So, you are on a development team that is adopting Agile or thinking of going in that direction. You may be considering Scrum, any of the other Agile methods, or your own hybrid. If you are adopting Agile by starting small, you probably are working against-the-grain in your organization. You may have heard that there should be a role that protects the team from the rest of the non-Agile world. Or, you may have heard the exact opposite - that this is a sign of a dysfunctional team and leads to an Us vs. Them smell and local optimizations. Which is it? How should you should you implement the ScrumMaster or equivalent role?
In early 2003 Scott Ambler wrote Running Interference where he starts:
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.
Scott then gets real and suggests how a team might deal with sub-optimal conditions:
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.
InfoQ recently interviewed Scott about the dangers of this type of blocking:
InfoQ: Is blocking good or bad?
Scott: Yes ;)
As I wrote, it should be done only as a last option. You should try to educate the others in the techniques that you're using and just as important find out what they're trying to accomplish. Many times just getting together and talking will solve many of the issues. When that doesn't work then you may find that you have to block, which is unfortunate but the only strategy which enables you to succeed.
InfoQ: Should the ScrumMaster be the blocker?
Scott: This can be done by anyone on the team. It might be a rotating role but often it's taken by the most senior person/coach.
InfoQ: Doesn't this create an Us vs. Them mentality? Would you agree that this mentality usually inhibits successful adoption?
Scott: Yes, there is a significant risk of this, and its probably not a good thing. We need to work together to understand what each group is trying to achieve. I've found that many agile developers have fallen for some of the rhetoric around the "evil bureaucracy", often because they don't really understand the bigger picture. The agile movement has done a lot of good things for bringing greater discipline to developers, but in other respects it exacerbated some of the prejudices and blind spots with less experienced developers.
InfoQ: Then what is the alternative? How should a team go about adopting Agile to increase its value and still deal with others who are doing things differently?
Scott: Find out what the goals are of those other groups. If you can show that you are addressing those goals in an agile manner, then you can often move forward. Maybe you'll discover what they're asking you to do actually makes sense.
This is not the first time this issue of blocker has been discussed, it is a recurring question that we have covered previously on InfoQ.
So if you are adopting Agile in a non-agile environment you may need a blocker - but do so with caution. Beware of Us vs. Them smells cropping up. Listen to the non-agilists - they are also doing their best to do a good job and help the organization.