Tips for Scaling Agile Development
It used to be normal to hear that agile projects should be small in both time frame and team size. Now, it seems conventional wisdom dictates that we should be scaling agile. But how do you go about doing this? The answer lies in simplifying the communication channels while addressing the overall team organization and its underlying practices.
One of the principles of the Agile Manifesto says, “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
Remember that bigger projects tend to increase handouts, like email and other forms of written communication, which reduces efficiency. On the other hand, direct conversations, adopting scrum of scrums meetings, and communities of practice are more effective ways of improving communication between teams.
Additionally, you might want to consider communities of practice, which are self-help groups and are an integral part of implementing a uniform agile methodology. Well-functioning communities—with clear vision, autonomy, and focus—can become an important tool in sustaining the agile model across multiple teams.
Keep in mind that all teams must uniformly adopt agile principles. This helps with the adoption of a governance model for execution of a uniform agile strategy across the enterprise. Indeed, the agile governance model on Agile Helpline recommends the adoption of scrum of scrums and communities of practice to drive agile governance.
For larger projects, teams should be organized as crossfunctional feature teams in order to develop end-to-end functionality. For scalability, you need multiple feature teams. Additionally, bigger projects also need component teams for developing reusable code. The key is to keep the number of component teams small to reduce dependencies.
Now that you have multiple teams building features and components, how do disparate modules get integrated? Continuous integration comes to the rescue for integrating the code. However, as the number of teams increases, you need a definition of done in order to incorporate integration tasks.
Mitch Lacey, in his article on defining "done," suggests that tasks related to “release to integration environments” are part of being done. This could also call for a separate integration team in rare cases.
Agile teams rely on the delivery of other teams for certain modules. To improve the timely delivery, the upstream teams should plan on completing their features ahead of the downstream feature team.
Finally, I suggest you take a look at what Mike Cohn says in Succeeding with Agile. Cohn suggests performing rolling look-ahead planning to proactively manage dependencies. This looking-ahead planning for the next two sprints can give you adequate time for the component teams to respond to the feature teams’ needs.
If you have any other suggestions for scaling agile, let us know in the comments below.
