Agile software development is all about eliminating overhead. Instead of establishing hierarchies and rules, Agile...
management zeros in on what the team can do right now, and team leaders, developers and testers roll up their sleeves to deliver working software by the end of the day.
Put another way, Agile software development favors real work over what I call "work about work." Work-about-work is that dreaded situation where creating reports about the project is so time-consuming it prevents you from actually working on the project.
Agile management's focus on "what we need to do today" avoids the work-about-work problem, and the approach is effective for single teams where members sit side by side in the same room. But what happens when projects expand to include many teams working at separate locations, often across several time zones?
Is it possible for Agile teams to maintain their agility when development projects grow to include perhaps 100 people? How do they avoid creating the Agile management nightmare that software development consultant Ron Jeffries described this way: "a 100-person project is a 10-person project, with overhead."
I have posed this question to quite a few Agile experts over the last few months, and of course, many answers emerged. Some involve sophisticated approaches like Disciplined Agile Delivery, or DAD, and the Agile Scaling Model, or ASM, specifically devised to address the complexities of large-scale projects.
The answers that stick with me, however, are the small, commonsense measures that help Agile practitioners stay true to the spirit of Agile, as envisioned by its founders: Favor people and interactions over process and tools, value working software over comprehensive documentation, concentrate on customer collaboration over contract negotiation, and train to respond to change instead of following a plan.
In this installment of Quality Time, I discuss some Agile management tips offered by experts for easing multi-team Agile projects.
Achieve single-team success first
Mastering Agile techniques within a small team is a prerequisite for multi-team success, says consultant James Shore, co-author of The Art of Agile Development. This sounds like common sense. But Shore has seen many organizations that lack Agile experience attempt large-scale projects and fail. If Agile practitioners don't understand what single-team success looks like, how can they effectively manage multi-team Agile projects?
Agile software development favors real work over what I call 'work about work.'
Keep teams small
Most experts believe Agile teams should top out at about 10 members. Johanna Rothman, founder of Rothman Consulting Group Inc., in Arlington, Mass, recommends going smaller for multi-team projects. Five- to seven-person teams ease the process of coming together as a group and figuring out who does what. In other words, the smaller the team, the easier it is to stay Agile. If a small team lacks a necessary skill -- a common objection to Rothman's recommendation, she suggests "bringing in visitors for an iteration." That might be a database administrator, for example.
Keep established teams intact
When Agile projects span many teams, it's a given that some teams emerge stronger than others. Conventional wisdom suggests that moving members from high-performing teams to ones that aren't doing as well will boost progress overall. It won't, said Amy Reichert, a tester and Agile practitioner at San Francisco-based healthcare firm McKesson. Each team has its own chemistry, and when known members move out and new ones move in, the team's rhythm is interrupted and progress stalls.
Keep iterations short
Large projects lead some Agile managers to favor longer iterations -- the mini development cycles within software projects. But shorter -- no more than two weeks -- is better, Rothman said. Shorter cycles let teams solicit feedback on small increments of work and make changes accordingly.
This is important for all Agile projects, but the more teams involved, the more important it is to keep iterations short. The length of an iteration should be equal to the amount of work you can afford to throw away, Rothman says. If, for example, business leaders don't like the software you are writing for them, you could throw away two weeks of work and start over. Do the math and it's easy to see how, for example, ten teams practicing three-week iterations could land a project in real trouble if do-overs are required.
Learn how to get unstuck
Multi-team Agile projects will never be as efficient as single-team efforts. What will you do when a large project gets stuck -- as it inevitably will? What often occurs in this situation is that inertia sets in, as one team waits for another to take action. Don't let that happen, Rothman said. No matter what your role, take a stand. Identify what you are going to deliver that day. Do it, then let other teams know what you have done. It's a way of staying Agile, no matter how large the project or the problems at hand.
What are your solutions for stable Agile management in multi-team projects? Let us know what you think.