Just a quick reminder that we have the first of our Scaling Agile Webinars tomorrow April 29th at 10:00 a.m. PT/1:00 p.m. ET!
We’ll be chatting about how developing complex systems stretches the Agile methodology with these challenges:

• 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
• How can Agile be adapted to handle these challenges?

Please join us! Register now!

In my past two posts in the Scaling Agile series, I’ve written about the triangle of traps and the challenges of developing complex systems when scaling Agile development. Today I would like to focus on the impact and challenges at the team level when developers and product owners are forced to operate in dispersed and distributed environments – a situation that could impose serious dependencies and may have an impact on other teams.

Three points of impact

The working context of large projects directly impacts team members in three big ways:

• They are dealing with a huge backlog and multiple teams, making it difficult to answer questions like: What is really important? Are there dependencies? Which pieces are locked by contractual commitments?
• The customer is typically not part of the team and in the high pressure to deliver it is easy to loose sight of who wants what we are building, why it is important, and how does the customer expects it to work.
• With multiple, distributed teams and individuals there is much more information to track and things easily fall through the cracks.

How to Break Down Backlog: Strategies

I’ve written about the need to break down large backlogs into tiers, but the big question is how? As backlogs get larger it becomes critical to have a way of defining the weight of multiple prioritization criteria to produce refined, intelligent backlogs. As criteria and weighting change, these intelligent backlogs can be automatically updated. In the Accept360product these prioritization criteria are called “strategies”.



Smart Requirements

Because teams in large projects are not self contained and customers cannot be part of every team, simple user stories are not enough for each team to manage their decisions.  In the rush to complete a sprint, shortcuts are often taken – risking that the end result misses the mark or negatively impacts the work of other teams.   To avoid this user stories need to carry a much richer set of information in addition to the description of the story. They need to be “smart requirements” and include:

• References to the customers who requested the capability, why they requested it and how they expect it to work
• Use cases and definition of affected personas
• Links to the strategies or prioritization criteria that they fulfill, so it’s always clear their strategic impact
• Dependencies from and to other user stories and the teams who own them.

Empowered Team Members Make Informed Decisions

Not being able to deliver an important feature in a release is always painful for me and from what I have seen it’s the same for anybody involved in a project. Some internal stakeholders and customers are bound to be upset. But this approach has helped me make informed decision with an understanding of the impact. It has also allowed me to proactively communicate the impact to the people affected. I find that people tend to be much more flexible and understanding when care is shown about informing them of a change instead of leaving them to discover it on their own and be surprised.

I’d love to hear what your experience has been in this area.

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.