Do you find yourself struggling with changing priorities and Sprint lengths that are too restrictive? Can we really use Agile in maintenance projects? Find out here!
Agile, and Scrum in particular, has become the facto standard for the software industry, and people are often trying to push its boundaries in order to use it in any project they are currently working on. One question that we encounter more often than others in these scenarios is whether Agile, or Scrum more specifically, is appropriate for maintenance projects or if their nature prevents us from profiting from the benefits of Agile.
One of the reasons Agile has become a standard is that its benefits are hard to ignore. Focusing on small iterations and empowering the team, so they are actually responsible for what they are working on, is an excellent recipe for achieving great results while exploring uncharted territory.
Nowadays, software projects involve a lot more adapting to new needs than they used to, which is the reason why people are trying to use Scrum, given that it is the most used Agile framework. Indeed, according to the latest 2017 State of Scrum report made by Scrum Alliance, 89% of Agile users use the Scrum approach.
But every so often, and particularly when it comes to maintenance projects, people start to complain about having to endure constant changes in the Sprint Backlog with all the blocker and critical issues that “need to be fixed right away” and of course, were discovered after the last Planning meeting.
Many different recipes are put to the test: shorter Sprints (can we have Sprints shorter than a week?), Time-boxed Stories for unexpected issues (will 40 hours be good enough for handling all the blockers?), or if we follow Scrum to the letter, cancelling every other Sprint because priorities have changed. As you can imagine, teams become frustrated with the constraints that have been imposed on them, therefore, they give up and start to reconsider if Agile really works with maintenance projects.
Content related: Say no more “Buts” and stop asking yourself why Scrum is not working.
Scrum in a box
Scrum’s limitations are great for exploring new horizons and occasionally reassessing where you stand, ensuring course correction at the end of every Sprint. However, sometimes, even a couple of weeks is too much when dealing with an incessant flow of blocker and critical bugs that must be addressed as soon as possible. Luckily, there are other Agile methodologies or frameworks that we can use and that are better suited for working under these ever-changing conditions.
Kanban (“visual card” in Japanese) is a system devised by Toyota in the late eighties. Initially, it was conceived to improve efficiency by means of inventory control, but recently the software industry has embraced it and redefined it.
The main purpose of Kanban is to reduce context switching and multitasking by limiting the work in progress and focusing only on the tasks with the highest priority. Out are the Planning meetings where you have been committing to certain tasks only to change that commitment a couple of days later. Out are the artificial time-boxed constraints that the team was self-imposing and could never follow because of this mutable context.
The rules for following Kanban are very simple:
- Visualize the workflow.
- Limit the work in progress.
- Measure the lead time.
Following these three rules and having a backlog that is constantly reprioritized, the team can easily work within the constraints imposed by a maintenance project. For instance, we can point out the following two:
- Was a new blocker bug discovered? If the Work in Progress limit (WIP) allows it, then it will be addressed right away. If not, it will be the next task the team must work on.
- Are there any disruptive bugs on sight? The team will continue working on those improvements that are the top priority.
No more Daily Meetings?
One of the main characteristics of Kanban is that there are no special rituals prescribed. As we have seen before, there are only three simple rules and none of them talk about review meetings, retrospectives, or even Daily standups. Nevertheless, Kanban does not explicitly forbid them, and we at Hexacta have found they are a great addition to team dynamics.
The benefits of a Daily standup are many and too obvious to disregard. Just to name a few we can find these:
- Improved communication.
- Team building.
- Task focus.
- Knowledge sharing.
- Problem resolution.
And all of that can be completed in a mere 15 minutes a day! It would be a shame to abandon them. (Read as well: Communication in Agile software development… Does it matter?)
When it comes to the other Scrum rituals (Review and Retrospective meetings, backlog grooming), the cost in time is much more significant but so are the benefits obtained. Therefore, making decisions becomes a little bit more complicated on whether to include them or not.
The way we normally address those rituals is as any other task that the team needs to work on:
- Have we reached a milestone, and do we need to show the stakeholders where we are at? Then let’s put a meeting for it into the backlog and prioritize it.
- Do we need to go over the backlog and refine it or split it into smaller tasks? Then let’s put a meeting for it into the backlog and prioritize it.
- Do we need to review the way we are doing things and come up with better strategies? Then let’s put a meeting for it into the backlog and prioritize it.
Having the team and the stakeholders figure out when they need something and address it as they would anything else has proven to be much more effective than forcing a fixed cadence in Kanban projects, but your mileage may vary.
This might be interesting: 4 reasons why splitting an unfinished product backlog item is a bad idea.
To sum up
Agile is not only the industry standard but a proven way of obtaining great results in software development projects. Scrum is the most widely used Agile framework, but it comes with certain limitations that are not very well suited for maintenance projects where the predictability is low, and priorities change often.
On the other hand, Kanban is perfectly suited for addressing mutable contexts and adapting to changes in priorities. It is simply a matter of choosing the right tool for the job.Go Back