« June 2009 »
S M T W T F S
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30


Monday, 8 June 2009
Success factors for self-organizing teams
Topic: Agile management

The notion of the self-organizing team is fundamental to agile thinking; but not everyone agrees that self-organizing teams are practical. As for me, I think the viability of the self-organizing model depends on the team members, their management, their organizational context, and (possibly) on the nature of the work they do. If we limit the discussion to software development teams, then I would say there are three critical success factors for growing effective self-organizing teams.

1. Clearly define the boundaries. The team has well-defined boundaries within which they may feel free to self-organize and self-manage. Without this, teams aren't sure how far they can go or how much they should attempt to do to manage themselves. When people are uncertain about this, they tend to err on the side of caution and do little or nothing without asking management's permission. That pretty much nullifies the benefits of self-organization.

2. Tolerate mistakes and allow time for learning. The organization is tolerant of mistakes and of learning-curve time. All too often, management declares teams to be "self-organizing," and the first time the team makes a mistake they step in and take "control" of the situation. Once management does that, the self-organization experiment is finished. It will take a very long time and considerable effort before teams will believe management is serious about allowing them to try and self-manage again.

3. Keep the team challenged, yet not frustrated. The team's administrative or functional manager is sensitive to the team's limitations, and adjusts boundaries and expectations carefully so as to provide the team with sufficient challenges to keep them in a state of learning and growing, while not expecting more of them than they can handle. I think it is unlikely that every team in any given organization will be at the same level of readiness and maturity for self-management. Each team will need its own boundaries and challenges so that the organization as a whole can improve its effectiveness.


Posted by Dave Nicolette at 10:25 AM EDT
Post Comment | View Comments (1) | Permalink

Sunday, 22 November 2009 - 6:14 PM EST

Name: "Neil Murphy"

Years ago someone had the concept of a development team as a surgical team.  The chief developer was the surgeon and might have one or more assistant surgeons.  There would have various specialists supporting the developer (tools person, tester, admin etc).  There was someone who 'managed' things, but this person was not necessarily more important than the persons who actually produced.  The manager in that sense was the facilitator for the 'surgeon' and the team.

So I would suggest the role of a PM in an agile world is to facilitate the team in producing, by running interfernece, coaching, mentoring, facilitating administering etc, and even managing of required.   With that role in place a team can be as self-organising as is required by the organisation or as the team wants to be or can be.

 

View Latest Entries