Scrum is not a project

How many times have we heard that Scrum doesn’t work? Or at least we haven’t gotten as much improvement, even half of what was promised. We had followed all the scrum activities religiously but there has been no progress. That’s happening because scrum is treated as a project. Scrum is not a project.

 

From my personal experience and the stories I’ve heard from other people, many companies or teams think that Scrum is a “project” and they try to implement it as a project.

 

At the beginning of the scrum journey several people attend scrum master classes and then a few attend the product owner classes. But, almost no one attends the scrum development classes. After that the company reads a scrum guidance book or invites a consultant to teach everybody. It appears they are gathering the requirements for a project.

 

Second, the company creates a scrum board and a burn down chart most likely using some sort of an application. Then the company sets the initial date for planning, sprint duration, and scheduled the morning scrum meetings. All these activities remind the design stage of the project.

 

The next step is the implementation of the project…oops I meant to say scrum. And, from the beginning everyone sees the progress and the positive results. Productivity has increased, the production deployment frequency is more often, relatively regular, and better visibility.

 

After a few months of sprint-work everybody notices that many of the old problems have come back. Team has to work overtime or weekends before the end of the iteration. It seems like the project is coming to an final stage but the project slides from its schedule. The environment is not ready for the new deployment (e.g. lot’s of bugs found etc.).

 

And then new problems start to arrive. The product backlog is empty of the product backlog items are not ready for development. The team’s velocity is stuck or even going down. QA engineers had a lot of free time at the beginning of the sprint but now lots of crunch-time at the end. It is the opposite situation for the developers. The number of production bugs has increased.

 

After everything is fixed and the whole project is “successfully” released business and developers become relaxed. Why? Why are the last few sprints before the final release so tense? Scrum says “Every Sprint produces a Product Increment. The Product Increment must be of high enough quality to be given to users. … the Product Increment is of high enough quality to be shippable: the Product Owner could choose to release it immediately.” Technically the the final release date shouldn’t be much different from the first, second or any of the other sprint ends.

 

Why doesn’t Scrum work in its full power?

First because a waterfall project was squeezed in to small sprint time boxes. The Definition of Done is quite often mixd up with the project release date. In this case the Product Increment doesn’t reach the Definition of Done and some work that is still in progress has been passed to the feature sprints. It is not always development. Most likely it’s test or integration or deployment.

 

How have companies tried to improve?

Only a very small number of companies have tried to change their behaviour to the real Scrum/Agile. Most other companies just try to adjust Scrum/Agile how they can.

 

How to be a real Agile/Scrum company? Let’s start from the beginning.

Backlog refinement

The Product Owner has to prioritize the Product Backlog items based on their real used story value (ROI). The backlog has to have enough user stories for at least one iteration.

 

Sprint Planning

Who must be in the scrum planning? It is crucial that the right people attend the scrum planning. The Product Owner present the Product Backlog Items to the team. Businesses must be prepared to answer all user-story questions the developers may have. All technical discussions have to happen on a white board and include all the team members no exceptions. Then all the information on the white board must stay there.

 

Daily Scrum

There is no leader like a team leader or a team manager who leads the Daily Scrum. A self-orginazing team whose members trust each other doesn’t needed any dedicated person to lead scrum meetings because sooner of later the team members will see him as a manager.

 

It is always better to have a physical scrum white board with the sticky notes as task representation rather than an electronic tool. An electronic tool requires a dedicated person to move the task cards around. A physical scrum board is available from everyone at any time. Every team member has to move his task sticky note himself. This provides the confidence for him for controlling of the process.

 

Sprint Retrospective

Most of the scrum teams know what should be done at the retrospective. But, not many do it right. Discussing the issues and having wishful thinking that everyone will be careful next time and that this issue will never happen again is the big old project approach. That’s not how it is should be handled.

 

The main goal of the Spring Retrospective should be to improve the process by investigating the root cause of the issue. Riding the root cause means not only to discuss the issue but find out why this issue happened. After the root cause has been found a fix plan has to be created and executed at the next iteration. All these activities will prevent the same issue from happening again and leads the sprint velocity to increase.

 

Conclusion

Agile/Scrum is not a project it is a perfect vehicle to drive your development projects. To achieve and maintain this vehicle at full potential all the parts have to fit and be oiled perfectly. It must become a mindset.

 
 
 
Scrum, Kanban or Scrumban for a headhunter’s company