SlideShare verwendet Cookies, um die Funktionalität und Leistungsfähigkeit der Webseite zu verbessern und Ihnen relevante Werbung bereitzustellen. Wenn Sie diese Webseite weiter besuchen, erklären Sie sich mit der Verwendung von Cookies auf dieser Seite einverstanden. Lesen Sie bitte unsere Nutzervereinbarung und die Datenschutzrichtlinie.
SlideShare verwendet Cookies, um die Funktionalität und Leistungsfähigkeit der Webseite zu verbessern und Ihnen relevante Werbung bereitzustellen. Wenn Sie diese Webseite weiter besuchen, erklären Sie sich mit der Verwendung von Cookies auf dieser Seite einverstanden. Lesen Sie bitte unsere unsere Datenschutzrichtlinie und die Nutzervereinbarung.
My personal story here is that, after the introduction of Scrum in our organization, I was faced with decisions to be made concerning story points, meeting rooms, sprint lengths, etc. I left all those decisions to the teams. There was only one requirement I had for all teams: planning meetings would have to take place on Mondays. Because otherwise it would be very inefficient (at the organizational level).You will have to come up with your own personal story that reflects empowerment/delegation.
Most Agile books seem to assume that organizations come from the ordered part of the spectrum, and have to “let go” over strict management. But many other organizations (like in my own experience) are in the chaotic part of the spectrum. They need a little bit more management. (I did that by imposing Scrum, and it worked.)See book: page 102-103
See book: page 115-117
See book: page 111-112
Authorization usually starts with shareholders who authorize top managers to grow a business with their money. These top managers hire and authorize other people to do work. This leads, quite naturally, to a hierarchy. But that is the only thing a corporate hierarchy is good for: authorizing people and making sure each person has only one boss.
I don’t know any other good word for empowerment, even though it has been overused in management literature. So I will stick to it for now.See book: page 112-114
This is often the problem with managers: they fear they become powerless when they hand over authority to other people.See book: page 124-125
I explain here that I became more powerful after introducing Scrum in the organization, because (despite plenty of issues) it seemed to work nicely. And because top management liked it and saw the results, I became more important in the eyes of top management for having changed the organization in such a positive way.
Some managers forget to tell their teams that they trust them.If you explicitly tell people you trust them you may increase their commitment and loyalty.See book: page 138-139
I have seen managers requiring certain behavior from employees (for example, “be more disciplined”) while they rarely showed such behavior themselves (for example, never being on time in meetings).You destroy trust if you don’t lead by example and show the behavior you also expect from others.See book: page 139-140
Sometimes team members keep asking the manager to help them solve issues. This may be an indication that they don’t trust each other enough to make good decisions. You can increase trust between people in a team by not giving them solutions to their problems. Let them figure it out together first.See book: page 140
This seems a bit cheesy. But I have it from a book by Scott Berkun. If you don’t trust your own behavior, if you don’t live up to your own value system, then how can you expect other people to trust you?Trust yourself first, before building trust relationships with others.See book: page 140-141
So these are the four types of trust. A manager needs to work on all of them.
Now we get more practical...
See book: page 127-129
Authority boards are a very new concept, not described in the book. I have received a few reports since I published the first articles about it of teams using them successfully, but it is far from a mainstream topic. Still, I want to show it because it nicely reflects the way of thinking of an Agile manager: delegate as much as possible by using some kind of information radiator.
Put the 7 levels of authority horizontally on a board.
List all key decision areas (only the ones that are worth communicating and discussing).
Determine which teams or individuals are authorized to do what, and at what level.
The nice thing about this approach is that there is an urge to make things flow from left to right, just like a regular task board.
You must treat delegation as an investment. It doesn’t pay back for itself immediately. It takes a while...See book: page 133-134
Like 100% code coverage a fully self-directed team (all key decision areas at level 7) is the ultimate goal that you will never reach.
Hand out the playing cards to each table. Ask them to distribute sets of 7 cards among each other.Check that there are at least four people at every table. I don’t think the game works well with only tree people.Make it clear that it is more fun for people to come up with their own stories from personal experience.Some groups make it easy and simply read off the 10 stories from the paper.Maybe you can find a way to incentivize people to think of their own stories.
Make sure everyone pays attention to these examples. They make it quite clear how it works.Suppose 3 people at the table choose 6, the others choose 4 and 5.You always look at the highest number that was played, in this case 6.
If the people with the highest number are not a minority, everybody wins points.But you only win points according to your card’s value.
Another example: suppose only one person chooses 7.
In that case everyone wins points except number 7, because 7 is now a minority at the table.Conclusion: in order to win points choose as high as possible, but without becoming a minority at the table.
Make it clear that the most value in this game is achieved by discussing the lowest and highest card values that were chosen. The other stuff (calculating points and playing again for the same topic) is optional.
I show this slide on screen while people are playing the game.
Some possible questions:What effect did the points have?What effect did the discussions have?I usually point out that the game is actually skewed when people have different projects and teams. In that case it is hard to compare the choices for authorization, because such choices should be context-dependent.It is probably even more interesting to play the game with one team and its manager. Then they all have the same context.
It is now time to discuss the most important challenges that were written on sticky notes earlier in the course.This is the 4th part of the course so we usually end the day after this module.
I make a central action list on a wall, and I ask the group at the end of the module which concrete practices they think most managers should do regularly. They can be practices that I have suggested in this module or other practices they suggest themselves.We will review the entire list of practices at the end of the course.
Once again I explicitly ask people to give feedback on the feedback door, before they leave the room to go home.
View #2: Empower Teams<br />Teams can self-organize, and this requires empowerment, authorization, and trust from management.<br />
Agile software development works because of<br />self-organizing teams<br />
management<br />self-organization<br />self-organizationis often complex, not chaotic<br />Sometimes it needs a littlemanagement<br />
Managers are like gardeners<br />They let self-organization (anarchy) do useful work<br />while steering the system toward valuable results<br />
But HOWdo we grow<br />a valuable self-organizing system?<br />
Well, NOTby putting a<br />control center on top of a living system<br />
Distributed being<br />A complex system is more than the sum of its parts, and the “extra” stuff is distributed over the system. It cannot be attributed to any single authoritative part. <br />Control from the bottom up<br />In a complex system, everything happens at once, and problems ignore any central authority. Therefore overall governance must be spread among all the parts.<br />Kelly, Kevin. Out of Control.<br />Boston: Addison-Wesley, 1994, page 469<br />
We distribute authorization with...<br />Empowerment<br />Yes, there is that<br />buzzword again...<br />
Empowerment<br />is implementing distributed control by delegating authority<br />
Delegation<br />“Delegation (or deputation) is the assignment of authority and responsibility to another person (normally from a manager to a subordinate) to carry out specific activities.”<br />http://en.wikipedia.org/wiki/Delegation<br />
Managers empower people,and distribute control,to prevent the system itselffrom breaking down.<br />
Question:<br />Does handing over power to others make you<br />powerless?<br />
Answer: NO<br />Non-Zero-Sum<br />Zero-Sum<br />Free markets<br />Social networks<br />Teamwork<br />…<br />We all win!<br />Football<br />Elections<br />Judiciary<br />…<br />I win and you lose<br />http://en.wikipedia.org/wiki/Zero-sum<br />
Non-Zero-Sum<br />Powerful teams make their managers more powerful.<br />
Trust your people(communicate this clearly)<br />
2) Earn trust from your people(consistent behavior)<br />
Help people to trust each other(mingle, don’t meddle)<br />
4) Trust yourself(stay true to your own values)<br />
Key Decision Areas<br />Make explicit list with“areas of authorization”<br />Prepare project schedules<br />Select key technologies<br />Set documentation standards<br />Etc…<br />People should not walk into“invisible electric fences”<br />Reinertsen, Donald. Managing the Design Factory. New York: Free Press, 1997, page 107.<br />
Key Decision Areas<br />However…<br />Authorization per key decision area is not a “binary” thing<br />Reinertsen, Donald. Managing the Design Factory. New York: Free Press, 1997, page 107.<br />
Situational Leadership<br />Four different “leadership styles”<br />Telling<br />Selling<br />Participating<br />Delegation<br />Work your way to level 4<br />http://en.wikipedia.org/wiki/Situational_leadership_theory<br />
Situational Leadership<br />However…<br />It might be good to distinguish between informing people (push your opinion) vs. consulting them (pull their opinions)<br />
RACI Matrix<br />Involvement depends on tasks<br />Responsible<br />Accountable<br />Consulted<br />Informed<br />Make explicit what people can expect from whom<br />http://en.wikipedia.org/wiki/Responsibility_assignment_matrix<br />
RACI Matrix<br />However…<br />Key decision areas are better than tasks, and there should be no separation of accountable versus responsible in Agile teams<br />
We will now mergethe ideas behind the previous examples...<br />
The Seven Levels of Authority<br />Tell: make decision as the manager<br />Sell: convince people about decision<br />Consult: get input from team before decision<br />Agree: make decision together with team<br />Advise: influence decision made by the team<br />Inquire: ask feedback after decision by team<br />Delegate: no influence, let team work it out<br />
Relocate to other office building<br />Replace waterfall with Scrum<br />Select new team members<br />Choose logo for business unit<br />Select architecture or component<br />Sprint length and deliveries<br />Coding guidelines and pairing<br />EXAMPLE<br />
The optimal level of authority depends on people’s competenceand the organizational impactof decisions<br />
The ultimate goal is a<br />self-directed team<br />(but usually not attainable)<br />
Game: Delegation Poker<br />Find Delegation Poker Cards, and Delegation Poker Stories<br />One person picks a story and reads it out loudOR tell a story from personal experience<br />Everyone choose (privately) one of the 7 cards<br />After everyone has decided, show all cards<br />Everyone earn points except the highest minority(see examples…)<br />
Game: Delegation Poker<br />Keep track of the points people earned (optional)<br />Let both highest and lowest motivate their choices<br />Play it again for the same topic (optional)<br />30 minutes<br />
Tell: make decision as the manager<br />Sell: convince people about decision<br />Consult: get input from team before decision<br />Agree: make decision together with team<br />Advise: influence decision made by the team<br />Inquire: ask feedback after decision by team<br />Delegate: no influence, let team work it out<br />