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:

I lacked skills for getting whole team up and running!

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.
What if I had been able to better motivate the benefits from empowerment. What if we had tools for working with our dysfunctionalities. What I needed was
  • 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.

Next: PDM in Scrum, part 2: PDM core values

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… ;-).

You see the project had fixed scope, fixed budget and fixed deadline. Yes yes yes the old story once again…

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.