Once at a seminar I asked if anyone knew what empowerment meant. No one knew! Why is empowerment fundamental to agile? One way to show this is to look at the opposite: 

Un-powerment

Inspired by Esther Derby’s drawing here, this is what I came up with. With visualization like this you can ask if empowerment would make a difference to your efficiency.

High Performance Tree

Lyssa Adkins showed us how to communicate core values using the High Performance Tree metaphor. Read about it in the excellent and very useful book Coaching Agile Teams, or watch it live on youtube. Nail up a High Performance Tree on the wall, explain how endeavouring the PDM values (tree roots) yield effects of stronger people, stronger group and stronger agreements (tree branches). These effects will in turn give us more ideas, better ideas and so on (fruits). To see all the fruits in full bloom, so to say, you might want to revisit the tree in part 1.

Team Radar

Team Radar, from zero in centre out to ten. Lines connectiong points.

The Team Radar is a simple procedure that helps tracking team progress toward values. You can visualize where the team feels it stands today, and you can reason on how to improve towards your values.

- What could be improved the most?

- Is our understanding of where we are different? Why?

- How can we improve?

The illustration shows a radar where each team member has marked four dots on the axes, for where he/she thinks the group is living up to the values. The low score on shared responsibility suggests there could be an issue with specialized roles.

Iterate

With this setup you now have the tools to review and measure progress. Do a new radar in next iteration and see how progress is going, or even better,  try other new innovating excercises! Refer to the tree metaphor, and don’t forget to enjoy the fruits from it!

Why all this Core Values talk?

Why talk about values? Why not just say what people should do? It would be much easier! In Scrum that would perhaps sound something like this:

- We have four meetings, three artifacts, three roles, and some rules to tie this together! 

When you head on like this without any motives you are very close to a stick-and-carrot leadership style. It’s not that you don’t need to teach rules and methods (like above), but it will not be enough if you want your teams to get empowered.

Shared goals

So, in addition to the above we need to raise questions about how we do our work. Consult the people involved. Question the tools used!

The steps to reach a shared vision (Senge, et al. 1994)

- Why are we doing Scrum?

When you reason around the values and possible benefits from those, the methods gets justified. Also, people might see ways to modify the tools and methods, to something more suited for their context. This will make people feel more engaged, motivated and hence become more empowered.

This will help you to gain some steps on Senge’s ladder to a shared vision (even though we’re not working with shared visions explicitly in this topic).

PDM Core values

Ok then, enough of all this meta-talk. We want team to get more empowered, and we want to know how to apply PDM to do this.

In Sam Kaner’s book Facilitator’s Guide to Particitatory Decision-Making you’ll find four PDM core values.

• Full partitioning: all members in the group are encouraged to participate
• Shared responsibility: all people in the group feel responsibility for the decisions being made
• Inclusive solutions: everybody’s perspective are taken into account to get wiser solutions
• Mutual understanding: people needs to understand each others needs and goals to get stronger agreements

Great! This allows us to get started the right way! The PDM core values helps us to get motives for working with PDM, and in turn PDM will get us more empowered with the rest of the stuff we do.

(We obviously did not quite get out of the Nine Circles of Meta, did we? Just bare with me, we will soon get to the fruits of this.)

Next: PDM in Scrum, part 3: The tree metaphor, revisited

Once I joined a team that said they did Scrum. The team had two communicative people and two quiet people. The planning meetings were completely dominated by the talkative ones. The quieter did not talk at all. I tried helplessly to boost quiet people, but I did not succeed:

Participatory Decision-Making, core values as the roots.

I told everyone what would happen. I could see the signs because I was assigned to be the project leader. The task was doomed and I had no choice but to refuse the assignment. “What I can offer is myself in a coaching role” I told them. I thought that I could do the visualization-trick, show everybody how to do the hansei and then we could all jump on the kaizen-train.

“Oh, by the way, the team will not get time to gather requirements. Who will do that work?” I asked.

“That must be you”, the chief said (the person behind the interesting deadline) and looked at the IT-coordinator (the person behind the tiny budget).

OK then! I can do coaching, which I love. Hopefully we can achieve lots of stuff here! Me and the team got started, and we set up Scrum-but for visualizing what was not doable. Great team! Engaged people we were, all of us. Much enjoyment. And already after the first two-week sprint, even before we lacked the non-existing requirements, we noticed things were worse than expected. Maintenance work is taking up almost all time from the team. “Wow, we must visualize, and escalate to the customer”. We did! But frustrating enough, no actions are taken. March on.

So here we are today. My small amount of hours has run out (a month before deadline) and it remains only to do one final project retrospective. The plan is to summon the team, the chief and the IT-coordinator. We must all face the reality and talk to each other. If the impossibleness can be visualized, then we can motivate ourselves to ask what we can do to avoid same journey next time. What can we improve? What do we need to learn to manage delivery? We realize that the team must be the problem, and obviously the team is too small. There aren’t even anyone who can gather the requirements, since no one has the time. So we need more people, and thus we need to work with budget. The first reactions are not unexpectedly a bit inprogressive: “but we cannot change budget”, “I think that you do not understand how budget works” (expressed directly to the facilitator), “If we ask for a budget, then we would only get a tiny portion”. So I talk about different tools for achieving goals, like “art of the possible”, “focus on / focus off”, “no whining” and “no blame-game”. And then I again ask how we can achieve delivery before deadline. Silence. Finally, chief says:

“Well… maybe we could lift the budget-question to higher instance.”

All this happened yesterday. Today IT-coordinator called me to have a meeting with chief tomorrow. Those who’s alive will see… .

- I love anecdotes, but I really believe that yours would be better if they weren’t so long.

It was important to bring this issue to the surface, but unfortunately I failed! I couldn’t hide my frustration. I let the sarcastic face out! My colleague reacted unhappily and told me he appreciates me for being direct, but warns me from being this direct with our customers. They might get very annoyed.

I wonder what would have happened if I stopped him immediately when things began to feel bad, before I had crossed my boiling point. Perhaps he would have been more open-minded? One thing is sure, I definitely would’ve managed to give him a nicer feedback.

I believe this (long) story relates quite good to what Esther Derby wrote in this post. Don’t wait with giving feedback! Because that will probably only appear as insincerity and lack of trust.