After months of politicking, you’ve finally achieved your goal to run an agile project. You’ve put your team together, you’ve convinced your managers to let you colocate in a single work space, and you’re ready to go. Unfortunately, you find yourself surrounded by the rest of your IT organization: people who aren’t agile, probably know very little about agility, and may be hostile to the whole idea. What are you going to do now?
In an ideal world, you want to do the right thing: produce working software
that meets the needs of your stakeholders in the most appropriate way possible.
You should be able to work closely with your stakeholders, to create whatever
artifacts that you see fit, to not be forced to create artifacts that don’t
add value, and to do so at the most appropriate times during the project lifecycle.
You need access to the right people at the right time, and you should be free
to refuse the “help” of others. In other words, you should be in
control of your own destiny.
OK, you can stop laughing now.
Ifs and Buts
Unfortunately, many agile project teams often lack this essential control. Senior management may be willing to give agility a try—as long as you don’t rock the boat. “Sure, you can do Feature Driven Development—if you still follow the processes of the existing data administration, quality assurance and enterprise architecture groups.” Although it’s possible for all three of these groups to work in an agile manner, it’s an uphill road if you’re the agile pioneer in your company.
First, you need to find a way to work with these folks. An agile team should have stakeholders from all involved areas, so everyone involved will need to be flexible—including you. You must listen to their concerns and questions, and find ways to gain their trust and interest in the project. They must be willing to try working in an agile manner—which means an evolutionary approach.
Because agile development is iterative and incremental, you won’t be producing a large requirements document early in the project that others can review and accept, nor will you produce a big architecture document before you start design, nor create a detailed design document before you start coding, and so on and so on and so on. Instead, your artifacts will evolve over time. Other groups must accept “partially complete” artifacts, often in nontraditional formats. For example, agile modelers often create their architecture models on whiteboards and leave it at that—they don’t want to invest the time to create pretty architecture documents for the bureaucrats to review.
Time to Block
OK, I’ll come down to earth. So what do you do if other people aren’t flexible enough to evolve their approach into a more agile one—even after you’ve tried education and communication? The answer is simple—you block them. On an American football team, there are several very large guys on the front line whose sole job is to make sure that opposing team members don’t sack the quarterback (which would prevent your team from moving forward). In software development, a blocker works in a similar, though less physical, manner, to stop people on other teams from hindering your developers’ progress.
A blocker produces the documents that the bureaucrats request, attends their meetings and constructs a façade that makes it look as if your project team is, in fact, working with these other groups. This appeasement process keeps bureaucratic impediments away from your developers, allowing them to get their job done. The bureaucrats can claim that they’ve “helped” your team, and are thus able to justify their existence.
On a team of 10 people, you may need one or two blockers. Although this sounds like a waste of valuable personnel, it enables the other eight or nine workers to be effective—which is far better than your entire team wasting time hopping through bureaucratic hoops.
Who Should Block?
This depends on your situation. Often, the team lead takes on this role, if only for the simple reason that you really wouldn’t wish this task on anybody. After all, who wants to spend most of his time attending useless meetings and producing worthless documentation?
You could also treat it as a revolving position, with each team member taking a turn for an iteration. In fact, it’s a great way to give people downtime away from the project—albeit downtime that isn’t much fun.
You could also assign one person permanently to the role—perhaps an employee who doesn’t have the skills or attitude to be an effective agile team member. Some people seem to be oriented toward attending meetings and producing paper—if you’ve got one of those on your team, let him indulge this curious inclination.
What to Block?
The easiest way to answer this question is to turn the four values of the Agile Alliance around—something I jokingly did with my "Fragile Manifesto, The Agile Edge, Aug. 2002). Some groups may value following processes or using tools more than they do working with people. As a result, blockers spend time creating "necessary documents required by your process that offer no real value to the project team, attending review meetings for those same useless documents to ensure that they're of sufficient quality, and filling out the "all-important process checklists so that management knows the useless documents have been created and are acceptable to folks not directly involved in the project.
Many IT professionals still suffer from the serial mindset promoted by traditional development approaches, focusing on comprehensive documents produced early in the lifecycle as opposed to working software. Since these folks rarely have the skills required to produce working software, blockers may find themselves creating extensive requirements documents—a dangerous pursuit, because the team may be expected to work to that document as opposed to building working software. To cater to data administration bureaucrats, blockers may also be required to create logical data models, or, worse yet, physical data models that your data group wants to baseline to enforce a rigid database schema. This may be convenient for the data group, but it’s incredibly bad for your developers, as the database schema generally evolves with the rest of the application (next month, I’ll discuss evolutionary database techniques).
Bureaucrats may focus on defining contracts instead of collaboration, requiring the blocker to invest time in negotiations. Management often wants to see comprehensive plans in place, requiring the blocker to create and update complex Gantt charts. The critical thing to remember is that the blockers do all these things in parallel to the “real work” being done by the rest of the team, therefore preventing the bureaucrats from impeding progress.
Will You Get Caught?
Maybe, but don’t count on it. Lately, I’ve been talking about blockers at conferences. When I ask people if they’re doing it now or if they’ve done it in the past, I see a lot of hands held high. When I ask if they’ve been caught, only a few hands remain aloft. The coin flips both ways, too: If you’re not working directly on a project team, but instead are “supporting” one or more teams, you may want to ask yourself whether you’re being blocked. And, in case this article blows your cover, I hereby apologize in advance.
If you do get caught, my best advice is show management that the team really didn’t need to complete whatever tasks you were blocking, and suggest that the blocked activities be discontinued. Just remember to do so in a way that lets the person you were blocking maintain as much dignity as possible.
The Big Picture
Remember, if you’re using a blocker or intend to do so, your organization clearly has a big problem. Though blocking can serve as an effective stopgap measure to get a project past the goal line, in the larger sense, it’s like applying a Band-Aid to an injury that requires major surgery. Subterfuge should be a last resort, but if you’ve failed all other attempts (education and communication foremost among them) to combine an agile team with a rigid power structure, blocking may be your only alternative to maintain the agility necessary to reach your goal. Use a blocker if you need to get through the project, but after that, step back, evaluate the situation and consider rethinking your approach to software development.
Scott W. Ambler is a senior consultant with Ronin International Inc. His latest
book is The Elements of UML Style (Cambridge University Press,
2002).
