Scrum Isn’t the Only Path to Agility
While working with one of my current clients, a team said they didn’t want to do Scrum. At this organization, there is a lot of Scrum—most of the teams there are Scrum teams. The team in question decided that Scrum wasn’t working for them and they wanted to try something else. So I asked them what they wanted to do.
They said that they spent two days laying out the work they need to get done for the next release. (The release is about two months away, so doing some planning toward that release timeframe doesn’t seem bad.) They laid out the work to be done in weekly increments and agreed to measure their progress and replan every week. They also agreed to have weekly retrospectives so that the team could provide feedback and adjust.
They have set up a team room so that they can work together on a daily basis. This allows them to focus on getting their work done and to swarm on problems.
So, to sum that up, the team is:
- Working on a release plan for a two-month release
- Using a one-week cadence for meetings and replanning
- Using retrospectives to help the team reflect and tune their process
- Working together in a team room
It certainly isn’t Scrum. But that doesn’t mean it isn’t agile.
Their process is allowing the team to react to the business needs. It is helping the team understand their progress and set expectations with their business partners. But because their plan has strayed from the Scrum norm, they weren’t sure about its agility. They asked me if it was OK for them to follow this plan.
I told them that if it works, it will be good for them. It will give them a base to build on. It will give them a chance to continue to grow and improve their process as they learn more and adopt more agile practices.
I would like them to adopt a few things next: continuous integration, including unit tests; functional test automation; and pair programming or code review before code check-in.
Depending on how this experiment goes, we will tweak things as we go. We may need to change our processes or practices in order to improve. But this plan allows us to get started with something the team thinks they can commit to and will be able to reflect on.
I have used Scrum a lot. I believe it can really help a team to become more agile. But that doesn’t mean it is the only way for a team to become agile. Agile is all about self-organizing teams collaborating to find what works for them, so if this particular plan helps this team get started, then they’re forging a new path to agility.
This article was originally published on TechWellInsights.com.
Tom Steihm has been developing applications and managing software development teams for over twenty years. As CTO of Coveros, he is responsible for the oversight of all technical projects and integrating new technologies and testing practices into software development projects. Recently he has been focusing on how to incorporate DevSecOps and agile best practices into projects and how to achieve a balance between team productivity and cost while mitigating project risks. One of the best risk mitigation techniques Tom has found is leveraging DevSecOps and agile testing practices into all aspects of projects. Previously, as a managing architect at Digital Focus, Tom was involved in agile development and found that agile is the only methodology that makes the business reality of constant change central to the process.