The rules of Scrum are simple, but too often people forget that to actually do Scrum requires spirit, passion, engagement – and involving the whole team.
This is a lighthearted list of some of the many things I’ve seen going wrong. It’s not Scrum if…
| Problem | Why it’s a problem | An alternative |
| …the team is told what their velocity is. | Velocity is a tool to help predict when you get a certain number of features complete and to plan for the next Sprint. It’s not a proxy measure for productivity. | Allow the team to discover the rate at which they complete their work. |
| …a burndown, burnup or cumulative flow diagram is confused with reality. | All of these charts are models that give you an idea what is happening. They only measure quantity, not quality; nor what has been completed. | All these charts are useful. Instead of looking for better charts, try “Genchi Genbutsu”:Go See for Yourself. Visit the team and see what Features are complete as part of Sprint Review. |
| …you’re using the Scrum Task board to micromanage team members. | I hope this is self-evident. | Scrum is focused on the success of the team. Allow self-organization to have a chance. Teams need to learn for themselves how to work most effectively together. |
| … you enforce Best Practices. | No matter how good the practice (i.e. Test Driven Development, Unit Testing, etc.) enforcement breeds resentment, and compliance without understanding.Scrum is trying to harness the diverse ideas and opinions of the whole; not just an anointed few. | Allow each team to grow/evolve its own practices. Provide them with support and the best information available. They will often find better options locally. Focus on outcomes, i.e. working software shipped every two weeks and not practices.Create community of practice to socialize and share. |
| … the membership of teams changes frequently. | Creating a high-performance team requires stable team membership. | Create stable Feature Teams. |
| …you treat your Product Owner as a Business Analyst with a better title. | The Product Owner needs the ability to see the big picture with a product, and the authority to make decisions that cost 1-2 team Sprints (perhaps $150,000) without having their choices overruled. | Find dedicated people who understand the Product area, give them basic Scrum Training. Trust them to make the right decisions at the Feature level. |
| …you magically turn all your Project Managers into Scrum Masters. | Many Project Managers don’t want to be Scrum Masters. | Ask people what role they want to play going forward. Give them a short period of time to play that role and see if it’s a fit. Don’t make assumptions based on their current title, role, etc. Finally, remember not all people are compatible with Scrum. |
| …your existing organizational structure remains the same. | Scrum Teams require less formal organizational structure and more coaching. | Agile organizations typically become flatter and more flexible over time. |
| …you spoon-feed teams their User Stories or Features. | When people aren’t engaged in creating the Stories/Features from conception to deployment you reduce understanding and engagement. | Co-creating knowledge is more effective than knowledge transfer. Involve the team in creating the Product Backlog. |
| …you break the Stories down into tasks for the team. | Same as above; you’re detaching people from the Story they’re building. | |
| …you maintain your existing roles, i.e. Developer, QA, BA, and Usability. | Formal roles create bottlenecks and foster individual work. In addition, they encourage handoffs. | Scrum wants collaborative work. At the team level, ignore all formal titles. Our goal is high quality working software, not handoffs. |
| …your Impediments Backlog remains unchanging. | Scrum is about improving the way we do work. An unchanging Impediments list/Backlog signals that no one is engaged in making things better. | Select one or two Impediments per Sprint; find something small to improve related to them. Practice true Kaizen (a continual dissatisfaction with the current state). Often the smallest improvements have a huge effect on morale. |
| … you have phases – Requirements, Design, Development, … | There are no separate phases. | Scrum Teams are expected to produce working products in the first Sprint. In practice this is hard to achieve at first, yet remains the goal.In addition, we don’t have separate phases within the Sprint. The most effective teams find ways to create Acceptance Tests before starting the Development work. |
| …you keep repeating the same actions and getting the same results. | Scrum is intended to challenge the status quo. When you create a new status quo, Scrum challenges it again. | Scrum invites a true Kaizen mindset – Congratulations! We’ve achieved a great improvement which allows us to see an even greater improvement just ahead. |
| …you focus on the tools and not the people. | Remember: Individuals and Interactions over Processes and Tools | Tools are useful but they’re not our focus. Use these tools if the teams feel they’re helping them succeed; not because management requires blow-by-blow reporting on tasks. |
| …your team members don’t feel professionally challenged and fulfilled emotionally. | Scrum should be fun. | See the above list that leads to disengagement, etc. Remember, it took years to get people into this state—it will take many months, if not years regrow lost spirit. |
From all of these rules, remember that Scrum itself isn’t the point. The point is to deliver high quality working software, which we do most effectively by creating High Performance teams. Scrum is a tool to create teams, no more.
Thanks to Neil Killick, Neil Johnson, Amy Neil and Marc Andre-Morriset for their suggestions, which are represented in spirit, if not exact copies of their tweets.
What are your “It’s not Scrum if…” stories?
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.
Many golden nuggets of truth and wisdom here – thanks so much for sharing.
Thanks Mark – most of these come from real client situations I’ve seen over the years.
Can’t read this properly on an iPad. 🙁
Sorry Pete its a problem with my tables. About 5 minutes of reading about making tables look readable on an IPad (https://css-tricks.com/responsive-data-tables/) and my brain hurt from all the CSS I was reading. I would happily email you a PDF of the original item as written in Word if that would help.
Sorry Mark
Hi Mark,
This was really a great read. Im in process of building an Agile team using Microsofts TFS product as the product manager and I suppose the Scrum Master and this gives a good baseline. My question stems from how you are saying scrum involves fluency within the whole team and not to be formal. Is it ok to include the QA guy and the reporting analyst in our Sprints since we are part of the same team ? Also some of our developers are working on a different project but they all can provide an update to the team so we are all aware of the initiatives going on. How can we make this successful? Hope to hear from you soon.
Svkaria – there are a few Questions:
Are there clear boundaries on who is on and not on the team? The Scrum events (Daily Scrum, Sprint Planning, etc) are for the whole team. If that includes QA etc then they should present. (Hint they should be on the team)
The other people working on different projects – are they normally part of your development team? In which “ask the team” what they think is the most valuable use of their time.
If they’re not normally part of your team don’t involve them.