Management 3.0 - Empower Teams

Editor's Notes

1. 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.
2. 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
3. See book: page 115-117
4. See book: page 111-112
5. 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.
6. 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
7. 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
8. 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.
9. 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
10. 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
11. 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
12. 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
13. So these are the four types of trust. A manager needs to work on all of them.
14. Now we get more practical...
15. See book: page 127-129
16. 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.
17. Put the 7 levels of authority horizontally on a board.
18. List all key decision areas (only the ones that are worth communicating and discussing).
19. Determine which teams or individuals are authorized to do what, and at what level.
20. 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.
21. You must treat delegation as an investment. It doesn’t pay back for itself immediately. It takes a while...See book: page 133-134
22. 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.
23. 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. 
24. 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.
25. 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.
26. Another example: suppose only one person chooses 7.
27. 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.
28. 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.
29. I show this slide on screen while people are playing the game.
30. 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.
31. 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.
32. 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.
33. Once again I explicitly ask people to give feedback on the feedback door, before they leave the room to go home.