measure what you value not what is easy to measure
I am a scrum master of a team in an organization that has many scrum teams on the current project. My project manager asked me to reach out to this group to see what ideas we can generate on the current issue we are having.
So my organization seeks to do scrum. This is a change to the culture here. In the spirit of continued improvement, I have my eye on one practice that we do that really isn't very scrum, or at least not my interpretation. Instead of sprint review, we have sprint report out. At this point, we do some of the review activities like demo the working software. But this is also a measurement point where what was committed to in sprint planning is compared to what was done in sprint. When I was trained as a scrum master, the sprint commitment was explained as a commitment to how the team is going to behave, not to the delivery of x number of story points. This includes meeting the definition of done. The definition of done means no corner cutting.
Here is the problem. If DONE is the metric, that drives how people behave. So some of the scrum teams that are new to scrum DO cut corners and report things as done, demo out of their development environment... As such, we are not realizing the benefits of scrum.
So how do organizations measure the success of scrum and the success of sprints? What am I missing?
Thanks
Stephanie,
I was tempted to offer you solutions here, but instead, based on what I saw in your original post...I don't think you need me to do that. I'm instead going to put myself in the "coaching stance." Let's do the 5 why's together. I'll help if you need it, but I don't think you do.
I'll start... Why is your organization not realizing the benefits of Scrum?
So, you answer, then ask yourself why that is happening. Then answer, then ask why that is happening, and so on... until you ask at least 5 Why questions and answer them all. Peel the onion, and look for the root cause problem.
Hi Stephanie,
I recommend reading the scrum guide - specifically the parts on definition of done AND sprint goals.
Also the team no longer 'commits' to what they will deliver in the sprint, but they 'forecast' what they think they can get done to deliver on the sprint goal.
For definition of done - have everyone sit down together and have them determine & agree what needs to be included - you can offer suggestions, such as demo in the QA environment and not local instance, tests on code etc. It needs to be their decision on what the definition of done is - that way they will do a much better job of owning it and holding themselves and their teammates accountable. Post the definition of done where everyone sits and have it easily referred to throughout the day and sprint continuously. Have it posted in the demo room too. Be STRICT about not showing what does not meet the definition of done. This is important - you may have a 'demo' where there is nothing to show - have it anyway and openly discuss why it is the case. It might be painful, but it will help you get to the cause of the problem. Maybe the team doesn't have the skills needed, maybe they don't care, maybe they don't understand the vision of what they are trying to build, it could be a number of things.
Everyone has to be transparent, so that they can inspect & adapt to improve.
One way to measure progress is by release working software more often to the end user - you can then track usage, sales, whatever it is you are trying to improve. It could be page views if you offer content. Compare that to how often you released to production 'before scrum' and the value it delivered.
Scrum won't solve all of your issues - but it will shine a bright light upon them. It is then your job & the organizations job to remove the impediments & things that are slowing the team down.
Good luck.