BT

New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

Real-life Agile Scaling - Henrik Kniberg's Opening Keynote at Agile Tour Bangkok

| by Shane Hastie Follow 11 Followers on Nov 21, 2015. Estimated reading time: 3 minutes |

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:

Risks of Scaling Agile

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:   

Earliest Testable Usable Lovable Product

 

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.

Team Structures

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.

Dependencies

Teams of 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:

Multiteam 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.

CI and CD

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.

Aligned Autonomy

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.

Good Agile Sweet Spot

He summarised his talk with the following points:

Summary

 

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT