Self managing/organising teams: Hey Scrummaster, let the team decide!

[Peter Janssens]

A self-organizing team is a powerful concept. But what if the team collectively decides to go into a direction that you as a Scrum Master know for sure that they will hit problems. (or at least you think)

F.i. they decide to abandon retrospectives. Will you respect their decision or will you try to change it? Would you go for option 1) respect the team or 2) try to convince the team away from their decision.

May I ask you, intelligent agilist, to provide examples of similar conflicts you encountered in real life. If you solved the situation, please let us know how. If not, just post the conflict.

Feel free to give input if you prefer related intresting topics like
>when is a team truly self directing
>how do you create a self directing team
>what competences does a team need to have in order to be self directing
>what if they go in the wrong direction (according to whom?)
>the role of project leaders and managers wrt self organising team
>products owners having trouble not telling teams HOW to do the work

If our session gets selected, we will present your feedback at the XP Days Benelux 2008.

20-21 November 2008
Eindhoven, The Netherlands
http://www.xpday.net

Be welcome!

[Michael]

Have not solved this situation, but believe I have contributed towards this goal. I find that team members must feel like (and actually be) a part of the strategy sessions. By this I mean, in your typical organization directives (in the form of strategic objectives) come from the top down. I rather believe that it is the front-line workers, with their specialized skills and unique experiences that make them who they are should be involved in setting direction. For truly, only they know what they can accomplish and what they are capable of. In this way, far-reaching and unattainable goals are not set by people totally disconnected from the process/team. For me, this has proven effective in cultivating a team that wants to succeed and can, because they have been consulted for their expertise and contributed to setting overall strategy. They know what is expected, and have more "skin in the game" because they were a part of setting those expectations. This begins creating a team that takes ownership and accountability for what they do each day. In the long term, should also create a team that can truly manage themselves and adapt to the constantly changing business environment more quickly than a traditional top-down managed team.

[Peter Janssens]

Michael,
thanks a lot for your valuable contribution.
Do you mind if I ask for some clarifications, I might not understand it all in detail yet.
- "This begins creating a team that takes ownership and accountability for what they do each day. In the long term, should also create a team that can truly manage themselves...": why do you say "in the long term"? When you take ownerhip & accountability, haven't you started yet self managing?
- What kind of strategy did you have in mind: product strategy (usually taken care of by the product owner), engineering strategy, corporate company strategies (eg business development decisions, financial restrictions, etc..), or other kinds of strategy?

[Michael]

Hi Peter,
In a fast-paced world, I tend to view "in the long term" as 9+ months, but you are absolutely correct...teams that take ownership and accountability for what they are doing the team is beginning to "self-manage".
In terms of strategy, I apologize if I seemed vague...intending to speak of corporate/company strategies.

[Peter Janssens]

Michael,
hmmm... intresting. Must be a challenge to enable team members to contribute actively and in a qualitative way to decisons like "Will we expand first in India rather than in China?" or corporate budget decisions. As it is not a developers core area, how can we make do this also in an efficient way? How can we deal with confidential matters????
Do you have practical & succesful experience in larger companies?

[Michael]

I'm from the non-developer side. I do have experience in larger companies (I am on LinkedIn.com) and the front-line can be consulted on all sorts of non-confidential matters and strategic decisions (such as, should we continue to use XYZ claim system or develop our own?). The idea of having one "core area" of competence is fine in some industries, but I am finding that individuals are not going to be hired just because of one core area, rather their collective experiences and business acumen are what companies today are valuing. Therefore, we must give workers the opportunities to move outside of their comfort zones and find new areas of skill and ways to contribute. A team full of developers might not be as capable in becoming self managing, as say, a team of business analysts or customer service associates.