12 biggest mistakes you can make when adopting Scrum
## Sprints as mini-waterfalls You are using sprints, but the rest remained the same. You're doing exactly what you did with waterfall, just in a smaller scale. For example, you defer testing to the last part of the sprint. Or you still have functional teams, not cross-functional teams. That's not Scrum. That's waterfall. ## Report-style daily scrums People in the team feel denigrated by the scrum. They really do a status report to the scrummaster. Answer the typical questions and then shut down the brain. The role of the scrummaster is important here, as only she can assure the team can feel they have the ownership of their actions and can therefore self-organise. With that power comes passion and the will to attend the scrum. ## Retrospectives without actions Retrospectives can bring out a lot of interesting stuff. Most importantly, the things that have to change, to help the team improve in the next sprint. If a clear list of actions is not redacted at the end of the retrospective, the meeting serves no purpose. ## Incomplete definition of done Some teams may describe "done" as dev-finished. But then there could be a manual testing phase, a deployment phase or some other external stakeholder action that needs to be completed before a change can ship. Until it's out there, in the wild, delivered to your customers, it's not done. And if you don't account for it during your sprint and on your scrum board, you're going to have issues with blockers. ## Product owner and scrummaster are the same person Separation of roles is important in agile. When the same person is product owner and scrummaster, he has to impersonate at the same time two conflicting roles: the first tends to ask for more from the team and the latter to protect the team from external distractions and unrealistic expectations. Well, if you're not schizophrenic, I don't know how you can do it. ## Technical user stories If you're writing user stories that feel just like the old tech specs, with every detail enclosed in it, you're not doing it right. You may be missing what a real user story is: it's a description of a feature that has business value, because it's useful to the customer, and it's written using the business domain language, not a technical lingo. In fact, it doesn't describe how to do something: it describes what is needed, why it's needed and by who. ## Waterfall-style reports Reports are outdated the same moment you write them. Give more attention to your scrum board or whatever you use in place of it: the scrummaster should spend some quality time with it and make sure it's visualising in a clear, simple format the status of the sprint. ## Scrummaster not mediating When the team becomes king, everybody is called out to speak. But for some people it can be uncomfortable: especially for junior components of the team that can feel oppressed by more senior ones. It is very important that the scummaster mediates the discussions and creates an environment where everybody can speak up without fear. ## Defects not visualised There is no such thing as bug free software. During a sprint, the need to fix bugs may arise and the time for them was hopefully taken into account in the sprint planning as insurance. But work on bugs still needs to be visualised on the scrum board, along with user stories, so that if anormal conditions appear, they become visible and can be dealt with swiftly. ## Product manager not available Even if the team is self-managing and there are sprint planning sessions, as more work is done on user stories, new questions may arise. A product manager has the very important mission of getting customer feedback. But at the same time he has to pass that feedback to the team. So if he's never available for consultation, it's a problem. Try running in the woods at night without a light guiding you. It's not fun. ## Not measuring improvement Measuring improvement is your compass to know the direction you're going: good or bad? If you don't have proper metrics in place to see where your scrum adoption is going, you're lost. Thus you have to take time and decide which metrics are important for you. Something like number of bugs fixed is called _vanity metric_: they give you the impression you're improving, but you could actually be stalling or even getting worse. Metrics that work involve delivered value and the customer. But they are hard to work out at first. ## Inflexibility from going by the book It's good not to have changes in the backlog during a sprint. Having a well defined roadmap for a couple of weeks, helps the team to focus on what they have to do. But in the real world, nothing is perfect and you can't follow the book: you'll come across moments in which you'll have to make exceptions to the rule. And that's alright. You have to be flexible and responsive to your customers. As long as the exception doesn't become the rule.
