PDM in Scrum, part 3: The tree metaphor, revisited
continued from part 2: PDM core values
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!
PDM in Scrum, part 2: PDM core values
continued from part 1: Elevating empowerment
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 participation: 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.)
PDM in Scrum, part 1: Elevating empowerment
How can the team be motivated to work with empowerment?
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 also had trouble in participating myself. Not a good feeling! The planning meeting had been more effective if the talkative persons had done it by themselves. I was not feeling very empowered, and the quiet people looked unhappy.
- to provide tools for working with empowerment
- to communicate the effects of these tools
- to motivate, with the benefits from these effects
So, enter…
Sam Kaner’s Facilitator’s Guide to Participatory Decision Making.
If you search on PDM – Participatory Decision-Making, you find that the term is synonymous with Employee Empowerment.
How does PDM fit with Scrum?
The core values in Scrum, Commitment, Openness, Courage, Respect and Focus, has lots of references to empowerment. I mean, if you would remove empowerment from Scrum then there wouldn’t be very much left. The applicability of PDM in Scrum is obvious. PDM is like a bunch of techniques that the facilitator can use to elevate a team’s empowerment.
Breaking deathmarch with project retrospective
After practicing two months of classic deathmarching, we finally arrive at a much-needed project retrospective. There are no surprises here, we all knew that it was a deathmarch. It was not a difficult thing to predict, you would with no problem also see the signs: fixed scope, fixed budget and fixed deadline. And the budget’s way too small. Not even close.
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… 
.
Real-time feedback practice
A colleague has this habit of telling anecdotes that are by far too long. They are so long that my mind finally does not manage to stay alert. So today, after another long story ended, I said:
- 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.
What I think would’ve worked better:
- I have a problem with this story because I cannot relate it to the purpose of the meeting.
In this way I open a dialogue for work with the process insetad of blaming the other part. Also, there are no judgments as comes with the example’s word “better”.
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.
