At the end of our last sprint, I switched my mobile team from Scrum-like to Kanban-like.
Why would I do that, and what does it even mean? Both good questions.
My mobile team has five developers, two testers, one designer, three products with both iOS and Android apps, and three product owners. Each of the product owners have other products they are responsible for, and these other products have a higher priority. I am fortunate if all three product owners are able to attend the stand-up meetings we hold three days a week.
When I took over, there was no velocity, and it became clear, fairly quickly, there wasn't likely to be. I have been able to hold retrospectives, but sprint reviews are basically demos in the Friday stand-up, and sprint planning was the first stand-up meeting of the sprint. These were 30 minute meetings. Having developers split across three time zones didn't help. The result of sprint planning was, usually, that unfinished work was rolled into the new sprint, and a few new stories were added.
I'm sure there's a strict Scrum advocate whose head just exploded, somewhere.
As a team, we decided to switch to a Kanban-like process; this is more in line with how the team works. The product owners manage their backlog. When they are ready, they move their story cards into the To-Do column, which makes them available for the developers to work on. I've got a sneaking suspicion that we may encounter some issues with WIP, but we'll work it out.
We'll continue to hold retrospectives and evaluate our process as we go. If it doesn't work, we can go back to sprints.
Overall, I like the direction we're taking. I was struggling to figure out how to make the team more Scrum-like. It wasn't until I began to understand more about how the team works that I realized it makes more sense to make the process fit the team than it does to try and make the team fit the process. I work with a great team, and I need to make sure they know that.
There are other products, in our company, that have dedicated teams. They're doing well using Scrum. If I had three different dedicated teams for my three products, I'd probably be running them all on Scrum, still.
I want to be clear about something. I am not a proponent of customizing an approach before you even try it. Scrum, out of the box, can work great. As you use it, you may identify constraints and will need to choose to either eliminate the constraint or change the process.
Being agile isn't about strictly using Scrum, or Kanban, or some other flavor of agile. There are no methodologies or frameworks mentioned in the Agile Manifesto. An important part of agile is experimenting; learning how to deliver value more quickly than you've done in the past. Where you end up may not look the same as where you start, and that's okay.
Where are you on your Agile journey?