How can you save your projects by adopting Scrum?
I know it may sound like adopting Scrum for a failing project may seem like a desperate measure, but it’s actually a very good move—if it’s executed properly. But why would you move to Scrum?
I’ve seen a lot of projects that move to Scrum because it is still in the analysis phase, the long-term mission is fuzzy, the project isn’t delivering anything, there is no transparency, the funds are bleeding with zero ROI or the project environment keeps shifting.
But how do you save a project with a methodology change? The experts have weighed in and I heartily agree that these are the best practices:
- Scrum is cool but no one wants to hear about that. Instead, if you want to sell Scrum to your stakeholders and your team, you have to tell them about the benefits. Make sure that you highlight:
- Incremental, continuous delivery – just mention the fact that you’re going to have a working product all the time and the clients are going to love it. The point of Scrum is to get the sprints to improve the project steadily.
- Clarity and transparency – since you have a Product Backlog that everyone discusses and that is accessible to everyone at any time, it’s easy to keep track of what’s happening. When someone wants to change something and that snowballs into disruptions, there’s an easy way to hold them accountable.
- Control – business owners or product owners can change the contents of the backlog constantly but can be held accountable for delays if the acceptance criteria aren’t satisfied.
- Hire an expert to soften the transition and maximize the investment in the change. Take note that a Scrum expert is totally different from a Scrum Master. The expert or coach is there to ensure that the roles are followed, the artefacts created and the practices followed. They are essentially there to provide a learning model for the project being implemented.
- Perform a Scrum Training workshop. You need your team to know how to do Scrum while sleeping. Although there is a long way to go, the first step should always be to train them. Understand that Scrum is hard to implement and even more difficult to maintain. It can only get off the ground if the stakeholders support the training. Make sure that the training program has a case study so the team gets hands-on work on an actual project.
- Set up a space for the Team. Scrum requires daily, fast, paced, intense meetings and four-hours sessions between sprints. You need a space where the discussions can happen and the product backlog can be updated and posted 24/7. This space must be accessible to all the stakeholders in the project.
- Create solid acceptance criteria for User Stories. Stories are the starting point for creating the workflow process and the tasks for the sprint. Make sure that both the product owner and the team members stick to the acceptance criteria to avoid miscommunication and wasted effort.
- Visualize the product backlog. Expectations and the product backlog must be placed in a conspicuous place at all times. This way, the team can always check and see the remaining stories for the sprint and the rest of the stories that the project needs to achieve. Set the backlog up in such a way that the work that need to be done in the next few days is at the top and the work for later is at the bottom in an upright triangle.
In the end, you have to weigh the cost of the change to how much the project is bleeding funds without the change. Changing over to Scrum can take as little as a week to as long as a month—but what does that mean in light of a project that hasn’t been functioning properly in half a year?
Discover our trainings in :
English:
Français
