There is no question that Scrum is one of the most popular project management practices today. Unfortunately, the successful adoption rate of Scrum is not as high as its popularity rating. Since the method yields such good results for various companies, it seems like those trying it out should do everything they can in order to succeed. However the reality is a little different.
Too often, previous project management practices and underlying assumptions get in a way of a successful Scrum adoption. The worst part is that teams in question think they are doing everything right too often failing to realize that just doing Agile is not enough.
One of the most important things to understand during any Scrum implementation is that it is not only a practice, but a true mindset change. A change that you actually have to work to achieve. Wonder what happens if you don’t? Let me paint you a picture.
After careful consideration, your company finally settles on Scrum as a new project management approach. Someone on the team takes a look at how it is done, which seems pretty clear and you set out to try it. You figure as there are quite a few rules in place, the team can simply reassign roles and start working. Scrum has the manual, everything should be fine, right? Unfortunately this is where the problems start.
Getting the Requirements
To start doing any work, the team first needs to know what the client wants. For this, Scrum teams meet with the Product Owner every two weeks, listen to the requirements and figure out what can be done in the next iteration. Seems rather easy right?
However, in most post traditional project management teams, Product Owners seem to think they actually know what has to be done. And since they still feel like they can tell the team what to do, they go ahead and do just that. Not listening to what the team capabilities are and actually pushing the work on the team members instead of letting them choose. Which does not allow for any team independence or creating a product according to the teams capabilities.
Daily Grind
Once the user stories and tasks are defined, your team finds itself in the first iteration. The board and the backlog is set and work begins. Every morning the team meets for the Daily Scrum and it seems to be going well. But are your team members talking about what they did and are going to do? Or is the Scrum Master orchestrating the meeting?
If the Scrum Master is not properly introduced to Scrum, in most cases they still see themselves as the power holders in this meeting. Which then turns into them controlling the team instead of guiding and enabling it to achieve its goals. And in such cases the Daily Scrums turn into question-answer sessions instead of a collaborative effort.
Reviewing the Progress
A similar situation happens with the Sprint review. Since the team has not been able to choose which work to do and then have been told how to do it, most likely they are not going to succeed. Which leads to a Sprint Review where a not working increment or one with multiple issues is presented.
Instead of acknowledging the faulty process, the product owners and other power holders simply blame the team. In their eyes the team has failed what they were supposed to do. But when you think about it, they had very little chance of success. The team that had no say in how the iteration happened is now blamed for the bad turn out. Furthermore they are asked to do better and deliver more in the next iteration or to face consequences.
Preparing for the Future
Lastly, after the iteration is finished, comes a time for a Sprint Retrospective. Ideally this is a time to reflect and see how the process could be improved by all parties. What happens in a faulty Scrum implementation though is Product Owners and Scrum Masters scolding the team for not performing. Often times threatening to take action if things do not change in the next iteration.
And unfortunately, without enabling the team and allowing for work prioritization the next iteration is just the same. Causing the company to keep working in a faulty Scrum process or eventually giving up on the practice altogether.
While it may be tempting to implement Scrum with your team, it is important to realize that this is no small change. It has to be taken seriously and like with anything else in order for it to work, you have to put in your efforts. Otherwise, it is actually better to stick with your current process and optimize it to the best of your abilities.
