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.
Community comments
Corporate behaviour
by Tim Murnaghan,
Re: Corporate behaviour
by Amr Elssamadisy,
Re: Corporate behaviour
by Deborah (Hartmann) Preuss,
Waterfall
by Ben Holland,
Blocking is more than protecting the stars
by mike dwyer,
Corporate behaviour
by Tim Murnaghan,
Your message is awaiting moderation. Thank you for participating in the discussion.
In line with Scott's answer is "blocker" a pattern or a smell? Yes ;)
Actually the title blocker is concentrating too much on the negative aspects of corporate life and runs the risk of falling into the "evil beaurocracy" stereotype. I coined the term "Square Peg Adapter" as a pattern that we had to follow to plug in the agile square peg team into the corporate round hole.
For example, somebody has to get the overall development budget approved. Having a team building relationships with the business by delivering certainly helps with that - but it isn't the whole story.
Re: Corporate behaviour
by Amr Elssamadisy,
Your message is awaiting moderation. Thank you for participating in the discussion.
The mirror image is that we're seen as elitists/geeks/non-conformers/trouble-makers, etc.... Damn those touchy-feely problems!!!!
Re: Corporate behaviour
by Deborah (Hartmann) Preuss,
Your message is awaiting moderation. Thank you for participating in the discussion.
Amr, I'm not sure I see what you're referring to... could you elaborate?
Waterfall
by Ben Holland,
Your message is awaiting moderation. Thank you for participating in the discussion.
We are currently working in a organisation which is very hierarchical. The development process is a typical waterfall. Design is only completed by senior architects. They then pass the design to architects who then write a low level design. In the "perfect world" the developers would only get their hands on the low level design. Commercially this seems very expensive. Oh, and as usual there are no clear requirements and anything near to a requirement exists in the design documentation as a proposed implementation.
I was charged with running the development team and I was pretty unhappy with the above. In order to mitigate our risks I adopted an agile approach. One way of looking at it is that I have used the agile development as a negotiating tool. The team can say we are doing our bit. We are driving out requirements that have not been thought of in the design. But, more importantly our progress is clear to all the stakeholders. Yes, we have tweaked a few noses. But, we now have a backlog and I hope an agreed way of working. It is not pure agile (if that exists). But, the development team are now able to own the solution with their colleagues in the architecture team and we are also able to drive out the requirements before we develope a component in the backlog.
Blocking is more than protecting the stars
by mike dwyer,
Your message is awaiting moderation. Thank you for participating in the discussion.
I can assume that Scott is neither an Amercian nor a Canadian football fan as his description of a blocker is as limited as the notion that all these 'very large guys on the front line" do little more than protect the quarterback. The Offensive Line as they should be referred to, are the people who move the team forward by being in constant contact with the opposition. This can be in a passive manner, as in pass protection where the quarterback gets 2 - 4 seconds to toss the ball to another 'standup guy', or it can be in a proactive manner that supports 'running with the ball'. In either case the Line adapts and inspects, removes impediments, and gives the team every opportunity to meet its objectives.
In software development, the ScrumMaster works in a similar, equally intense and team oriented manner to move the team forward - every day, every play. Your team is not just the developers it is everyone working with you to get the job done.
All of this if for nothing if the stars can't catch the pass, or get to the hole fast enough, but the scrummaster, like the lineman, gets up heads back to the line and works with the team to get better.
What causes the smell is when the team can't get their act together. The resistance, elitism, antipathy will grow as you score better, faster, and smoother so be ready for it and just play harder and keep everyone's focus on who is delivering. Be transparent about it as well.