BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Blocking: Useful? Dangerous? Ethical?

Blocking: Useful? Dangerous? Ethical?

Bookmarks

George Dinwiddie commented on a discussion that took place in the eXtreme Programming yahoogroup about "blocking" as described by Scott Ambler:

This is a great example of something that I call blocking, where you produce the paperwork, attend the meetings, pretend to care, ... to make it look as if you're following the "official process".

Although George sidestepped the question of ethics ("I'd like to skirt the ethical issue, which ultimately must be decided by each person"), he pointed out that blocking can have side-effects, as can be seen in the context of the Polaris project, a discussion of which spawned this discussion thread, as described by John Ross:

The story is that PERT was a Potemkin Village kind of thing. They did it to keep the auditors and Congress off their backs while they got the job done.

Then people actually started believing the scam...

George Dinwiddie analysed this result and extended it into an analogy of the effects of blocking:

First of all, note the reported outcome of the Polaris project and PERT. If it is true that the project did not use PERT to manage the project, but merely to keep the project auditors at bay, it's quite ironic that the end result was strengthening the belief that those with oversight of a project should direct how the project is managed. The long-term effect has been more intrusive auditing, not less.

Perhaps this should not be surprising. If we fool people, we shouldn't be surprised that they draw some unwarranted conclusions. Would this same principle not apply in the situation Scott describes? If you merely produce documents and attend review meetings of them without any regard to what's actually happening on the team, won't this reinforce the belief that such documents and meetings are necessary?

He concluded with an alternative strategy based on an Aikido phrase:

I've never been a fan of the martial arts, but I've learned an Aikido phrase from Jerry Weinberg that's useful in many situations: "Center; enter; turn."

Center: be aware of yourself, who you are, and what you want to accomplish.

Enter: be aware of the other. Enter their world and stand beside them, rather than in opposition.

Turn: together with them, turn their energy in a more effective direction.

When I can do that, I'm much more effective than when I try to block them.

Donald Gray joined the discussion:

Scott Ambler's "blocking" doesn't bother me. I don't see that giving management the information they need, in the format they need it, a problem. If doing this allows the team to continue working on their tasks providing value (via working software) to the clients, I'm all for it. It sounds to me like part of a Scrum Master's job: remove impediments.

...

Finally I saw what bothered me, another example of insufficient views. The team has a view of what they need. Management has a view of what they need. Both sides have their view point. But because of some communication disconnect, my view and your view never become our view. The communication had reduced to a management/team, us/them mentality. In reality there is not management without a team, and no team without management. Like "mind" and "body" one needs the other to exist.

If you'd like to read further, you can follow the discussion on eXtremeProgramming newsgroup, on the ethics of blocking, the success/failure distinction or continue reading other news and articles in InfoQ's Agile Community.

Rate this Article

Adoption
Style

BT