We find that there is a lot of question as to how Agile teams can help stakeholders and customers in dispersed locations collaborate. We’ll cover information that should increase your knowledge at our Scaling Agile: Smart requirements and intelligent backlogs webinar on May 12th 2010.

Find out who needs to be included in the sprint process to make sure the right product is built and the right priority decisions are made.

Topics to be covered include:

• What are the right “most important” priorities? How do they fit with company goals?
• Are the requirements detailed enough for engineering to build?
• How can engineering validate early on if what they are building meets customer needs?
• How do you manage backlogs for complex systems?
• How do you adjust to changing conditions, understanding the impact of your decisions?

Be sure to register today and add the date to your calendar.

Join us on this important topic!

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.

Agile purists would argue that “scaling” and “Agile” should not go in the same sentence because the whole point of Agile is to deliver a working system in small increments, so you cannot get more scalable than that. Who can argue with that? Yet, I keep seeing organizations that love the value of sprints and cross-functional teams, but struggle to apply it to more complex software and products built across distributed teams.

Agile Fail Points – I have found similar challenges across disparate industries such as software, energy, consumer electronics, and internal IT. Next are some real-world examples. We delivered the system on time, but somewhere we dropped a critical requirement and that delayed a big payment milestone.  Each team did their sprints on time, but a delayed architecture piece caused latency to everybody. The priorities we were setting at the team level got out of sync with the release priorities. The user stories we get are too high-level, we do not understand what the customer really wants. Priorities change all the time and yet we are still on the hook to deliver.

Devil’s Triangles Traps of Agile – The more I look at the issues, the more I see them boiling down to two tiers of traps. To describe them, I’d like to borrow from Michael Krigsman’s excellent blog the idea of a devil’s triangle, and I want to redefine it a bit and expand it to two triangles.

The inner triangle is the dynamic between key team stakeholders: user/customer, product owner, and developers. While things tend to work fairly well in a team with co-located members, when you have distributed team members or difficult “politics” (both of which happen a lot) things “disappear” in the vortex of this triangle: use cases are ignored in order to get things done; user stories are not detailed enough; the context for prioritization is lost; customers change scope and priorities.
The outer triangle is the dynamics introduced by more complex systems and programs: the need to sync up sprints across release trains; manage dependencies between trains and architecture work; and have a shared view of prioritized backlogs at the release, feature, and user story level. In most cases this synchronization doesn’t happen with obvious and painful consequences.

It’s Not About Agile – If we define Agile as just running development sprints, all this scaling discussion has little to do with it, and everything to do with the structure and management around it. I hear this argument a lot, but in the end the distinction is a moot point: a good engine is not going to get you to your destination without the rest of the car – Agile development alone will not prevent the dynamics of the devil’s triangles to suck precious life from a project. What matters in the end is how we address these real challenges and ensure that the products we create and the projects we run deliver the value they were intended to generate.

In future posts I plan to discuss in more detail the challenges of the two devil’s triangles of Agile and ways to tackle them. In the meantime, I’d love to hear how this relates to your experience.