Mechanical Scrum Versus True Scrum – What’s the Difference?
Recently I was talking to a friend about their company’s implementation of Scrum. They don’t see the point. Before Scrum was implemented, they often had to wait an hour or more to access a test machine. After several years of using Scrum, it’s still a problem. The same company has its test servers in another country and there are often network issues that cause the running tests to fail. These were problems before they started using Scrum, and nothing has been done to address them since.
Scrum only works when we use it to address the problems that exist in our environment, and then work to resolve them.
Consider the basic principle that a Scrum Team is required to produce high quality working software (or hardware) at the end of every Sprint. Shippable quality.
Anything that stops the Team from achieving Shippable Quality Software every Sprint is an impediment, and must be resolved.
Here are some of the common reasons that impediments don’t get resolved:
- Definition of Done[1] doesn’t exist, isn’t honoured, or isn’t published in a truly visible place (usually the Team room wall).
- Definition of Done isn’t frequently updated and improved until the Team is at least able to ship at the end of every sprint; preferably able to ship continuously.
- There are no Component or Feature Teams[2]. Scrum doesn’t require Feature Teams explicitly, but it does require that the Team has a sufficient supply of skills that it can get a small vertical slice (not just one component) of software to truly done at the end of every Sprint. Component Teams, while legitimate in Scrum, increase the coordination effort required to get to done every Sprint.
- Pressure exists to deliver more every sprint. Many Teams feel a constant pressure to deliver significantly more than they’re able to. The pressure is so intense, that they constantly take shortcuts to try to meet the demand. Scrum was created to give the doers more freedom in deciding how much work they could achieve and how they could achieve it. It only works when the Team takes a stand and makes clear their capacity. Real improvement is only possible when the Team has sufficient slack to pause, reflect, and improve.
- Organizational impediments are not removed. For example, network issues between one office and another, coordination issues between Teams, or anything else that can’t be resolved at the Team level.
Remember, Scrum is a problem-finding tool, not a problem-solving tool.
Your organization has to solve the problems that Scrum highlights, for it to work effectively. Since Scrum doesn’t solve the problems for your organization, you’re not actually practicing Scrum if you don’t follow through and resolve the issues that it finds. Instead, you’re practicing Mechanical Scrum.
[2] Feature Teams – A feature team is “a long-lived, cross-functional, cross-component team that completes many end-to-end customer features—one by one.” Source: Larman and Vodde: https://www.featureteamTeams.org
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
Leave a Reply