Part VI: Advice on Solving Common Challenges With Scrum

The Intent of this section

My experience is that virtually all of the challenges people adopting Scrum have are due to Scrum’s lack of incorporating Lean thinking into it. In 2007 I suggested that considered Scrum to be a partial implementation of Lean would make it better. At the time I didn’t know Flow or the Theory of Constraints applied to knowledge work. Now I do.

All of the topics in this section come from either people asking me questions directly or from posts I see on LinkedIn lamenting a problem they are having in Scrum. The intent of this chapter is:

help people having trouble with Scrum
teach a basic Lean-Agile concept
help people migrate from Scrum to Lean-Agile

Improving retrospectives

I hear many (mostly Scrum) coaches complain about the poor efficacy of retrospectives. Things like:

“Retrospective meetings are mainly complaint sessions; there never is a follow-up on action items from previous sprints”
“People aren’t motivated in the retrospectives, but mostly just go through the motions.”

I also see this, but mostly for retrospectives in Scrum, done at the end of the Sprint as mandated.

To solve this problem, we should take a system thinking and flow perspective.

We need to stop asking why people aren’t motivated and ask how they are being demotivated.

Let me be clear that I am viewing this issue from the perspective of systems thinking and flow. Neither of these are in Scrum. While Scrum allows flow within the sprint, that’s not that same as coming from flow. There is a big difference.

First off, what is the purpose of a retrospective? There are many

Acknowledge the good that’s been done
Detect and discuss impediments
Select a few of these to solve
Step back and see the bigger picture
Team building – solving problems together

Amplio suggests taking a systems thinking perspectives and look to see how retrospectives have been set up that may be causing the aforementioned challenges. Flow suggests the question “are they being done at the right time?” Be clear, I’m not worried about whether I’m doing Scrum or not, I’m concerned with improving the quality of the team and how they work. For 1 and 4 above, the end of the sprint is a good time. But for detecting problems and solving them, it’s not.

To make things clearer, let’s say we have a two-week sprint. Looking for challenges at the end of the sprint means we’re, on average, detecting them one week late. Consider it’s the end of the sprint, we ramped it up at the end to get things done, and now we discover we weren’t working as well as we should. Who likes that? It is easy to make yourself wrong thinking these things should have been detected sooner – and they likely should have.

Regarding solving problems, Scrum doesn’t provide guidance here. The consequences of “purposefully incomplete” to avoid complexity now rears its head. Scrum does not provide guidance for fixing your problems here. It can’t because it doesn’t provide first principles. It would have to have a magnitude of solutions to all sorts of problems – it’d be overwhelming.

But there is another way – one I’ve been imploring Scrum’s thought leaders to adopt but which has been typically called bashing. It’s to use the first principles discussed in Flow, Lean, and the Theory of Constraints. Also include how to tell which practice will be better based on proven theory so you don’t always have to run “fail fast” experiments.

The challenge Scrum folks have not considered is that many of those adopting Scrum are late adopters and aren’t going to figure things out. This is the main cause of ScrumBut. After a while they get frustrated and try things without a good understanding. If Scrum did “inspect & adapt” on itself people might notice that Scrum’s design is setting this up and perhaps they wouldn’t blame the folks using it. Again, this is systems thinking.

The solution to improving retrospectives is to recognize the differences in what you are trying to do. Use a flow model for learning and detect errors quickly.

We must also acknowledge the implications of Edgar Schein’s maxim – “We don’t talk and think about what we see, we see what we are able to talk about.” We do have to be “purposefully incomplete”, but we also need to be sufficiently incomplete.

Making Retrospectives Better

Having virtual boards to do retrospectives with is also useful. The figure below shows one you can get this one and more by joining Success Engineering’s free Amplio Community of Practice.

But the main way to get retrospectives to be better is to solve your problems when they arrive. There are two ways to do this. One is to have an agreement among team members to try to solve challenges as soon as they are detected. It often doesn’t take the full team to do this. This will both improve the quality of the team’s workflow as well as have less to deal with at the end of the sprint.

The second option is to have a short retro in the middle of the sprint. This can be just 15 minutes. If you combine this with the idea of only having daily Scrums when they are needed, you can schedule this somewhere in the middle of the sprint and have it whether a daily Scrum is necessary or not. This can be a quick review of what’s going on.

The other key thing is to not try to solve too many of the challenges discussed during the retrospection. Typically, just one or two items need to be improved. Then the team will appreciate the progress being made.

When the Product Owner wants to insert something at the end of a sprint

Sometimes a PO asks to insert something into the sprint is the correct thing to do, even if breaks the sprint goal. Take a look at the attached picture.

Now it’s true you could just break the Scrum goal. But first, that doesn’t feel right, and second you’re still not focusing on the right things. Having POs have to break sprint goals to get the right work done will not endear Scrum to them. In fact, it’ll make them feel like Scrum isn’t working.

It explains three ways to do your work:
1. Scrum without MBIs.
2. Scrum with MBIs.
3. Driving from MBIs (a Lean approach).

If a team is focusing on MBIs (not usually done as I don’t know of any Scrum trainer who includes them – let me know if you do), then the PO can say – “this change is more important than what’s in the rest of the Sprint.” It makes sense to insert it and it doesn’t cause any waste. Of course, it won’t be Scrum.

<< Part V: Consultant’s Corner

Appendices >>