Monday, January 05, 2009

The Use of Self-Managing Teams Outside the Context of Software Development

[Note: this post was heavily edited on Jan 18th to take into account comments on the earlier version.]

Most of what you need to do to become Agile requires only re-arrangement of what you are already doing. For instance, managing a backlog is still a process of deciding which work to do and in which order to do it, it isn't something that boggles the mind and makes people say "some people might be able to do that, but I don't see how we could." Managing what work to do with a backlog is like tuning an engine. It is straight-forward to explain, learn, and implement. Whereas, moving from conventional management to self-managing teams sounds like moving from steam to internal combustion. It is completely different and not well understood. But wait, what exactly are self-managing teams?

The terms “self-organizing,” “self-managing,” and “self-directing” have been used to mean many things, but are generally thought of as being in the same ballpark. In this post I will use the term “self-managing.” While looking for other writing on the topic prior to writing this post, I found that it is a poorly defined topic within the Agile literature.

What the Heck is a Self-Managing Team Anyway?
What sort of management does self-management apply to? What is the scope? Does it just apply to how I manage myself on my pre-assigned tasks? Does it only apply to project management? Does it mean dealing with hiring and firing? What about budgets? Some folks have taken it to mean that there is no manager, that the Scrum Master is the manager, etc. Sure, there are lots of short sections on self-managing teams in Agile books and articles, but it is not much more than a vague description of the concept repeated in different ways by different authors. This is not a criticism, only an observation that self-management it is an underdeveloped area of Agile.

In the Poppendieck's "Implementing Lean Software Development" there are four pages on "Self-Directing Work", most of which talks about project management. Kent Beck's "Extreme Programming Explained" takes self-management for granted without specifically talking about it. Ken Schwaber's book "Agile Software Development With Scrum" contains a couple of paragraphs on self-organization but mostly takes it for granted. In general, most of the material on the topic assumes that you will be doing it and there are practices which are meant to support it, but there is no in-depth discussion of exactly what it is and how to do it.

In searching the web for a more in-depth treatment, I did find one really good article by Esther Derby in the December 2008 issue of Better Software Magazine entitled "What's a Manager to Do?" This article gives a good overview of the concepts as well as some pitfalls and how to avoid them.

I had better luck finding reference material on self-management by looking outside of software development all together. At some point during my searching, I accidentally left off the keyword "Agile" and discovered that there are whole books on self-managing teams, and they have nothing to do with software development at all. I ordered three of them and am currently in the process of reading them. I'll post new entries as I go.

Here are the books on my reading list related to self-managing teams:

Business Without Bosses
Leading Self-Directed Work Teams
The Wisdom of Teams

Apparently, people have been promoting and practicing self-managing teams completely outside the realm of software development for quite a while. While it holds promise, it does not yet seem to have become a widespread practice. If it is still in its infancy in general, is it really a good idea to promote it in conjunction with all of the other parts of Agile which, IMHO, are much more straight-forward and are closer to our core-competencies as an industry?

Even though self-managing teams are not well defined or described in Agile, it doesn’t really matter. There are actually many no-brainer “self-management” oriented Agile practices that are straight-forward and beneficial in their own right. The fact that they may get us closer to creating self-managing teams is a side benefit.


Anonymous said...

Some times you have a great manager and you work great together and he helps you be productive.

But most of the time (Especially in the kind of organizations that are desperately looking for a solution like Agile) that is not the case.

Most of the time the system is broken and if you're being productive at all it is DESPITE management.

This is when Agile's self direction and Scrum masters (to counter act the managers) are an improvement

Vlad from Avid Inc.
(A happy AccuRev customer)

Kate Carruthers said...

In a scrum implementation at a large company last year I explained how the process worked to some managers & they all looked really uncomfortable (even squirming in their chairs). Upon asking what the problem was one of them blurted out "but you're asking that we trust the staff!"

I laughed & said yes - but they were really worried about trusting their staff & could not embrace that idea. No surprise then the scrum implementation in that place turned into little waterfalls not to long afterwards.

Trust and clarity of role and purpose are critical for self managing teams. Most managers actually seem incapable of either. So self managing teams are off the agenda for many places.

For the record, some of the best places I've worked we were allowed to self organise and achieved amazing stuff!

Damon Poole said...

Vlad and Kate,

Thanks for your comments. I agree with all of your points. But where is the dividing line? What is "management?" It seems that many people have different opinions on the scope/definition of "self management." For instance, I've heard some folks say "oh, that just means no more top-down project management, everything else stays the same." I've heard other folks give a definition that sounds a lot like a Scrum Master.

I should clarify that I have no qualms with the well-defined aspects of "self-management." For instance, having developers be responsible for estimates instead of a manager is clearly spelled out in Scrum. Estimation is part of management, but it is in the realm of project management.

The term "self management" is so nebulous it could mean just about anything. What does it mean to you? Where would you draw the line?

Anonymous said...

Self-organizing teams have been around for a long time, and were popular in manufacturing a few years back.

