As so many have pointed out, Scrum is simple but not easy. Unfortunately, many teams fail to get the benefits they were hoping for. In many cases, they end up blaming Scrum itself but the actual cause is often more down to the implementation of it.
Here are a few signs that what you are doing may not actually be Scrum at all:
1. Delivering according to the original specification. If nothing changes during your project, you have missed out on the opportunities to build a better product. If you are not willing to evolve your requirements, Scrum will provide little value.
2. Not demonstrating working software at the end of each sprint. If it takes you three 2-week sprints before you can demonstrate something to the users, you are effectively running a 6-week sprint!
3. Sacrificing good technical practices to meet deadlines or boost velocity. The team needs to be able to update and make additions to the code over and over. This requires automated tests, to give them the confidence they haven’t broken something, and refactoring to make sure the code remains readable.
4. Spending a lot of time up front planning and estimating. At the start of a project is when you know the least. While you clearly need a fairly good idea of what it is you will be doing, creating a detailed plan will be a waste of time as things will change. Or, much worse, that plan may even prevent you from making changes based on what you learn later on!
5. Ticking the boxes. While following the rules of Scrum is necessary if you want to do Scrum, it isn’t enough. You can’t simply apply Scrum as a checklist of practices — you need to make sure you actually achieve what the rules are aiming to achieve.
6. The Scrum Master as a project manager. In Scrum, the responsibilities of a traditional project manager have been distributed between the product owner, the team and the Scrum Master. Combining the roles of Scrum Master and project manager will not only create a conflict of interest between these two, very different roles. It will also clip the wings off the product owner by taking away decisions they should be making.
7. Not measuring velocity. What is a reasonable amount of work to take into a sprint? When are we likely to ship feature x? Without measuring how much work you get done each sprint, you’re just guessing. The risk is someone might hold you to those guesses!
8. Building, shipping and moving straight on the next feature. It’s not iterative delivery unless you actually iterate!
9. Things not getting better and better. Continuous improvement is at the heart of Scrum, so settling for “good enough” is not an option when it comes to ways of working.
10. A big team. Scrum prescribes a team consisting of between 3 and 9 people. Any more than that and you are unlikely to get the kind of collaboration Scrum requires and the coordination will become too much to handle through self-organisation.
11. “We spend so much time in meetings rather than doing work”! Does the sprint planning meeting feel pointless? Chances are developers just work on their own individual tasks with little interest in what the others do. That’s not what Scrum is supposed to be like.
12. Little involvement from users, customers and stakeholders. To build a better product, you need the feedback form the customer and the users. If the team build the product in isolation and ship at the end, how could you expect a better result than when using a traditional method?
13. Teams that are unable to deliver features end-to-end. The team being cross-functional is not a nice-to-have. It’s how they can deliver to evolving requirements without having to wait for changes upstream or downstream.
14. Just doing bits and bobs. Scrum is designed to deliver complex products, not scheduling simple chores or constantly responding to urgent requests. In these cases, Scrum will create extra overhead without much value in return.
What do you think? Is there anything missing from this list? Or anything you disagree with? Please share your thoughts!