Delivery predictability

Delivery predictability refers to the percentage of the committed work that is completed at the project’s end. This capability enables the organisation to make customer commitments and utilise resources effectively.

1. They deal with uncertainty

Software is complex, and uncertainty is inherent in every endeavour. Teams that ignore uncertainty suffer more stress and burnout than those that effectively manage it.

When uncertainty is communicated in vague language such as ”soon” and ”likely”, it leads to misunderstandings. When developers say five days, customers and stakeholders assume it means exactly five days, but the reality may be between three and seven days. This is perhaps the most common root problem for failed expectations.

The best way to deal with uncertainty is to estimate it. An estimate is a guess, an approximation when an exact measurement is impossible. This means an estimate has a probability distribution. Five is somewhere between three and seven.

To estimate uncertainty, the key insight is the distinction between complexity (Simple vs. Complex) and effort (Easy vs. Hard). Effort is subjective; Anna may do something in one day that takes Mustafa two days. Complexity has to do with how many ”things” must be done to complete a task. When the team agrees on a high-level solution, counting the number of system components that must change may be a reasonable estimate for complexity. Complexity can be measured objectively.

“Agile estimation and planning succeed because estimates of size and duration are separated. Because story points are abstract they are pure estimates of size. We then estimate a rate of progress, which we call velocity. - Cohn, Mike. Agile Estimating and Planning.

The best way to estimate work is to use Story Points (or other size metrics, such as S, M, and L) rather than Ideal Days. Instead of having Bob say it will take him three of his days and Alice say it will take two of her days, it’s better if the team says that task A is twice as complex as task B.

An average velocity—the work rate—is calculated by estimating complexity and work in fixed time slots. By taking the average velocity over several sprints, we can calculate when work will be done within a normal probability distribution. If the last three completed 7, 5, and 9 things (an average of 7), it’s reasonable to expect around seven things achieved in the next. With that, you can calculate the product plan.

A common misconception is that estimation is commitment. It’s not. The estimate conveys information about the work that customers and stakeholders find valuable. Is task A bigger than task B? Knowing relative sizes helps plan and prioritise.

2. They make every delivery a working system for stakeholders

Teams that focus immediately on tangible results — rather than process, preparation, and planning — receive better customer feedback and are more likely to deliver on customer expectations in the long run. Teams stuck in “setting things up” and “building the platform” never catch up.

By consistently delivering a working system that the customer can try, the customer is closely involved in the project. Initially, the deliverables may be minimum viable products (MVPs), but remember that viable means that something is practically useful. They may be walking skeletons, all system parts are available but implemented superficially (e.g., the database may be a JSON file).

The essential idea is to focus immediately on tangible results - rather than programs, preparations and problem solving - as the first step in launching performance improvement thrusts… It is almost always possible to identify one or two specific short-term bottom line goals for which the ingredients for success are in place..” - Peters J., Thomas and Waterman Jr., Robert H. In Search of Excellence. 1982.

The key insight is to understand the distinction between vertical and horizontal development. Technical systems consist of layers, such as the data layer, business logic layer, and user interface layer. Developers tend to build a technical stack either top-down or bottom-up, one layer at a time. Customers, however, don’t see or value the layers. Customers expect a steady flow of features, each with a part from each layer in the stack. So, instead of iterating vertically, one layer at a time, it’s better to iterate horizontally.

Team engagement

Engagement refers to the likelihood that someone will recommend the organisation as a great place to work.

3. They are autonomous with a clear directional goal

Alignment is the extent to which the team has a specified goal (what they should do) or whether it’s free to do whatever it wants. Autonomy refers to how much of the team’s means (how they work) are specified, or whether they are free to do things as they want.

“Effective team self-management is impossible unless someone in authority sets the direction for the team’s work.” -- J. Richard Hackman. Leading Teams. Harvard Business Press, 2002.

When both alignment and autonomy are low, teams are told in detail what to do, but they do not know the overall goals. This is called micro-management.

When teams are free to do what they want, without any clearly stated direction, it's anarchy. Anarchy can be dangerous, as the team may set off in a direction that is potentially harmful to the company.

When teams have a clear directional goal but not the autonomy to make their own decisions on the means, it's a waste of human resources.

The most effective teams have "aligned autonomy" (see Henrik Kniberg's excellent YouTube clip) and create their purpose within the directives set by the overall organisation and processes.

4. They constantly improve their system and don't depend on "later"

Developers should be permitted to do a great job.

Effective teams don’t depend on fixing it later or waiting for customers to ask them to improve system quality. Customers expect a high-quality system; they will not request platform quality as a feature.

Once the team takes ownership of refactoring and tidying their code, the cost gets built into the estimates, as it should.

“Modernization should be built on adding value, not chasing technology trends”. - Bellotti. Marianne. Kill it with fire.

Refactor as you go. When new features are estimated, take into account the tyding and refactoring requires to ensure the end result is always a better system.

5. They deliver a collective output

Highly effective product teams collaborate to deliver tasks as a collective outcome. No member delivers anything on their own. This makes the team different from a coordinated group.

Value Realisation

Value realisation refers to the extent to which the completed work makes a difference to customers. As developers, we love the latest technology and are always eager to improve and refine it. However, in the end, it’s the customer impact that matters.

6. They fix bugs immediately and always have a working system

”It works on my machine.” — Unknown Software Developer

The software from effective product teams is always working and free from bugs. When bugs are detected, they are fixed immediately (at the top of the backlog). This policy may initially slow the team down, but because the team is forced to work together and fix all bugs, they eventually grow and become faster.

Bugs are problems that prevent a user from accomplishing a task supported by the system, and there is no simple workaround.

“If some problem occurs the whole production line stops. In this sense it is a very bad system. But when production stops everyone is forced to solve the problem immediately. So team members have to think, and though thinking teams grow.” - Liker, Jeffery. The Toyota Way.

A common mistake is labelling a feature request as a bug. The fact that someone’s favourite feature is missing is not a bug. It’s a feature request and should be prioritised with other features, not as bugs.

Perhaps the most efficient way to reduce the number of bugs in a system is to define what constitutes a bug. There may be fewer than you think.

7. They have a clear Definition of Done (DoD)

It’s often surprisingly hard to tell when software is done. At some level of abstraction, it’s never done. However, to de-risk a project, you want to work in small incremental steps and iterate.

Effective teams don’t wait for the obvious. Testing, monitoring, analytics, and logging are not the subject of endless discussions. They are always there, making every delivery ready for launch when the time comes.

The Definition of Done (DoD) should be a non-negotiable checklist. It’s the contract between the team and the stakeholders. Here are a few things that typically should be on the checklist:

• Testing - Does the software work as expected for the customer?
• Documentation - How do we know what the code is doing?
• Analytics - How do we know what users are doing?
• Observability - How do we know what the code is doing when it’s live?
• Monitoring - How do we know what the code has done (logging)?
• Interfaces - How can other teams access, should they wish to?

When the team and stakeholders have different understandings of what is meant by ”done”, decisions are made on false assumptions.

8. Their backlog is a prioritised list of functionality that the customer finds valuable

Effective teams start with the customer’s needs and work backwards. Their backlog is the functionality that the customer finds valuable, in the order of delivery.

It’s a common mistake to use the backlog as a to-do list and add all kinds of tasks, everything from implementation details to concepts. That’s a big mistake! It makes the backlog impossible to prioritise, and customer focus is lost.

De-clutter the backlog frequently. Remove old items ruthlessly.