On April 9th, I published an article “Why we dropped Scrum for Kanban in our lead up to launch“. The article will be published on the Scrum Alliance website over the coming days and I was just approached by a staffer at Scrum Alliance to provide an update on the article, now that we’ve launched our product. Here is the update that I provided, based on my experience switching to Kanban towards the launch of a product, launching it & then switching back to Scrum.
It’s been some time since I wrote this article (originally wrote it April 9th), so I thought I should provide an update, particularly now that we have switched back to Scrum again, have completed our first sprint & we’re now half way through the next sprint…
We launched a product called Jaro, a social good project with a rather ambitious goal of raising $1 Billion for charity & 1 lucky winner of a tournament-style game.
The launch was successful and the software we had built worked & scaled as expected. (i.e. the launch was a success & shortly after we were featured on BBC Click on the BBC World Service, being transmitted all over the globe & smashing our servers with traffic)
We had focused on only the most important tasks each day in the lead up to launch. This acute, daily focus on what is most important, helped us inspect and adapt daily, to ensure that the team were only concerned with what is important now. For the most part, it worked, but it wasn’t sustainable. Shortly after we launched, we conducted a ‘launch retro’, where we discussed what’s working & what isn’t.
While the team liked the Kanban process, we reached the conclusion that it wasn’t going to be sustainable as it was harder to measure & understand our capacity and was difficult for the Product Owner to give informed estimates on when features would be delivered. (I have no doubt that we could have improved it, but going back to Scrum seemed like the easier, safer option)
So in true Agile fashion, I’ll reflect on what’s working for us now that we’re back to Scrum and what we’re working to improve:
What’s working – less hours, less stress, better quality
I previously mentioned that the team were working long hours (and whilst we had some mild improvements through the Kanban process, we ultimately didn’t improve this as much as we’d liked). Well now the team are generally coming in on time & leaving on time, which has also had the knock-on effect of improving quality as well. Our definition of done is being followed and we’re also working towards building some more front-end automated tests.
I attribute all of this to Sprint Planning & the sprint commitment. The team really understand the importance of Sprint Planning in being in control of how much they commit to & the effects that it will have on their work over the space of 2 weeks.
What we’re working to improve – release schedule
When we were using Kanban, we were continually releasing to our dev, then staging, then production environments on a daily basis, which meant that our early adopters, charities & partners could see their requirements being fulfilled almost immediately, which was vital in the lead up to launch (particularly when getting sign-off / approvals). Now that we’re live, the team are getting asked to release patches / small changes mid-sprint, which isn’t exactly ‘by the book’ when it comes to Scrum.
To give us visibility around the extra time it takes to do this, we’ve factored in a story-point buffer whenever it’s likely that we’ll need this done. We’re also factoring in our deployment testing process when it comes to considering a story ‘done’, as this was favourably received during the Kanban process.
So why should you consider Kanban over Scrum?
From my experience here (and yours will no doubt be different), it’s when requirements & priorities change quickly & often. If we truly value the principles of the Agile manifesto, then we should welcome changing requirements, even late in development, but in my opinion, Scrum is only good at this when we can handle changing requirements every 1 – 2 weeks (I avoid saying 4 weeks!).
This is why Kanban is the unofficial preferred framework for maintenance staff, as it is more concerned with limiting work in progress, than it is fulfilling a release plan / backlog.
I hope this article helps you to make a decision on whether this approach is right for you; I’d love to hear your comments, experiences & feedback on this approach, I’ll do my best to answer any questions you have as well.