Scrum and Exposing Dysfunctions – A Catalyst for Lean
I like Scrum, but can we change the Daily Scrum to twice per week…The team should be able to deliver on the commitment, but can we push the Sprint Demo out 1 week…Scrum is working great for the team, but do we really need a Sprint Backlog? You can answer “yes” to all of these, but don’t go around saying you’re using Scrum. Conversely you can say “no”, and identify the root-cause for the ScrumButt, remove the dysfunction, and improve the way you do business.
Identify the Root-Cause
As Scrum takes hold during the implementation phase, numerous ScrumButt suggestions will arise. If you are serious about improving the engineering environment, building a better team, and solving complex problems while maximizing efficiency, these ScrumButt suggestions are perfect opportunities to improve upon. The key is getting to the root-cause.
The Sprint Retrospective is an appropriate time to address these dysfunctions, and an even better time to address a dysfunction is as soon as they arise. It is up to the Scrum Master to identify, address, and resolve to a solution with a sense of urgency. If the Scrum Master is complacent, the Team will feed off the complacency and the entire initiative loses momentum.
Remove the Dysfunction
Here is where you find out whether or not the company, division, or department is serious about improving. What I have found is that Scrum is a catalyst for Lean. Due to the nature of Scrum making all processes, decisions, and individuals transparent, a multitude of excuses will be cast. This is the opportunity to strike. This is where change takes place. This is the moment of truth.
The Scrum Master will need to find creative and effective means to remove these dysfunctions. Most of the dysfunctions encountered are rooted in company culture and tradition. When I hear the phrase “but, this is how we’ve always done it” I know there is a pending storm ahead. I am now challenging the status-quo and asking people to come out of their comfort zone. The point here is that identifying a dysfunction is the easy part, and the real work is to remove the dysfunction.
My suggestion is to allow a team member(s) or Product Owner to come up with the reasons why removing the dysfunction will be an improvement. When the Scrum Master jumps to a solution, even though it may in fact be correct, the path to removing the dysfunction will be up hill. At times, these hills must be concurred. However, when the Team defines a solution, the path is almost effortless because they own the idea.
Improve the Business
Making common sense improvements that are supported by sound logic is at the heart of Lean, and Scrum is a perfect means to identify what to improve on first. The return on investment (ROI) from using Scrum for Lean initiatives far outweighs that of all day meetings to map out processes, and then argue over why certain steps are in place. With Scrum, the waste floats to the top and is exposed during the development process.
