Blog

The Three Signs of a Miserable Scrum implementation (Markus Gärtner)

On December 17, 2012, in Syndicated, by Association for Software Testing
0

Probably the ugliest thing about going to conferences is that you pick up a lot of books to read. That even held for XP 2012 in Malmö, Sweden, although I just attended the first day at the tutorial of J.B. Rainsberger & Ruud Wijnands on Agile Coaching. They recommended two books from Patrick Lencioni for my to-read pile at home, The Five Dysfunctions of a Team and The Three Signs of a Miserable Job. While getting close to finishing the latter one, I noticed that the three signs of a miserable job map easily to signs that your Scrum implementation is miserable as well. Here’s the rationale.

Irrelevance

In the book, irrelevance is the second sign mentioned. In my daily work I consider this the probably most important early warning sign. When your team seems irrelevant about the work it is doing, then they are not putting hard efforts in it. They are unlikely to put in extra hours, probably working from 10 to 4, and will not care about the code they are writing, the product they are creating, or the customer to start with.

That’s bad.

Why? Well, if the product is not relevant to your team, then the feedback you get about the product will also be irrelevant. But Scrum is all about feedback. You get feedback every second week in the review meeting; you get feedback every two weeks on your team cohesion in the retrospective; you get feedback every day in the daily standup meeting; you get feedback every second during a pair programming session. But with irrelevant that feedback becomes a waste of time – for you and your team.

Instead, your team should know about the product, they should know the product backlog for the next planning horizon, and they should be able to know why the code they build today matters to someone. In the book, the manager Brian makes people aware about in which way their work is relevant to someone else. With T-shaped team members there are two dimensions in which individual team members make relevant changes to someone around them.

First, there is the product dimension. You should know at least the ProductOwner. As a team members it is even better if you actually know the end customer. Only then will you understand the troubles people can have using your product.

On the second dimension, in a team you contribute the larger product. As a T-shaped team member you have special skills, and a broad general basis of skills. With your special skills you contribute to the team, and help others be more effective. As a tester that means that you can teach your programmers how to come up with better tests. As a programmer you can help automate some particular daunting task for a tester. As a database specialist you can help your tester check results in the database. This is the reason why we prefer pair working a lot: by working together we become aware of how we contribute to the larger team.

Immeasurement

Although software engineering might be an idea which time has come and gone, without feedback on how relevant my work is to someone else, I won’t notice when I miss opportunities to improve my job. If I don’t know if a particular change in my behavior caused a particular change in the relevance of my work to someone else, then I will soon stop paying attention to my work, how it impacts others, and soon my work will become irrelevant again.

But, what should I measure on an Agile team? Considering the T-shaped team member discussion from before, the most relevant things are probably customer satisfaction and team mood. A while ago my then-colleague Bernd Schiffer wrote a blog entry on three different measurements for reporting success of an agile pilot to top management. In it, he proposes to use customer satisfaction, release burn-ups, and a happiness index like a niko-niko calendar. The first and the third measurements seem to be just about the customer and the team happiness. The second measurement is a bit more interesting though.

Why would we need a release burn-up? Because we forgot one other group of people to which our work is relevant as a Scrum team: the management. Especially when introducing a new methodology like Scrum, coming from a background of probably missed release dates, and undercommitment for a long time, a release burn-up provides management not only the necessary transparency for the team, but more meaningfully reminds the team from time to time about these dates.

And as the book The Three Signs of a Miserable Job recommends, I would also make it transparent to the team as a manager that you rely on them to deliver on time, and your team’s work is relevant for you.

Anonymity

That brings me to the final point: anonymity. If your teams don’t know their team mates, their manager, or their customer, then it’s unlikely they can build a good product for these people that should be relevant for them. If team members don’t know each other, they don’t know personal preferences, personal struggles, and they will have a hard time coming along with each other. So, celebrate your successes – every single sprint. Go out for dinner when you delivered a working product increment. Maybe head for a team event out in the evening. Enjoy yourself as part of that awesome team.

Even more, ask your manager to join you after the release has been delivered successfully. Maybe he can step in taking the bill that evening. This might sound touchy-feeling, but if you do work for an anonymous person, you are unlikely to put the best of your effort in.

Finally, if you don’t know your customer, if you don’t know his work, and if you don’t know how she is going to use your product to help them do better work, then you are speculating. Instead leave the office for two or three week, join your customer in the daily work, and then come back, and build the awesome product that she deserves. You will have a better understanding of what is needed, what is giving your customer a hard time, and surely you will have exchanged some war stories from previous products, and you will avoid stepping into the same problems again with your product.

So, according to these three simple measures, how’s your Scrum implementation going today?

PrintDiggStumbleUpondel.icio.usFacebookTwitterLinkedInGoogle Bookmarks

 

Comments are closed.


Looking for something?

Use the form below to search the site:


Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!