How to Reduce Risk on Any Agile Scrum Project
One of our readers asked me how to reduce project risk in a blog comment. The moment I read the comment, I started thinking about what to recommend. Yes, we all know the benefits of agile: get your product into the hands of the customer more quickly, early feedback, ability to pivot and increased customer satisfaction.
But what can we do to further reduce risk and increase our chance for success and profit?
My top 3 suggestions include:
- Train, train, train
- Plan and baseline your project
- Consistent velocity
Reducing risk through better scrum practices is more than just the scrum master’s responsibility; it’s the entire team’s responsibility. I’ve already written posts about techniques to improve performance, reduce risk and help teams better meet release commitments. So, I’ll provide links to those posts as additional reference material at the end of each suggestion.
1. Train, Train, Train
Scrum is very different from traditional development methods. Everyone on the team must receive adequate training and even coaching. You cannot just ask someone to read a book or attend scrum certification training and expect that person to lead the transition of an entire organization or even a single team.
The practice of scrum requires transitioning to an agile mindset. That requires training by an experienced professional. If budget allows, we suggest hiring a part-time agile coach to help the team remain focused on practicing scrum the right way, so they do not fall back into their comfortable, traditional practices.
If management does not invest in training, the team has little or no chance for a successful transition to scrum. You’ll probably end up practicing some inefficient hybrid form of scrum, what we call scrummerfall, which can result in more overhead and projects may even take longer than if your team remained traditional and never attempted scrum.
If you want a successful transition, train everyone on your team how to practice scrum and think with agility. Then, hire someone to help the team improve their practices. This is the Number 1 way to reduce risk.
For more information about how to successfully transition to agile, check out our post 5 Steps to Implement Agile.
2. Plan and Baseline Your Project
Those who don’t want to follow formal methodology often tell management that you cannot be agile if you have to plan beyond the current sprint. Nothing could be further from the truth! We affectionately call the practice of only planning sprint by sprint cowboy coding. That’s not agile at all, it’s just chaos.
So to reduce risk, you must have a target product, priorities and planned public release dates. Recognize that the agile approach is different from the traditional way of planning. With traditional projects, you create work breakdown structures, which are task focused. With agile projects, you work with the customer to determine the most important product features, create a feature breakdown structure and plan for feature releases.
Organize the highest priority features for your first release, the next highest for your second release and so on. Write stories for the first release, start sprinting, start demoing and immediately start delivering value. With scrum, you don’t need to have all the answers to begin developing your product, but you do need to have a plan. Beginning with the end in mind is the Number 2 way to reduce risk.
For more information about how to successfully plan with agility, we suggest you read Chapter 2 of the GSD Scrum Handbook – GSD Gold Project Planning.
3. Consistent Velocity
Because scrum is so different from traditional methods, we recognize that at first the team may have trouble meeting its sprint commitment. If the team cannot meet their commitment sprint after sprint, then they have little or no chance of delivering on time. That’s why the Number 3 way to reduce risk is to help the team become more efficient.
If the team is not meeting its sprint commitment, a change of focus may be in order. A common mistake is to continue to focus on individual tasks rather than to holistically focus on completing the entire story. If your team’s primary focus is not on completing the story, then this change of focus can work wonders. Look at the burndown chart every day at the beginning of standup.
Reviewing the burndown is a daily reminder that the entire team must focus on closing stories.
Ensure everyone understands the story requirement and acceptance criteria when the story is picked up by the team. Because scrum accommodates changing priorities, stories written and groomed months ago can get pulled into a much later sprint than originally intended. Before the team starts designing and coding, make sure everyone involved with the story truly understands its requirement. While the developers design and code, the quality assurance testers should immediately start writing test cases to validate the story. This ensures the team is ready to test as soon as the story is coded and unit tested, reducing the gap between development and test.
Conduct a Retrospective at the end of every sprint. This is the best time to focus on what went right, where the team needs to improve and to implement much needed changes that improve performance and reduce risk. I cringe when teams tell me they don’t have time for Retrospectives. In reality, nothing could be farther from the truth.
Common opportunities for improvement include: Everyone needs to write better stories, lack of commitment from the Product Owner and stories are carrying over sprint after sprint. If you have issues in these areas, check out these posts: Write Better Stories, Bad Behavior on a Scrum Team and Maximize Velocity in a Two Week Sprint.
When the entire team understands scrum, commits to a realistic product development timeline and completes work with consistent velocity, risk is greatly reduced.