The Grumpy Scrum Master

September 17, 2014

grumpy dwarf

“Going against men, I have heard at times a deep harmony
thrumming in the mixture, and when they ask me what
I say I don’t know. It is not the only or the easiest
way to come to the truth. It is one way.” – Wendell Berry

I looked in the mirror the other day and guess what I saw? The grumpy scrum master. He comes by sometimes and pays me a visit. Old grumpy looked at me and I looked at him and together we agreed that perhaps, just this one time, he just might be right.

We sat down and had a talk. It turns out he’s tired and cranky and seen this all before. I told him I can relate. We agreed that we’ve both done enough stupid to last a couple of lifetimes. No arguments there. He knows what he doesn’t like – me too! After a little debate, we both agreed we don’t give a damn what you think.

So we decided it was time to write a manifesto. That is

We grumps have come to value:

Speaking our mind over listening to whiners

Working hard over talking about it

 Getting shit done over following a plan

Disagreeing with you over getting along

That is, while the items are the right are a total waste of time, the stuff on the left is much more gratifying.

 


Personal Value Stream Mapping

September 3, 2010

As a project manager, a scrum master, a team lead, or even as an agile coach I’ve wondered from time to time about the true value that I bring to a team. You see, to me it is entirely plausible that a team could work just fine without any of the aforementioned roles being present. In fact, I know that there are many teams that are quite successful without a project manager on the team. That goes for scrum masters too. It has always been a difficult question to face with any intellectual honesty.

Recently I picked up Mary and Tom Poppendieck’s latest book, Leading Lean Software Development. She uses frames to illustrate some of the successful and unsuccessful approaches to software development over the last 40 years. She deals rather harshly with what she calls the Project Management Frame. Basically, if you accept their take on modern project management it is wrong-headed on a number of different levels and is the source of a great deal of waste and very little value in the overall business value stream. Speaking as someone who basically operates in this role, it’s a pretty harsh toke. Having spoken with her about it, I get the impression that when she talks about project management, she doesn’t make any distinction between scrum masters, XP coaches, or traditional project managers. They are all separated from the work and using “management” to manipulate or measure the teams with metrics that at best serve no useful purpose and at worst cause a great deal of harm. Now I know there are those who might argue these points vociferously, but Mary and Tom are pretty darn smart, so I think there is some merit in considering their viewpoint seriously.

What value do project managers provide to the business value stream? Please note that I’m using the term project manager very loosely. It includes Scrum Masters and other leaders of that ilk. Well, perhaps the best way to answer that question would be to build your own personal value stream map. Take a recent project and see if you can list all of the activities that you engaged in as part of delivering that project. Line ’em up in chronological order, identify the wait steps and the queues and see what your personal efficiency, from the perspective of the team value stream is. It might look something like this:

  1. Release Planning
  2. Sprint Planning
  3. Daily Standups
  4. Retrospectives
  5. Reviews/Demos
  6. Resolving Impediments
  7. Release Coordination
  8. Change Control
  9. Tracking (taskboard, etc.)

So…if I look at that list, what activities are value adding from the customer’s perspective? Oooh, that might be a pretty short list:

  1. Reviews/Demos
  2. Resolving Impediments
  3. Release Coordination

All the other stuff is just “process” overhead without any intrinsic value. That leaves a pretty darn short list. Facilitating reviews/demos is certainly not much of a unique skill. You can do that without a PM. Easy. How about resolving impediments? Well, that sort of depends on how many you resolve…and even then, resolving impediments is not the exclusive domain of the PM/Scrum Master. Finally, there is only release coordination. Some people do that, others don’t – it depends on the organization. And does release coordination represent value to the customer? Would they pay for it? Maybe…

Perhaps that’s a brutal assessment of the value of a team leader. I tend to be that way. Others may be more forgiving. What it tells me is that, at least in my case, if I’m not eliminating a LOT of impediments, I’m probably not contributing much direct value to the team. They really don’t need me for those other activities. It’s the impediment removing that represents the real value. And you don’t need a PMI certification to remove impediments…or a CSM certification…or a title…

Interesting.


The Team Touchstone

April 2, 2009

A touchstone is a rock used to compare valuable minerals. If you took a known quality of gold and rubbed it against the touchstone it would leave a streak or mark on the face of the stone. Then you could take a mineral of unknown quality and rub it against the rock next to the first streak you made. A good touchstone would allow a visible comparison of the two streaks to be made. In this case, if the streaks matched, then presumably the second sample was also gold. If they didn’t match – no gold. Sometimes an acid might be applied to the streaks to further help clarify if they were the same substance or not.

So a touchstone is a tool used to compare the quality of two samples. It occured to me that as Scrum Masters we also act as a touchstone for our teams. Our job is to help the team see how the changes that they have made have improved the way they work. Of course we need to have a starting sample to compare against. In this case, the starting sample – what we might think of as the gold standard – is plain Jane, do it by the book Scrum. Scrum is our starting point. It is the process baseline against which we compare our process improvements. Some might argue that any process would work as this standard, but I think there is a certain elegance and simplicity to Scrum that lends itself to using it in this manner.

So we put Scrum into place for our teams and establish a baseline, We try it out for a sprint and review how it works for us. Then we change it. We tweak the process to make it work better for us. We try out new ideas, new practices, new ways of working together that enable us as a team to potentially perform better. How do we know the changes are an improvement? By comparing them to Scrum.


Trust Your (Bleep)ing Team!

July 20, 2008

Here is an issue that has come up over and over again – scrum masters and product owners that don’t trust the teams they work with. I’ve struggled with this problem myself over the years, so I can definitely relate to the mistrust. Here’s my favorite example:

Sandbagging: The team is not delivering 100% of their stories each sprint. The team is not pulling as much work as you would expect each sprint. Everyone is coming in late and leaving early. No one is staying late nights to make sure that stories are absolutely done before the end of the sprint.

There you are as the Scrum Master, tearing your hair out in frustration, trying to figure out how to get the team to step up and deliver. Well, if this goes on for very long, you end up not trusting the team. After all, their commitments seem to mean little, they just go through the motions, etc. Of course, here’s a news flash – they don’t trust you either. In my experience, teams can almost always read you like a book. They know it when you don’t trust them. They know it when you think it’s “their” problem. They aren’t stupid. This just further increases the sense of alienation between the two sides. It further limits your ability to be an effective member of the team.

I think that often times when we get to that place of mistrust we are doing something very fundamental and very destructive to the relationship with the team. We are making the problems, what ever they may be, someone elses problem. It’s the team’s problem, not yours. It is something that is inherent in their nature – they are somehow flawed. If they would just somehow, “Get it” then our problems would be solved. Of course nothing could be further from the truth. The fact is that everyone plays an important role in this dance of trust. If you really want to address the problem, you have to be ready and able to take responsibility for your part in the problem. Because as scrum master or product owner, you are part of the problem, like it or not.

So what is the solution to this problem? Trust your (bleep)ing team! That’s right, get that mistrust monkey off of your back – take it from me, that particular simian has nothing constructive to offer. Let the team know that you trust them completely – 100%

You’re never going to make significant progress as long as you and the team distrust one another. Guaranteed.

Then start looking for the impediments that are holding them up. Maybe the first and most difficult impediment to remove is any mistrust we may have with the team.


Enter the Dragon

February 6, 2008

bruce_lee2.jpg

A friend recommended that I try giving the team kudos using a kung-fu theme. A beer and a Bruce Lee flick were all it took to get me started. The names have been changed to protect the innocent…

————-

So there I was last night watching Bruce Lee’s classic “Enter the Dragon”. This movie has everything: the bad guys were *really* bad (this one had a removable hand that he could replace with a claw). And the good guy, well, he was *really* good. Bruce did everything with such authority. You watch him and he just owns the screen. He freezes after every move, as if to dare his opponent to even breath in the presence of his superiority. Bruce is so good that he doesn’t even need to wear a shirt. He suffixes each lightning fast strike of his iron hand with a high pitched cry that rings out, “EEEAAAAWWWuuuhhh!!!”

It makes the hair on your arms stand on end. Chills run down your spine. I don’t know of many things that came out of the 70’s that can rival this movie for sheer greatness.

Cut to the present, I’m sitting in on a Scrum planning meeting with a team. I’m watching the scrum master work with his team to determine what they are going to do in the next sprint. Right before my eyes I witness the team in action, executing moves worthy of my crime fighting hero, Bruce. A team member takes a story, and the scrum master asks for an estimate – and then he freezes. You can feel the air in the room actually stop circulating…

“EEEEAAAAWWWWuuuhhh!!!”

It was magnificent! Then another team member pulls a story off the backlog – there is a brief flash of post-it notes – so fast that the human eye can barely follow it, and the scrum master is there again asking for an estimate – and once again, just like in the movie, he freezes…

“EEEEAAAAWWWWuuuhhh!!!”

In a matter of minutes, none of the tasks were remaining. The team had collaboratively defeated their collective enemies, bad planning and poor commitment. I checked the hair on my arms – it was standing up.

Did I mention that the scrum master *was* wearing a shirt?

Best regards,
Tom


A Lesson from the movie “300”

December 1, 2007

So, you’ve experienced the Agile transformation now. Your team has a planning meeting, everybody goes to the stand-ups, and you do the obligatory review and retrospectives. You might even deliver some value to the customer every now and then. Sure, it’s an improvement over what you used to do, but it’s hardly living up to the hype.

