Let me set the scene: It was around 3 weeks to the launch of our product (Expensive big bang PR launch) and the team are discussing the plan of attack for launch. We’re coming up to the end of our sprint and grooming the backlog so that it is ready for the next sprint, we’re also releasing the product early to a closed group (media/bloggers), so that we can get some early feedback. Apart from a couple of features, our last sprint of work is mostly related to compliance & legal requirements for launch, with the rest being bug fixes & polish.
At face value, the plan would be to complete one last sprint and then enter maintenance mode. We have also imposed our own Change Approval process, to ensure that we don’t break the platform or any legal requirements.
But there are a few difficulties we face in the lead up to launch:
- Our developer that is responsible for deployment, sys admin & dev ops will be away on holidays, therefore the team will collectively need to pick up his responsibilities. (Our initial solution was to factor this learning process into the backlog as a sized story to be included next sprint)
- Media influencers using our platform early will be providing feedback, some of which may teach us something we don’t know which is critical to a successful launch
- There are some external ‘parties’ we are still waiting on for various reasons, which may mean that we need to pull in tasks to the sprint, which in scrum, is a no-no!
- There is a LOT of work to do before launch, some of which is absolutely critical, some are very nice-to-haves for launch, but stakeholders will be pushing to have all of this ready for launch. Now is certainly not the time to be over-committing during sprint planning & increasing the risk of bugs, particularly due to the high degree of unknowns that can happen so late in the game.
- The team are already working long hours to meet the high demand of features & stability for launch, if they keep this up, quality is going to drop at such a critical time. We need a healthy & motivated team to make sure this all goes according to plan!
- The next sprint falls on our easter long weekend. I suggested that we avoid the assumption that the team will work over these public holidays. If they want to thats fine, but I don’t want to base the length of the sprint on this assumption, its not fair & could de-moralize the team.
So at our retrospective, the team raised all of these very legitimate concerns. We could continue with the next sprint, but we’d inevitably be breaking the foundations of Scrum as soon as anything went wrong, or as soon as critical requirements came in.
So how do we:
- Reduce the risk imposed by losing our developer that is in charge of deployments
- Skill up all our developers in this process
- Be able to respond to constant change on a daily basis (i.e. breaking the usual timebox constraint) that will come from third parties, media influencers, testers etc
- Still continue to work on the necessary work prior to launch which is vital for compliance, legal & stability reasons
- Restrict work in progress (WIP), keep working-hours at a sustainable pace & keep moral high
- Keep quality at a high level
- … and finally, stay agile, pursue continuous improvement & stick to the inspect-adapt feedback loop
Our answer – to (temporarily) ditch Scrum & employ the principles of Kanban:
- Limit WIP
- Manage Flow
- Make Policies Explicit
- Implement Feedback Loops
- Improve collaboratively, evolve experimentally
To follow these principals, we created a Kanban ‘wall’ & mapped out the ideal process for iterating towards launch, it involved testing each feature on multiple environments & deploying daily. Deploying daily is time consuming, but it allowed all of our developers to become involved in the deployment process, which decreases our risk of deployment issues (better we find out now than later) and increases the confidence of the team to achieve a smooth launch.
To ensure visibility of bottle-necks early, we imposed limits on most steps of this process. Almost immediately we were able to identify QA as a bottle-neck & bring on a new resource to cover the increase in testing needed to follow this process of testing multiple times on different environments.
In lieu of a daily ‘standup’ as mandated by Scrum, we held a daily catchup with the Product Owner, where we scanned (& groomed if necessary) the backlog and discussed our flow, specifically we asked:
- How is progress coming along generally?
- Is this process (Kanban) still working? What is working and what needs to be improved?
- Are there any bottle-necks? Do our WIP limits needs to change?
- Are there any impediments? (We even created a column behind the Backlog that has a WIP of 0 for ‘blocked’ tasks, which creates visibility & alarm as soon as there is an impediment)
- Any new updates from the Product Owner?
At the end of each day, the updates to the product are deployed to the production-ready environment and tested by a tester in another time-zone (we have staff here in Sydney & the UK), meaning that the Product Owner has a list of tested features / tasks sitting in his email each morning. To save time, only features that are demonstrable & new are physically demonstrated to the Product Owner when they are fully completed, saving us time in lengthy Scrum Review sessions.
Finally I managed to borrow a projector & display the Kanban wall (we’re using Jira / Greenhopper) onto the wall opposite our developers. As soon as a WIP limit is breached, the column becomes bright red.
It’s been about a week since we implemented this process and it’s been really effective. My greatest concern of utilising this process was fear of rejection from the Product Owner because he effectively loses his typical ‘Sprint Commitment’, but gains the flexibility to adapt to changing priorities on a daily basis towards launch.
Honestly I thought that this was going to be an issue, but to my surprise, he’s (voluntarily) expressed satisfaction with this process on multiple ocassions & loves the fact that he is seeing progress from the team on a daily basis & to him, its a much less nerve-racking experience each day we get closer to launch. We’ve been tweaking this process since we started & we’re getting better every day.
This article is by no means suggesting that Kanban is ‘better’ than Scrum, rather in these circumstances, within this period of time (~ 3 weeks towards launch), it was better suited to handling the chaotic nature of iterating towards launch. I hope that we can switch back to Scrum once our product has launched and we are considering new stories.
Update: I’ve written a follow-up article, now that we’ve launched the product. It’s a bit of a retrospective about the experience, check it out: