This post is the fourth in a series on scaling Agile.
If this first step seems self-evident, then you would probably be surprised by how many people focus on scaling issues such as integrating work across teams and organization-wide “release trains” without having a clear idea of what they need to do to establish and sustain solid Agile teams. Before delving into this in more detail, I want to connect the dots between team collaboration and Agile practices such as Scrum and Extreme Programming (XP).
Agile in a nutshell
Over the last few blog posts, we have spent most of our time discussing how the family environment is the natural setting from which collaboration first sprung and how teams will prosper if they are able to emulate this environment in the workplace. Maybe you’re thinking that’s all well and good, but isn’t there more to Agile teams than collaboration? What about the rest of the Agile? What about Scrum and XP?
To get some perspective, it’s helpful to revisit why we are doing Agile in the first place. Agile helps us progress under conditions of high uncertainty, the very conditions under which our previous approaches to managing work failed. Although the root causes of uncertainty may vary, the Agile approach to managing through uncertainty is consistent: Progress incrementally and adapt accordingly. This allows us to learn in a stepwise manner what we need to do to deliver an emergent solution. Because the Agile process is iterative, it’s useful to represent it as a cycle:
In the diagram above, I have chosen verbs that are often used to describe Scrum. However, the verbs we use are not that important. What is important is making sure we have a clear understanding of the underlying activities: (1) Deliver something quickly (2) learn from the outcome (3) apply new learning to the next work increment.
Work is organized around the objective of speeding learning by doing a little bit at a time. Shorter iterations offer more learning opportunities and diminish the time between ideas and actions. The best way to proceed in this manner is through team collaboration. Teams are able to establish the mutual understanding and trust needed to — quickly — learn together and synthesize ideas into a pragmatic, testable construct:
Team collaboration is integral to Agile. Without collaborative teams, there is no Agile. Agile practices such as Scrum and XP provide frameworks and techniques for learning rapidly and delivering incrementally. They also include guidance about how to work effectively together as a team. They also assume and depend upon team collaboration. The family pattern for team collaboration complements Agile practices by establishing the workplace conditions needed for team collaboration. It’s the responsibility of the team to learn Scrum and XP and be willing to work in concert. It is the responsibility of the organization’s leadership to create the workplace conditions that are conducive to this working pattern.
Agile Scaling guiding principle
In the first post in this series, I introduced two principles to guide decisions that help us scale Agile:
- Be very clear on what Agile capabilities you wish to preserve and scale before you introduce new scaling structures.
- Be careful to choose structures that won’t impede, corrupt, dilute or otherwise limit the Agile benefits you hope to achieve at the next level of scale.
Regarding the first principle, it should be clear by now that in all cases an essential element of the value that we must preserve as we scale are Agile teams themselves. Without Agile teams, there is no Agile at any scale. If Agile teams are compromised as we scale, the benefits of Agile are also compromised.
The first step in scaling Agile is establishing Agile teams. Similarly, the first dimension of scaling is increasing the number of teams. Teams also constitute the first scaling structure. In slightly different words: Agile teams are the foundation for any additional scaling structures. As the foundation, Agile teams should be persistent, mature, well-formed, and well-supported. To the degree that they are not, our further scaling ambitions at the program and portfolio levels will be put in jeopardy.
Since, so far, the only scaling structure we have introduced are the teams themselves, we have not (yet) violated our second scaling principle. However as we discussed above, to get Agile teams established in the first place we need to create the conditions necessary for Agile teams to survive and thrive. In most cases this means not so much creating new structure but revising old organization frameworks that would otherwise impede healthy team development. I summarized some of these stumbling blocks in a previous post.
Agile is definitely biased in favor of the rule of parsimony, where less is more. Therefore you should avoid over-building or over-engineering when you can. When it comes to scaling Agile, this means delivering business value through single teams whenever possible. Keep in mind that there are many programs and products that are simply are too large to be completed by a single team. In such cases, there is a need to coordinate and integrate the work of several teams in order to deliver anything with economic value.
In the next blog post in this series, we will begin our discussion of this next level of scale, Agile program management, by comparing it to a village, the corresponding next level of scale after families that occurs in human civilization.
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 United States License.