Bob the tester is still pissed off that nobody ever listens to him (they call him the “Bob the Test Monkey” behind his back). Joe, the senior developer, knows that this Agile stuff is just another management fad – give it a year and it will all blow over. So he refuses to really engage, and bitches constantly about the number of meetings he has to attend. There’s Frank, the scrum master who moved to Agile because the boss told him too. He thinks it’s great, but he’s really a hands off kinda guy and tends to skip things he doesn’t think are necessary, like rigorously tracking impediments. And it seems like everyone else on the team is just waiting for something to happen.

This is a classic scenario where the team is technically “doing Agile” and they still suck. And I would argue that it is by far the most common scenario that teams moving to Agile methods find themselves in. This is where teams struggling with these issues start groping for the “silver bullet” that will solve their personnel issues. The fact of the matter is that these sorts of issues aren’t solved by methodologies. A process won’t fix these problems. It might make them more visible, but it isn’t going to resolve them for you. These problems are hard. Really hard. These problems require courage to resolve.

Have you seen the movie “300” or read the graphic novel? OK, regardless of what you may think of the movie, there is a scene that captures the essence of this dilemma. The setup is this: The king of the Spartans, Leonidas, is leading a hand picked team of 300 of the very best of Sparta’s warriors to defend Greece from invasion by the Persian armies of Xerces. It is almost certain death for the Spartans, for there are only 300 hundred of them against a Persian army that numbers in the tens of thousands. Yet the Spartans march forth into battle relishing a glorious fight. They know that they are the best fighters in the world. They and their comrades are bred to be the best fighters from childhood in a relentless training program. Only the toughest survive. So we know that this team is the best of the best.

On route to the battle a Spartan goatherd confronts Leonidas and asks to join the ranks of the Spartans going to battle. Unfortunately, the goatherd is hideously deformed. In this scene, he begs Leonidas to join the 300. You can tell that the goatherd yearns to prove himself – he wants nothing more in his life than to fight alongside the rest of the magnificent Spartan warriors (and their lovely six packs…). Leonidas considers the request, then asks the goatherd to raise his shield above his deformed shoulders. He can’t manage it. Leonidas rejects his request to fight with the Spartan soldiers. The goatherd is absolutely devastated. He is left behind as the Spartans march off to their destiny.

Was Leonidas cruel to reject the goatherd? Here we have someone who wants to be a part of the team. The softy in me says, “Go ahead Leonidas, let him join the gang. Give him a chance!” Everyone has something they can contribute. Rejecting the poor deformed goatherd just feels too awful. You can see the burning, pleading desire in his eyes – how can you snuff that out?

But that’s just what Leonidas does. However he’s not cruel about it. He is brutally honest. He honors the goatherd with a frank assessment and doesn’t pull any punches. Leonidas already has the perfect team. To admit another member to the team with a weakness only serves to weaken the team as a whole. In fact, its possible that Leonidas admires the goatherd’s dedication, but he doesn’t let that get in the way of pointing out his tragic flaw. The fact is, there are certain things that Leonidas just can’t compromise on.

So let’s return now to our Agile team. As we survey it, unlike the Spartans, we already have members with weaknesses. They’re easy to identify, usually everyone on the team is perfectly aware of them. If Bob the tester doesn’t have the testing skills the team really needs, then a hard decision needs to be made. If Joe isn’t engaged, odds are we are putting the whole team in jeopardy of failure. And Frank the scrum master is the one who should probably be responsible for confronting these sorts of issues – only he’s a “hands-off” kinda guy.

What would Leonidas do? He would confront the problem head on. I can guarantee you that Leonidas is not a “hands-off” kinda guy. I bet he would ask Bob the tester to raise his shield. And if Bob couldn’t manage it – then it would be time for that hard decision. Confront the problem without compromising the dignity of the person involved. Once it is identified, bring it to the team for discussion and resolution. OK, this last bit probably isn’t something that Leonidas would do, but there are no Kings on an Agile team either.

How about Joe the dev? Someone has to have the guts to step in, one on one, and confront the issue. And Frank the scrum master? With any role on any team, there are certain things you are responsible for that can’t be compromised. For scrum masters it is performing the fundamental rituals of scrum. There are plenty of areas for compromise and flexibility within development projects, but there has to be a bottom line somewhere.

In my experience, people tend to shy away from this sort of confrontation. Let’s face it, it can hurt. But if we expect ourselves and our teams to be the very best, then we have to hold each other accountable to the highest standards. That means confronting weakness when we find it. Not because we want to be cruel, but because the only way we can overcome it is to identify it first.

So the next time that you find yourself wondering what to do about that sticky issue on a team, ask yourself “What would Leonidas do?”