It seems everyone wants to scale Agile. Many say they have
done so already. But there are different views on what the end state looks
like. What does it mean to have scaled Agile? For many, it simply means
replicating certain practices across all development teams. Although this may
improve the internal
quality of software, it won’t help improve overall IT performance as perceived by the business.
Agilists advocate that every story must have acceptance criteria. What are the acceptance criteria for having scaled Agile? More broadly, what is the “definition of done”? Here’s one:
- Responsive IT: Achievement of continuous delivery for the entire value stream (not just development team) from feature concept to cash or user adoption.
- Valuable IT: Innovation occurs relatively unimpeded by artificial organizational constraints.
- One team: Business and IT are able to work as one team even if they are separate on the org chart.
- Scaled performance, not just supervision: Don’t say you have scaled Agile when all you have managed is to scale supervision of Agile. Has it made a difference to business outcomes? That’s the litmus test.
In my upcoming book, I explain that this target state cannot be attained without improvements to the design of the IT organization.