I’ve been thinking a lot about Scrum in the last few weeks. Scrums done a fantastic marketing job for itself, so much so that Scrum is now the poster child for Agile.
However there are aspects of Scrum I find troubling. One of these is the self-organizing team. Its not that I have anything against a self-organizing teams, in fact I’m all for them. And although I don’t talk about them in Changing Software Development much of what is written there implicitly advocates teams taking on organization for themselves.
No, what troubles me is the system within which self-organizing teams are expected to exist.
My first worry is that such teams are culturally incompatible with many organizations. Many (perhaps most) organizations are set up as command-and-control structures. As much as I’d love to have a revolution and change the whole organization I do not expect this to happen overnight. Self-organizing teams will often need to exist within command-and-contol organizations.
Some organizations will be open the occasional self-organizing team and will tolerate them. The team itself needs to recognise the boundaries of its self-organization and while it might seek to spread the idea it shouldn’t expect the whole organization to understand, the team needs to learn to interface to a hierarchical structure.
And in other companies the organizational immune system will actively try to ejects the self-organization team as counter-cultural.
A while ago I heard about a French bank in London which tried Agile development - it may have been Scrum I don’t know. Things went well to start with then the Business Analysts in the organization rebelled. They didn’t like the way the team was working and told management so. The experiment was closed down.
My second worry is that we might be asking too much of self-organizing teams within a hierarchical environment. Specifically, teams can (and do) change what is within their control but they exist within a system and they have limited power to change the system.
As W Edward Deming would point out: we should not blame the worker, or look for the worker, to fix a problem which is actually part of the system. The system needs to create the environment in which workers can do their best work. When the system stops the best possible work then it is they system that is at fault.
This is the thinking behind Deming’s point 10:
“Eliminate slogans, exhortations, and targets for the work force asking for zero defects and new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force.”
So, if we place a self-organizing team (or even a semi-self-organizing team) in a system which creates problems we cannot expect the team to fix the problems. There are limits to what the team can do. It is management’s job to create the environment.
I have been a vocal advocate of people trying to fix these kind of problems in their organizations. Indeed I actively urge people to try and address these problems. Until you try and fix a problem you don’t know if you can fix it or not.
Those of us who help organizations improve the way they work - including the adoption of Agile methods - need to recognise when a team can change the way they work and when they system the team exists in needs to be changed. And when the system needs changing we need to decide how far we go in changing that system.
However there are aspects of Scrum I find troubling. One of these is the self-organizing team. Its not that I have anything against a self-organizing teams, in fact I’m all for them. And although I don’t talk about them in Changing Software Development much of what is written there implicitly advocates teams taking on organization for themselves.
No, what troubles me is the system within which self-organizing teams are expected to exist.
My first worry is that such teams are culturally incompatible with many organizations. Many (perhaps most) organizations are set up as command-and-control structures. As much as I’d love to have a revolution and change the whole organization I do not expect this to happen overnight. Self-organizing teams will often need to exist within command-and-contol organizations.
Some organizations will be open the occasional self-organizing team and will tolerate them. The team itself needs to recognise the boundaries of its self-organization and while it might seek to spread the idea it shouldn’t expect the whole organization to understand, the team needs to learn to interface to a hierarchical structure.
And in other companies the organizational immune system will actively try to ejects the self-organization team as counter-cultural.
A while ago I heard about a French bank in London which tried Agile development - it may have been Scrum I don’t know. Things went well to start with then the Business Analysts in the organization rebelled. They didn’t like the way the team was working and told management so. The experiment was closed down.
My second worry is that we might be asking too much of self-organizing teams within a hierarchical environment. Specifically, teams can (and do) change what is within their control but they exist within a system and they have limited power to change the system.
As W Edward Deming would point out: we should not blame the worker, or look for the worker, to fix a problem which is actually part of the system. The system needs to create the environment in which workers can do their best work. When the system stops the best possible work then it is they system that is at fault.
This is the thinking behind Deming’s point 10:
“Eliminate slogans, exhortations, and targets for the work force asking for zero defects and new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force.”
So, if we place a self-organizing team (or even a semi-self-organizing team) in a system which creates problems we cannot expect the team to fix the problems. There are limits to what the team can do. It is management’s job to create the environment.
I have been a vocal advocate of people trying to fix these kind of problems in their organizations. Indeed I actively urge people to try and address these problems. Until you try and fix a problem you don’t know if you can fix it or not.
Those of us who help organizations improve the way they work - including the adoption of Agile methods - need to recognise when a team can change the way they work and when they system the team exists in needs to be changed. And when the system needs changing we need to decide how far we go in changing that system.
Hi Allan.
ReplyDeleteYou're hitting a hot spot here.
I guess I have a pretty similar feeling on the topic. There is quite a friction between the "Ideal Self-organizing team" and the organization within the team actually moves.
To be honest, I must credit Scrum to have taken this problem into account, while XP keeps it in the background. But the way organization reacts might differ a lot.
Organizations where Software Development is preminent are likely to be diffident at first, but also to look for results. If some sucesses are achieved the path could be relatively easy (well ... it's NOT easy, but it's better than somewhere else).
Organizations where SD is not a core activity, will put more and more obstacles on the way to a perfect Scrum implementation, and explicitly or implicitly fighting it. It takes guts to fight for a good cause, but this does not always allow for a victory. I guess in many cases the only possible option is to step back and find a reasonable trade off. You must not call it Scrum, and maybe not even a more generic "Agile", but still it can be better than what it used to be in place before. Such organizations are generally so dysfunctional that being 20% better than before can still result relatively easy (even if frustrating).