Agile Chaos... Everyone tries to do everything and very little gets done and quality goes out the window. Worse is that developers will perceive scrum as a problem rather than a solution. As a scrum master and guardian of scrum, it's one of your biggest fears! Forget about the sprint failing, this is when agile fails.
Scrum
Scrum: a process where short, fixed scope iterative cycles are used to deliver software over a long period of time. Scrum promises the fixed space to developers to allow them to be creative, while offering the customer the flexibility to change the product. A win win.
So the team gets the X weeks space to work on something and during that X weeks the organization issues are supposed to go on the backlog and, if the PO agrees, be prioritised to the top to be tackled in the next sprint. So you could have a possible x weeks needed to turn around your issue.
Reality
But how often do we see that managers or PO's just can't help themselves tinkering with the sprint backlog. As soon as the customer or stakeholder get off the phone with a question, suggestion or complaint, they have to have a developer that MUST look at this new revelation TODAY!
Well lets look at the effects this have on the developers in the team.
Context switching goes up. What the developer was working on yesterday, must be dropped to look at this new thing. Then when we have brought it to resolution, that developer switches back to what they were looking at. "Now where was I?"
Trust in the PO and Scrum master goes down. The team recognize they didn't get the space as promised by the PO and the scrum master couldn't prevent it. "I thought the scrum master had our backs"
Commitment excuse. We are now trying to fit more work into a short iteration. This means our original goal is probably unattainable unless overtime is called for. "Well we could have got that finished, but..."
Morale down. Trust is down, our goal looks out of reach. We have to work longer hours just to make up. "There goes my Saturday..."
Quality down. "If I have to work overtime, well dammit I'm gonna take a short cut. We can fix it up next sprint."
Amount of testing down. "We haven't got time to put in those negative scenarios. We'll pick a few to give us good coverage and leave it at that?"
What can a scrum master do prevent this from happening?
Scrum masters should have the power to stop a sprint and call a re plan. Also scrum masters have the power of informational at their hands. They can publicize the effects as observed so that Product owners realize the consequences of their decisions on the team and on the product.
Scrum masters should have the power to stop a sprint and call a re plan. Also scrum masters have the power of informational at their hands. They can publicize the effects as observed so that Product owners realize the consequences of their decisions on the team and on the product.
When reviewing the sprint, make sure you highlight what was added at an inappropriate times during the sprint.
The advantage of using a tool like JIRA is that the story or task history gives you evidence of the amount of context switching in a team. It should be universally recognized that context switching is inefficient in the organization. So highlight the history of stories during a chaotic sprint as evidence.
Trust and Morale are much less tangible to highlight. But it also means you have to work harder to increase both when you recognize they are down.
Quality and testing are much more tangible to show. There are lots of statistics out there you can gather on your product. Be weary that teams will design towards quality metrics if the quality metrics are a stick to beat the team. Quality metrics are evidence for management to give the team room to take some action.
When was the last time you accepted work into the team during the sprint? When was the last time you stopped the sprint? A scrum master should have the power to do this.
Scrum should be about sustainable pace. When you are in chaos due to too much flux, make sure you call it what it is: Chaos. If scrum is confused for chaos, people will not see scrum as a solution, but as a problem.
Lesson
The ultimate realization here is that there is more than the Scrum master protecting the team. The product owner needs to realize how they fit into the picture of the team. This is easier to do if you consider the product owner as part of the team. However if your organisation doesn't consider the PO part of the team, it's a bit harder. The scrum master has to go to more effort to make them realize the consequence of the product owner not absorbing the majority of that flux driven by the stakeholders.
