(Inauguration speech of Franklin D. Roosevelt, president of USA during WWII)
The end of the year is only two sprints away. We are in a refinement session.
“So, would it still be feasible to deliver the ‘A+flow’ by the end of the year if we do it like this?” The PO asks the team. He is standing in front of a white board full of scribbles holding a marker in his hand. He just gave in on reducing the scope by slicing the functionality even further to a point where he will be having difficulties to explain the stakeholders what the value in this slice is. He even has difficulties explaining it to himself.
The team gazes at the board. James, a developer, looks at the bunch of sticky notes in front of him. And back to the board. “Well, I must say I like that you came to realize that delivering the full A+flow will not fit into the two sprints we’ve got left before the code freeze. But I am also a bit sad since this is the so-many-eth change of direction we need to deal with (sigh). We just spent about 3 hours trying to understand which back-end systems we need to connect to and how to approach that. And now I need to think how your latest insight impacts the stuff that we investigated. (Pause…). I know for sure that we definitely need to do this bunch (points at the left stack of stickies). We estimated them to be size M.”
The PO was looking hopefully, but his eyebrows now frown and his face turns a little red. “Eh, and how much is M?”, he mutters in disbelief. “How much work is that?”. “Sorry, there was no more time for detailed estimates… But to be quite honest, actually we do not know what effort it represents ourselves!” James bursts out laughing “I only know it is not as much as that bunch of things!”
I am the Scrum Master for this team. I think it’s time to intervene.
“Can we elaborate on this bit further, James?”, I ask. “Can we have a look at your stickies and see what’s on them?” The stickies are put on the wall. Three of them describe back-end systems that perform some function in the chain of events needed to store and collect corporate data in the labyrinth of legacy services. “We have no experience whatsoever with these systems. And we are unsure about what we will find there.” says James.
“That’s not a problem, that’s why we do scrum.” I tell him.
“Well it is a problem, because you want to know if we can deliver before EOY.”, he replies.
I correct him by saying: “The PO wants to know, not me… I think it makes sense if we could give him some kind of estimate. He needs to plan a marketing campaign.”
James gets a bit irritated and says: “We just had at least 2 hours discussion of drilling down and trying to estimate, but the team keeps on saying they cannot give a forecast. We don’t know exactly what it is we need to do, so how in the hell can we forecast? And you know how it goes, If we say two to four weeks, people only hear ‘two weeks’. We’ve been there before and no way we are going to end up there again.”
I see fear is crippling this team. Once bitten, twice shy. My #1 Scrum Master knee-jerk to mitigate unsafety is to offer comfort by saying stuff like: “It’s ok, don’t worry, nobody will get fired over this. I will talk to management about this.” But that’s as bad as accepting ‘everything is going to be fine’ as an improvement from the retrospective! Moreover, there is no learning in it for the team.
What is a better option?
Try empathy!
Try to understand the team’s fear and think what would help you if you were in their shoes. If I were a developer in this team and I would be facing this kind of uncertainty and pressure, the problem would be mitigated if I could have those back-end system specialists helping me to fix this. That would strengthen me to be able to cope with the uncertainty of “changing plans as we go”. I would feel more safe because there would be someone who can really help me when things get rough.
I asked James if they needed help reaching out to the specialists to get things cleared. He looked a bit puzzled. I added: “For sure they know. Why don’t we ask them to join our sprint?”. I turned to the PO: “If you would be able to join our daily scrums, or even better, come sit here with us, you will know what’s going on all the time.” I made a mental note to talk about the safety issue with the department manager later.
What is the point I am trying to make?
1. Fear in software development is very expensive.
2. If you think you discover a fundamental problem, you are not looking at the causes, you are looking at their effect. Further investigation and fighting the root causes needs to happen elsewhere.
3. This story shows the Scrum framework in full action:
We see how the Scrum values are indispensable to create trust and safety. Because of fear, people avoid taking decisions, become opaque and evasive, show no courage, commitment and focus on the wrong things.
We see the dynamics of the scrum roles:
- The team estimates the work.
- The Product Owner optimises value generation.
- The Scrum Master upholds the distinct accountabilities.
We see the power of transparency (opposed to wishful planning).
We see how a plan is created based on inspection and adaptation to increase chances for delivering done.