There's a spectrum that covers self-organizing/self-managing/self-directing...not sure there's a bright white line that divides them.

You have to look at the context and the people involved and draw the lines based on what makes sense and will contribute to achieving results. And then you have to have the conversations so that people (both managers and team members) understand where those boundaries are.

I'd be interested in hearing which books on self-org teams you are reading, and whether you find them useful.

Esther Derby

Damon Poole said...


Thanks for your comments. You mention that "self-organizing teams ... were popular in manufacturing a few years back." That's sort of what I'm wondering about. What happened? If it didn't stick, will that repeat itself with Agile? Is software development a better place for self-management to thrive?

I see that you have a book on management called Behind Closed Doors . I really liked your article on self-management, I will have to check out your book!

The books I just picked up on self-management are:

Business Without Bosses
Leading Self-Directed Work Teams
The Wisdom of Teams

I haven't gotten far enough to comment on them, will post a new entry when I have.

Anonymous said...

Jim & Michele McCarthy organize a one week workshop called BootCamp to learn people to become aself-organizing bootCamp.
The do that using the Core protocols.
These protocols have been created by all the teams that have been booted.
I am biased as I have been organizing these BootCamps in Europe after following one.

I have a few books on building trust. You can find my list on Librarything

Anonymous said...


Nice post.

I don't know much about Agile / XP / Scrum (hey that's why I'm here!) but I do think that self-managing teams' effectiveness is almost entirely predicted by the quality of the people (be they ditch-diggers or a team of PhD researchers)

The problem with a lot of developers is that they get distracted, pursue things that are interesting but not necessarily useful or needed, etc... When you have a focused, cohesive team (due to deadline, due to interesting work, etc...) there is almost no obstacle the team can't overcome. It's times like this that management, whose job it is to assist staff & remove obstacles, becomes more of an obstacle itself.

Well, that's my perspective anyway....

Damon Poole said...


Thanks for your comments. Distraction is always a problem! That's one of the nice parts of short iterations and backlogs; they keep you focused on the here and now and working on the top priority stuff from your customer/market perspective.

Looking forward to more of your thoughts,


mawi said...

Came upon your post while actually googling for something completely different.

I recommend Hackmans work when it comes to self-organizing teams. Depth and pedagogy.

Re self-organizing in manufacturing, many articles document that manufacturing/assembly facilities turned from sociotech style organizing of manufacturing teams towards lean style teams. The difference being that the lean style focuses on process improvements, standardization and more specialization. You cant have kaizen without standardization (something that seemingly eludes many in SW).

However, I think the whole manufacturing analogy largely irrelevant.

İnanç Gümüş said...

I am the CTO of our company and I am w/our team full day, so I know how they are working at full capacity.

And then, our CEO told me: "You say that we need to trust our Scrum team, that's OK for now because you are w/the team as a Scrum Master. But when you have more than one team which you are not directly involved w/them like today how would you able to know are they working at full capacity? Because, trusting everyone w/eyes closed seems a real danger to me."

Also, he asked me about compensation programs, incentives etc. And also explained that we should not pay the same salaries to everyone etc. And, even there is a peer pressure, if everyone gets paid in equal salaries, the team would work as its weakest member's power...

Difficult questions like these should be answered too. But, I have not found satisfying information about them.

What do you think? Also, could you recommended some books about these topics too?


Damon Poole said...


The value of the team is in their work results, not their moment to moment productivity. In my experience, team productivity has much more to do with how well the team feels about itself than with how closely they are watched.

If you are doing Agile and measuring velocity, then if the velocity drops, ask the Scrummaster what they think is happening. If the retrospectives are functioning well, they will know.

As for compensation issues, that is not a topic I am well versed in. The most/best I've seen on that topic is by Mary Poppendieck.



İnanç Gümüş said...

Yes, that's true: we should look at the results. But. When our team also defines the size of the work so they become the definers of the results too. They say: 'this will take 5 points' and it does not happen mostly.

Maybe it depends on the product owner who needs to define the results for that smallest time w/most valuable work.

But in agile, the team is never fails accountable but never fails, the others are wrong (organization, management etc). Agile needs us to trust people blindly which can be very dangerous.

If a team never produces the results how hard the product owner is trying to do for months, then the team should take the accountability and be disintegrated.

What do you think? Usually, I don't think from that way, but, for the moment I think that way.

Damon Poole said...


Agile is not an excuse to do whatever you want and there is no intent that you trust people blindly in Agile. It is also not a way to escape accountability. In fact, it provides the kind of transparency that makes accountability much easier to accomplish.

Yes, you need to trust the team while they are in a sprint, but if they cannot produce what they commit to, then something needs to be changed.

If the Scrum Master says that there is too much outside interference, perhaps there is. It does frequently happen that outside attempts to "help" actually make things worse! :-)

Another possibility is that the team is just taking on too many story points. While it may seem like going in the wrong direction for them to do fewer points, it is better to commit to fewer points, but get all of the stories to a done state and establish a healthy cadence. Once things are going more smoothly, it is likely that their velocity will naturally increase.