FROM THE ARCHIVES OF PRAGPUB MAGAZINE FEBRUARY 2010
Barriers to Agility: How to Thread the Barriers to Agility When Failure Is Not an Option
By Johanna Rothman
How do you select a pilot project that will maximize your chances for learning and success?
When a company decides to make the transition to Agile, it’s making an investment in its future. Some companies make a serious investment in their business and people by funding professional help for their Agile transition. But many companies can’t or just don’t.
When the company doesn’t provide professional help with the Agile transition, it leaves people on their own to learn how to make Agile work in their organizations. They might read books, attend conferences, read newsgroups, and/or chat with friends. All to the good. You can learn a lot by reading books, and you can learn specific skills and learn about other people’s experiences by going to conferences. Using newsgroups and your colleagues to bounce ideas off is a great idea.
But when failure is not an option for your Agile transition, it’s time to get some coaching and learn how to do Agile right for your organization, product, and team. And that seems to be a problem for many companies.
For several years now, Gil Broza and I have been giving talks at conferences about common problems we’ve seen in how different organizations transition to Agile. We’ve seen quite a number of Agile Titanics: maiden Agile voyages that sank. Here’s some advice based on our experience coaching Agile transitions.
Select the Right Pilot Project
It’s easy to select the wrong pilot Agile project. Select a tiny project with just a couple of people for a month or so and you won’t learn how to experiment with evolutionary design, or how a team works together to solve problems. Select a big project and you’ve got a mess because too few people have experience with incremental work inside timeboxes. The coordination of a large project is hard, and doubly so if it’s your first time.
Think of Goldilocks when you select your pilot Agile project: the project has to be “just right” for size and risk. Let’s get specific: the project must be large enough that it requires about four to six people for at least three months.
Can the project be larger? Yes, up to nine people. More than nine people on a project and they’ll break into sub-teams — or worse, cliques. If the project is longer than six months or so, you run the risk of being the only Agile project in a waterfall world — an uncomfortable place to be, as a pilot project.
Can the time frame be shorter, or the project smaller? Not really. Shorter than three months and you don’t have enough experience with how your organization imposes or manages the obstacles that the team encounters. Fewer than four people and you don’t have a project with enough risk, so you won’t be able to see how Agile manages risks.
Your pilot project is the project that helps you see the obstacles to your organization implementing Agile. You want to learn from it, in the same way that the project team learns from each iteration. Make it too small or too short or too risky or too safe and you won’t learn enough about how Agile works for you.
Selecting the right project isn’t enough to prevent an Agile Titanic. You need a team who can do the work.
Select the Right Pilot Team
I’ve seen a number of pilot Agile teams composed entirely of developers. When they get to the end of an iteration, they count all the work as done, because their work is done. But the testers have not tested, the writers haven’t written any documentation, and there’s plenty of other work not done yet.
For those of us with Agile experience, the idea of a single-function team piloting Agile doesn’t make sense. But for people coming from years of Waterfall experience, it seems reasonable. So they set themselves up for failure with a single-function team, and when they finish several iterations, or even their part of the project, they don’t understand why they didn’t see different results from the published literature. “But,” they say to me, “we were using Agile. Why didn’t it work? What’s wrong with Agile?”
That’s the wrong question. The right question is, “Why aren’t all the roles across the organization represented on the team?”
A pilot Agile project needs the same team makeup as a real Agile team — that is, the team either has representatives from all the functions in product development, or the team members are able to perform that work. If you have testers on other projects, you need testers on the Agile team. If you have a release team in your organization who makes the builds happen, you need someone to make the builds happen on your pilot Agile team. If you have a DBA to do all the nasty query work, you need someone to do that work on the Agile team.
Because the team has to finish the work they committed to for an iteration, and the work has to be releasable, they need everyone they would normally need for a project on an Agile team. In fact, you could say that the ability to create a cross-functional team — and keep the team together for the entire duration on this project and only this project — is a test of management’s commitment to Agile.
If you can’t manage to create a small cross-functional team working on just one project, you don’t have the right environment to start Agile.
You have other options for lifecycles, and you should take a look at the lifecycle chapter and appendix in Manage It!
When you select a pilot team, follow these principles: Make sure all the roles are represented on the team. Make sure the team can stay together for the entire project. And, for the pilot project, make sure the team is all in one physical location. Yes, you can do Agile with distributed teams, but it’s much harder when people are distributed than it is when everyone is all in one place. It’s easier to learn Agile with a team that’s all in one place.
Other Pilot Agile Suggestions
Gil and I have put together a teleclass series that reveals these issues and how to resolve them. In a recent free teleclass we taught how to select a proper pilot Agile project, how to select the team to work on that project, and how to help the team work together as a cohesive self-organizing team. We also discussed what to do if you had no control over the project or team selection.
On the call, we discussed four other characteristics of the pilot Agile project. We also discussed what to do if your project doesn’t fit into that sweet spot: large enough to learn from but not so large that you have a mess. You have some options: for a too-large project, use Agile on one chunk and learn from it. For a too-long project, use interim releases. For a too-small project, see if you can gather more work and make the project bigger.
We wish you success in your Agile transition and we hope you never encounter the iceberg.
About the Author
Johanna Rothman’s latest book is called Successful Independent Consulting, and is available from The Pragmatic Bookshelf.
