Self-managing and self-organization in software development teams
Ed Gibbs in his blog posts a comment on self-managing teams that deserves some additions.
He mentions that "[he does] have fears that some stuff gets left behind by making everyone a developer [self-managing team]".
He specifically mentions that
I would beg to differ on these statements. The point with self managing teams is not to change the process of defining a leader (which is nominated by management in non-self managing teams), the point of "self managing teams and organizations" is to do away with the need to name a leader all together, the team is it's own manager, which in practice means that everybody is a manager, not just that everybody is a developer.
What I mean to say with this statement is that everyone in the team has responsibility over the organizational integration of the team, not just "a manager" (named by the team or not). If you need to buy hardware the team is responsible for buying that hardware (or starting the purchasing process, depending where you work). If a room needs to be designed then the team designs that room, not management. If someone needs to go to higher management with some proposal/request, then the teams define that proposal/request but they can name one or two (or more) people that go there and represent the team.
The goal with self-managing teams is not to make everybody a developer, it is to make the team fully responsible for it's results, and this includes tasks that would normally be assigned to a manager.
There is one problem however with the current traditional "MBA/old school" style of evaluating performance in self-managing teams: MBA's and old schoold managers forget that people are intelligent enough to evaluate themselves! In a case described in the book "Maverick!", Ricardo Semler states that they actually asked people to name their salary. What happened? Most people actually asked for a salary lower than what management was ready to pay (in some cases they actually had to say "no, you deserve more!"). Those that asked for crazy salaries (very few) eventually left the company anyway so problem solved.
Of course a self-managing team needs to be able to self-evaluate also (I have some experience with that which I could share in another post). Management needs to take the leap of faith if they are to rip all the benefits from self-managing, self-organizing teams.
Find this story interesting? Let others know: Digg it!
at
21:30
He mentions that "[he does] have fears that some stuff gets left behind by making everyone a developer [self-managing team]".
He specifically mentions that
Most organizations just have a lot of administrative stuff that someone has to take care of to keep everything rolling along. And someone has to focus on things beyond the project at hand. In a team of developers [self-managing team] who does one-on-ones, fills out the purchase orders for a new build box, or makes sure time sheets get signed off and approved?
I would beg to differ on these statements. The point with self managing teams is not to change the process of defining a leader (which is nominated by management in non-self managing teams), the point of "self managing teams and organizations" is to do away with the need to name a leader all together, the team is it's own manager, which in practice means that everybody is a manager, not just that everybody is a developer.
Everybody is a manager
What I mean to say with this statement is that everyone in the team has responsibility over the organizational integration of the team, not just "a manager" (named by the team or not). If you need to buy hardware the team is responsible for buying that hardware (or starting the purchasing process, depending where you work). If a room needs to be designed then the team designs that room, not management. If someone needs to go to higher management with some proposal/request, then the teams define that proposal/request but they can name one or two (or more) people that go there and represent the team.
The goal with self-managing teams is not to make everybody a developer, it is to make the team fully responsible for it's results, and this includes tasks that would normally be assigned to a manager.
The Evaluation pitfall
There is one problem however with the current traditional "MBA/old school" style of evaluating performance in self-managing teams: MBA's and old schoold managers forget that people are intelligent enough to evaluate themselves! In a case described in the book "Maverick!", Ricardo Semler states that they actually asked people to name their salary. What happened? Most people actually asked for a salary lower than what management was ready to pay (in some cases they actually had to say "no, you deserve more!"). Those that asked for crazy salaries (very few) eventually left the company anyway so problem solved.
Of course a self-managing team needs to be able to self-evaluate also (I have some experience with that which I could share in another post). Management needs to take the leap of faith if they are to rip all the benefits from self-managing, self-organizing teams.
Find this story interesting? Let others know: Digg it!
RSS link
3 Comments:
I'll just give an example of how it should work: Our team needed external monitors, so we got them (late because of supplier problems, but anyway with minimal fuzz). A while ago on an afternoon my monitor broke down, so I filed a ticket to our internal issue tracking. I said I didn't need a replacement immediately as there was another inferior screen I could use. I was asked two details, and the next morning some delivery guy came with a working monitor and took away the old one.
Surely a job of management in an agile team is to provide what Joel Spolsky calls the development abstraction layer so that developers can focus on development. Also developers must be open about what they need, and management must be open about what can be provided and by whom. Openness and trust in these communications makes the two parties understand how important the needs and costs are, so that they can cooperate in advancing the development with the very different means that they have available.
This relationship I find very similar as that between the developers and the customer; you're working in the same team, but with different skillsets, points of view, and stakes in the project.
As a manager, make your developers feel happy and in control, and make them understand the financial and other limitations that they must live with, and you'll have great results.
By
Anonymous, at May 18, 2006 6:40 AM
The point about management providing an "abstraction layer" is important. A self-organizing team is definitely more productive if they don't have to take care of all kinds of details that do not directly contribute to their productivity. However this abstraction layer must not be confused with having "a manager" for the team.
The team should and must have a leader, a facilitator, but if the team is empowered to make their decisions they will be more productive then if they are depending on "a manager" who is going to be a bottleneck anyway and must be handled that way (theory of constraints anyone?).
I see my role as "a faciliator" of self-organization, once I've helped the team self-organize I get out of the way and keep out of the way unless they explicitely ask me to help.
If you do this I can guarantee that the team will be much more productive.
By
Unknown, at May 19, 2006 6:44 PM
Good observations. I might add that the ability of the team to obtain hardware may depend on the organizational context. Timo describes a case when the team was able to handle that autonomously. In our organization (a large company), individual agile delivery teams do not have the authority to order hardware because the company practices centralized procurement as a cost management technique.
In that case, the development abstraction layer becomes all the more important. Our agile teams include a role we call "Team Lead" whose responsibility includes handling things like ordering hardware and dealing with non-agile parts of the organization on which our projects have dependencies, such as the security department and so forth. It is similar to the role of Scrum Master, with a little bit of conventional management responsibility thrown in. It's important to note that, consistent with your comments about self-organizing teams, the Team Lead does not decide when the team needs new monitors, etc., but only handles the logistics of getting the monitors. The role is mentioned briefly here.
When you say that people are smart enough to evaluate their own performance, it reminds me of the idea of Amish performance reviews. I'm not sure if a reference to Amish culture makes sense in Helsinki, but I think you can see how it would work on a well-functioning agile team. Obviously, the ability of a team to self-manage their performance assessment depends on having the right sort of people on board.
By
Anonymous, at May 30, 2006 5:31 PM
Post a Comment
<< Home