Accept Software Resource Library

Agile for Complex Systems and Distributed Teams

Continuing from where I left off, let’s dive into the agile scaling challenge of developing complex systems. The organizations who face this issue typically fall in two camps: those who have succeeded with agile on small, single team efforts and have now won the privilege to do it for the big, mission critical systems; and those who have already started on the agile path for complex systems and find themselves overwhelmed by too many moving parts and people reverting to the old way of doing things.

Characteristics of Complex System that Stretch Agile
Complex systems are those that cannot be handled by a single agile team. These are large efforts and often systems of systems. At a high level the characteristics of these systems that stretch agile include:

• Multiple teams are required, they are distributed, and team members are often not collocated
• There are dependencies across teams requiring tight coordination in order to deliver working versions of the system at the end of each sprint
• The scope of platform/architecture work is too big to be part of a functional team effort
• The backlog for entire system is too big to be managed at the sprint level

Next we look at ways to handle these characteristics in the context of a scalable agile approach.

Synchronizing Releases, Architecture, and Sprints
Given the large scope of complex systems, it is best to organize work along frequent release trains, as Dean Leffingwell points out. Architecture work needs its own track(s) that should be synchronized with the functional tracks. Not all sprints need be the same duration, but end dates should be synchronized (Mike Cohn), particularly when dependencies exist across both functional tracks and architecture tracks. With this type of structure you can also roll-up the status of all work to the release level.

 

Group Backlogs by Tier
Looking at the entire system backlog at the sprint level would be too unwieldy and overwhelming. A better way to manage it is to break it down and group it along tiers. At the highest level of the entire system (or product, or application) you can manage the backlog at the level of epics. Next you break down a feature backlog for each release train. And lastly you have your stories backlog at the team level for sprints.

Virtual Daily Scrums and Scrums of Scrums
What about daily Scrums? This can get very tough when team members are across the globe with no overlap of working hours. Direct contact is critical, and there is the need to be talking live from time to time, but offshore team members are a reality that cannot be ignored. Virtual daily scrums go a long way to provide everybody on the team a clear picture of who is doing what and when, and of critical issues. And when you roll up the results of individual daily Scrums, you also get the nice by-product of a Scrum of Scrums view.

These approaches have been found helpful in ensuring the success of agile for large-scale systems and in preventing the natural tendency of an organization to fall back to the old-way of doing things. What has been your experience?

Register to hear more about this topic at an upcoming webcast on April 29.