Henrik Kniberg, author of the InfoQ Minibook “Scrum and XP from the Trenches”, gave the opening keynote at the Agile Tour Bangkok conference on Saturday 21 November in Thailand. His talk was titled “Real-life Agile Scaling”.
He started by stating that we understand how to apply agile techniques effectively at the single team level, and at the level of a few teams working together. Moving beyond that to be able to apply large numbers of teams to a single problem/initiative is much more difficult and is frequently done very badly.
He explored what “scaling agile” really means and challenged the need for organisations to scale – it is often undertaken without understanding why they are doing so and what the impact of scaling could be. He presented the following picture of potential risks and costs of scaling:
He stated that there are three elements which need to be understood in order to scale effectively:
- How to “slice the elephant”
- Team structures
- Feedback loops
- How to keep teams synchronised and aligned
- How to tackle dependencies across teams
Getting these things wrong results in less than optimal outcomes, and often leads to disaster.
Addressing the “Slice the Elephant” question he challenged the MVP (minimum viable product) concept and suggested using a sequence of Earliest testable/usable/lovable Product instead, as shown in this image:
On the team structure challenge he stated that feature teams are better than component teams but that there is a risk of new silos forming around the feature teams, so a hybrid mode combining some feature teams with some of the aspects of component teams will often be necessary in organisations with large, complex technology stacks.
This is also an approach to help reduce the impact of dependencies across teams, where internally focused teams treat the customer facing teams as their customers. This “platform team” empowers the teams and changes the approach to overcoming dependencies, with loose coupling and tight alignment between the teams.
He presented some guidelines for team formation:
- Teams should be 3-9 people
- Teams should be relatively stable, full time and collocated
- Teams need a clear mission to align around
- They should have clear line-of-sight to their customers (internal or external)
- They need some way of prioritising customer requests – this could be a Product Owner role or clear strategic guidelines for decision making
- Teams need to be cross-functional and have all the skills needed to deliver value to their customers
- Teams should be autonomous so they are not blocked waiting for other teams or individuals
Scaling requires implementing additional feedback loops. Team-level feedback loops are well understood and built into the agile processes (continuous integration, daily standup meeting, iteration planning, retrospectives, showcases…). To scale beyond single teams there is a need to add additional feedback loops:
These additional feedback loops require cross-team synchronisation. This can take the form of daily sync meetings (like Scrum of Scrums), weekly demos, monthly big-room planning events, etc. In one way or another teams need to meet regularly to resolve dependencies, evaluate the integrated product, update plans, and make decisions. This gets easier if all teams have the same iteration length.
He stated that Continuous Integration is absolutely critical for keeping the work of multiple teams at a high quality and making dependencies visible immediately they become apparent. Continuous Delivery is a useful, but not mandatory, extension which allows rapid customer feedback.
He explained that in large scale agile adoptions the role of leadership is vital to success. Irrespective of what the role is called there needs to be leadership and direction around technology, product and design. Leaders create environments where aligned autonomy can be achieved.
He summed up with a reminder that agile is a continuum and is an ongoing journey, not a destination. Finding the sweet spot of enough planning and architecture is the key to successful agile adoption, at any scaling level.
He summarised his talk with the following points:
