How do we approach capability development in an Agile product development organization? I first started thinking about this question during an assessment.
Agile product development teams are deliberately given a high degree of autonomy. They are expected to organize their own work, use their professional expertise and continuously improve how they work. Different teams operate in different contexts and may therefore develop different practices.
That creates an interesting problem. Suppose an assessment shows that an organizational capability needs to improve. Perhaps teams need to become better at identifying product-quality risks. Perhaps requirements need to become clearer before implementation. Perhaps testing needs to provide useful evidence earlier. Perhaps teams need to become better at learning from production.
How should the organization make that happen?
We could define a better process and ask every team to implement it. But then we are no longer developing a capability. We are prescribing its realization.
At the other extreme, we could simply tell autonomous teams to improve. But if the capability matters at organizational level, leaving its development entirely to independent local initiatives provides little direction or continuity.
There seems to be a tension between deliberate capability development and team autonomy. Perhaps Agile product development itself provides a way through it.
What If We Developed Capabilities Like Products?
Agile teams already work within a similar tension.
A Product Owner or Product Manager can determine that something about the product needs to change without prescribing exactly how developers should implement that change.
A Product Backlog makes those required changes visible and allows them to be prioritized.
The development team then determines how to realize them.
What if capability development worked in much the same way?
A Capability Owner could maintain a Capability Backlog.
A Capability Backlog Item could describe a required change in organizational ability.
For example:
Teams can identify significant product-quality risks early enough to influence development.
The Capability Owner can decide that this ability matters and prioritize its development.
But the backlog item does not say:
Introduce mandatory product-risk workshops.
Nor:
Train every team in method X.
Nor:
Implement tool Y.
Those are possible ways of realizing the required capability.
They are interventions.
The Capability Backlog Item describes what the organization needs to become capable of doing. The people developing the capability determine how to make that ability real.
Perhaps capabilities themselves could be developed using Agile principles.
From Implementation to Intervention
The parallel with product development is surprisingly direct.
A Product Backlog Item describes a required product change. Developers determine how to implement it.
A Capability Backlog Item describes a required capability change. Teams determine how to intervene in their existing way of working to realize it.
The relationship becomes:
Product Backlog Item → Implementation → Product Increment
and:
Capability Backlog Item → Intervention → Capability Increment
This distinction is important.
Suppose teams need to become better at identifying significant product-quality risks.
One team may introduce collaborative risk analysis during refinement.
Another may change how testers and Product Owners work together.
Another may introduce examples, modelling or lightweight risk classification.
Another may discover that its existing practices are sufficient with a relatively small change.
The interventions can differ because the teams and their contexts differ.
What should remain common is the required organizational ability.
This allows capability development to provide direction without unnecessarily standardizing how autonomous teams work.
The Capability Reference Model
But how does the Capability Owner know what belongs in the Capability Backlog?
A backlog alone cannot provide the answer.
There first needs to be an explicit understanding of the capability itself.
A Capability Reference Model can describe the significant organizational abilities, expectations and conditions associated with the capability.
Assessment then compares the realized capability with that reference.
Perhaps the reference says that teams should be able to identify significant product-quality risks early enough to influence development.
Assessment shows that several teams cannot reliably do this.
That creates a development need.
The need can become a Capability Backlog Item and be prioritized against other capability-development needs.
This gives the reference model and backlog different purposes:
The Capability Reference Model describes what good means.
The Capability Backlog describes what we believe should change next.
The reference provides continuity.
The backlog provides focus.
The Capability Increment
Once a Capability Backlog Item has been prioritized, a team can take it into development.
Suppose the item says:
Teams can use identified product-quality risks to prioritize testing effort.
The team explores why it cannot reliably do this today.
Perhaps risk information arrives too late. Perhaps business impact is poorly understood. Perhaps testing is planned before risks have been discussed. Perhaps the team lacks experience with risk analysis.
The team then chooses interventions appropriate to its situation.
It might change refinement.
It might experiment with risk workshops.
It might seek coaching.
It might change collaboration between Product Management and Testing.
It might introduce supporting tools.
Those interventions are analogous to implementation decisions in product development.
But what is the resulting increment?
It is not the workshop.
It is not the training.
It is not the tool.
The increment is the change in organizational ability.
Before the sprint, the team could not reliably use product-quality risks to prioritize testing.
After development, it should be able to.
That is the capability increment.
Done Means Capable
This has an important consequence for the Definition of Done.
Suppose the team planned three interventions:
- conduct training;
- introduce a risk model;
- use it during refinement.
At the end of the sprint, all three activities have been completed.
Is the Capability Backlog Item Done?
Not necessarily.
Completing the interventions demonstrates that development work occurred.
It does not demonstrate that the capability increment exists.
The relevant question is:
Can the team now do what the Capability Backlog Item says it should be able to do?
That requires evidence.
The team might demonstrate the ability using real product work. It might be observable during refinement. A simulation might sometimes provide sufficient evidence. Other capabilities may require operational evidence over a longer period.
The form of evidence will vary.
The principle does not.
A Capability Backlog Item is not Done because its interventions were completed. It is Done when there is sufficient evidence that the required capability has been realized.
In other words:
Done means capable.
Reassessment Becomes Part of Development
Capability assessment is often treated as something that happens before an improvement initiative and perhaps again much later.
Agile capability development suggests something more continuous.
Assessment identifies a capability-development need.
That need enters the Capability Backlog.
A team develops a capability increment through interventions.
Evidence is collected.
The resulting capability is reassessed against the relevant part of the Capability Reference Model.
The cycle becomes:
Reference → Assess → Prioritize → Develop → Intervene → Reassess → Learn
If the required ability exists, the Capability Backlog Item may be Done.
If it does not, the interventions may have failed or been insufficient.
That is not necessarily wasted work. It is learning.
The team may try another intervention. The Capability Owner may reconsider the backlog item. The assessment may reveal another underlying weakness. In some cases, experience may even challenge the Capability Reference Model itself.
Capability development becomes iterative.
Autonomy Without Abandoning Direction
This may resolve the tension that started the question.
Team autonomy does not have to mean that organizational capability development is left entirely to local initiative.
And organizational capability development does not have to mean prescribing one standardized way of working.
The organization can establish:
what ability is needed,
while autonomous teams retain substantial freedom over:
how that ability is realized.
Assessment closes the loop.
Teams are not judged primarily on whether they adopted the prescribed practice. They are assessed on whether the required capability exists.
Two teams may therefore realize the same capability differently.
That is not necessarily inconsistency.
If both realizations satisfy the relevant capability expectations, it may simply be autonomy working as intended.
The reference provides coherence without requiring uniform implementation.
When Capability Development Crosses Team Boundaries
Not every capability can be developed by one team acting independently.
Capabilities interact.
Product Management affects Requirements Engineering. Requirements Engineering affects Testing. Architecture affects Engineering and Release Management. Operations provides evidence that influences several of them.
An intervention may therefore contribute to several capability changes at once.
Collaborative product-risk analysis, for example, might strengthen Product Management’s ability to make quality expectations explicit, Requirements Engineering’s ability to identify significant conditions and Testing’s ability to focus evidence on important risks.
Likewise, one capability change may require several coordinated interventions.
This is where broader organizational development becomes necessary.
Transformation as Orchestrated Intervention
A transformation program can be viewed from this perspective as a temporary mechanism for orchestrating interventions across multiple capabilities.
Consider adopting SAFe.
The visible transformation introduces roles, events, structures, backlogs, planning mechanisms and governance arrangements.
Those are interventions.
Behind them are organizational capabilities that the transformation is intended to strengthen: Portfolio Management, Product Management, Architecture, Requirements Engineering, Engineering, Testing, Release Management, cross-team coordination and others.
The important question is therefore not simply:
Did we successfully implement SAFe?
It is:
Did the capabilities we intended to improve actually improve?
PI Planning may have been implemented perfectly while cross-team coordination remains weak.
Product Management roles may have been appointed while product direction remains fragmented.
New testing practices may have been introduced while the organization remains unable to provide timely evidence about product quality.
The interventions can be successfully implemented while the capability development fails.
This is why the intervention should not become the reference against which improvement is judged.
Capability Stewardship Continues
Transformation programs are temporary.
Capabilities are not.
A transformation may accelerate development across many capabilities and coordinate interventions that would otherwise be difficult to perform.
Eventually the program ends.
The Capability Reference Model remains.
The Capability Backlog remains.
New evidence appears.
The environment changes.
New weaknesses emerge.
The capability continues to develop.
The Capability Owner therefore provides continuity beyond any particular intervention or transformation.
The role is not to own every practice used to realize the capability.
It is to steward the capability itself: maintain its reference, understand its current state, prioritize what needs to change, and ensure that development and reassessment continue.
Reflection
The original problem seemed to be about autonomy.
How can an organization deliberately improve ways of working when Agile teams are supposed to determine for themselves how they work?
Perhaps the problem appears because we confuse the capability with its realization.
The organization does not necessarily need to prescribe the practice.
It needs to make the required ability explicit.
A Capability Reference Model can describe that ability.
Assessment can show where the realized capability is insufficient.
A Capability Owner can prioritize the required changes through a Capability Backlog.
Autonomous teams can discover suitable interventions.
Reassessment can determine whether those interventions actually produced the required capability increment.
That is remarkably similar to the way we already develop products.
Perhaps capabilities themselves could be developed using Agile principles.
Leave a Reply