Since switching my mobile app "project" from Scrum to Kanban, my initial suspicions have become cemented in my mind - this project I've inherited really isn't a project. The biggest giveaway? Now that my Product Owners are producing roadmaps, I've found that there is no end in sight.
So, if it's not a project, what is it?
Maintenance. It's a mix of new feature development and bug fixing. It was assigned to me as a project, and it has a project number, but the product owners expect it to continue until the products are no longer supported. That might be a while.
I'm not complaining. It's providing me with the opportunity to gain experience transitioning a team from Scrum to Kanban. It has also helped me to realize that Scrum has the ability to blur the lines between projects and maintenance.
As I'm re-reading what I've written so far, I'm asking myself a question that you're probably asking, too. "So what?"
I think that the first "so what" is the realization that when a company is making a transformation to Scrum, there is the potential for everything to look like Scrum. So what?
Mobile application maintenance does look like something that you can do in sprints. But, all of a sudden, you go from traditional release management processes to needing a Scrum Master to accomplish something that you've been doing successfully. Hmm… potential increase in overhead costs, but now you can say you're doing agile. Again, so what?
This isn't to say that maintenance can't benefit from Agile processes. It certainly can. My primary caution is that if your company is making an agile transformation and you have selected a single flavor of agile to implement, don't try and force everything to fit the flavor you have selected. You might also want to avoid trying to turn things into projects that are not - being able to use Scrum-like processes for ongoing maintenance does not turn maintenance into a project.
More about our transition to Kanban…
I talked a little about switching my team to Kanban in my post in February:
The team has been making great progress, although we're still trying to figure out meaningful metrics for our consultant development team. There are times when I wonder if a project manager should be running this effort; it really is a long-term maintenance effort. If this is what the PMO Director wants me to do, in addition to my SAP projects, I'm not going to argue. There is the possibility, however, that at some point, I will either need to be more dedicated to the mobile effort, or focus on my projects that have end dates. Either way, it's in my best interest to make sure that I have a documented process.