The Urgent Call for Agile Organisational Transformation
As we progress deeper into the dynamic landscape of the 21st century, our long-established organisations, born of the Industrial Age and infused with a DNA of strict command and control, stand on shaky ground. These organisations strut with command-and-control bravado, erecting clear hierarchies in their stable inert markets where bureaucracy reigns supreme. However, they are feeling the tremors of a rapidly evolving, technologically charged dynamic markets and are plagued by sluggish responses and missed opportunities, which are their Achilles heel in these new fast-paced markets. Not since the 1970s has the classic hierarchical model, rooted in the stagnant waters of stable markets, been a viable proposition for companies seeking to thrive in an era of unprecedented change and unpredictability. Clearly, we cannot continue to coat deep-seated hierarchical practices with a thin veneer of modern innovation and expect sustainable transformation.
Embrace Uniqueness: Why Creating Your Own Scaling Practices Leads to Business Success
Business Leaders face a key challenge when scaling their organisations effectively while maintaining the distinctiveness that made us successful in the first place. Many frameworks and methodologies, such as Scaled Agile Framework (SAFe) or the Spotify Model, promise a structured approach to scaling, but do they genuinely fit our unique needs? In this post, I aim to highlight the importance of creating our own scaling practices, highlighting that successful commercial software organizations have thrived by embracing their distinctiveness rather than adopting standardized approaches.
Announcing Professional Agile Leadership with Evidence-Based Management Training (PAL-EBM) from Scrum.org
I have been an accredited Evidence-based Management Expert with Scrum.org for the last 7 years and I have been using the Evidence-based Management Guide to encourage leaders to make decisions based on evidence instead of gut feel.
Hiring a Professional Product Owner
One of my customers is asking me about the accountabilities of a Product Owner and how they break down. While I had seen many things around the Scrum Master for my post on Hiring a Professional Scrum Master , this was a little bit more of a discovery session, which is why I asked some of my trusted colleagues at Scrum.org to help out.
Stop normalizing unprofessional behaviour in the name of agility
In Scrum Events across the world, I hear repeated the phrase “that’s how agile works” when describing behaviours that are both unprofessional and the very opposite of an agile mindset. These behaviours will inhibit agility and are a result of a lack of understanding of the underlying principles.
Hiring a Professional Scrum Master
One of my customers is hiring for the Scrum Master Role and asked if I had a handy-dandy Scrum Master Job Spec that they could use. I did not, but there have been a few good ones floating around in the ether so I thought that pulling one together would be a good idea anyway. Here is my best effort to use the existing job postings, and combine them with the latest version of the Scrum Guide.
Scrum is made up of Influencers, Entrepreneurs, and Makers
In the empirical world, we have 3 key skill areas of accountability that are needed to effectively deliver products of the highest possible value! We need Influencers that can provide leadership and create environments within which groups of people can organise the work. I consider this the Leadership Track where you have Scrum Masters, Coaches, and CEO. We need Entrepreneurs who can have a vision and project knowledge and understanding of that vision to the people that need to make that vision happen. This is the Value Track and may be made up of Product Owners, Analysts, and Subject Matter Experts. Last we have the Makers who are the ones who do the work that brings the product to life. They are on the Technical Track and focus on turning the vision into a reality. They have many skills and may have coders, testers, and other experts…
Become the leader that you were meant to to be
Leadership is not about control, but about inspiring those around you. Managers transition to Leaders As organisations move towards modern management practices there will be less of a need for Managers. However that does not mean that those same people are not needed! Their role is shifting from managing people, to managing effectiveness and leading people!
All technical debt is a risk to the product and to your business.
If you were buying a car, or a TV, you as the purchaser would do your best to understand the product that you are buying, the quality tradeoffs, and the capabilities.
Professional Kanban Trainer for Applying Professional Kanban
The Scrum Guide only contains the minimum necessary to create an empirical process control system for managing risk. The new Kanban Guide reflects the minimum that you need to do to create a strategy for optimizing the flow of value through a visual, pull-based system.
What is Taylorism, and why Waterfall is just the tip of the iceberg!
For many people the traditional project management methodologies (see PMI / PRINCE2) are the root of the problems that birthed Waterfall. I assert that this is the tip of the iceberg. These methodologies are just a symptom of a greater problem that has its roots in the changes made during the industrial revolution. These changes, while they generated great amounts of wealth and many jobs around the world, dehumanised work and destroyed the essence of value and discovery that brought humanity to where it is now. It created processes that turned people into little more than sophisticated robots and enshrined that thinking into the very core of how we do things.
Sprint Goal is an Immediate Tactical Goal
In the The Evidence-Based Management Guide we talk about the Intermediate Strategic Goal and I likened that to the Product Goal in the 2020 Scrum Guide . If we also think of each Sprint as a tactical move towards fulfilling that Product Goal then the Sprint Goal becomes an Intermediate Tactical Goal that moves us towards our current Intermediate Strategic Goal.
Story Points & Velocity are a sign of an unsuccessful team
Story Points and velocity have been used for many years in the Scrum community and have been engrained so much in the way that things are done that most folks believe that they are part of Scrum. The accepted wisdom is that Scrum Teams are supposed to use User Stories, Story Points, and Velocity to measure their work.
Evidence-based Management: Gathering the metrics
Gathering the metrics for Evidence-based Management in software organisations can be a strenuous task and I have a number of customers that are fretting on what to collect and from where. Here I try to create an understanding of the ‘what’ that we need to collect.
There is no place like production
Value is such a subjective thing that we will often be wrong, and there is no way around that wrongness. In order to minimise the wrongness and maximise the amount of value that we deliver we need to have a clear understanding of what our users need, how they are using the product, and validate our new value as soon as we can. Without validation we only have assumptions and assumptions can be dangerous.
Product Goal is an Intermediate Strategic Goal
The Evidence-Based Management Guide describes not only a Strategic Goal but also an Intermediate Strategic Goal that is needed to evaluate and adapt your progress towards your intended visions of your product.
If your backlog is not refined then you are doing it wrong
Most Scrum Teams that I encounter don’t do refinement of their Product Backlog and try to work on things that they don’t understand correctly. However, if you get to the Sprint Planning event and your backlog is not ready, then you are doing it wrong. If what you build is not of good quality then you should read about Defenition of Done .
Getting started with a Definition of Done (DoD)
In my last post about Professional software teams creating working software David Corbin made a good point. How do you determining what “Free from fault or defect” means? Since that is different for each Product and may change over time you need to focus on Quality and reflecting that quality in a Definition of Done (DoD).
A better way than staggered iterations for delivery
There is a better way than staggered iterations for delivery that will keep you on the path to agility. Staggered iterations lead to more technical debt and lower quality software.
You are doing it wrong if you are not using test first
Many teams are struggling with delivering modern software because they are not building with Test First Principals. Test First gives us the assurance that we have built the correct thing, that what we built is what the customer asked for and that when we change things we don’t break anything inadvertently.
