Skip to content

Why we dropped Scrum for Kanban in our lead up to launch

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:

  • Visualise
  • 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:

Why we dropped Scrum for Kanban – Part 2 (Switching back to Scrum)


  1. Adam Carter Adam Carter

    I am not sure I understand why you dropped the Scrum processes. Kanban walls and processes have been used within scrum, xp, and other agile processes for at least a decade.

  2. Hey Adam! I appreciate that WIP limits can be useful in a Scrum implementation (the more visibility & transparency the better!), but I thought I articulated pretty well that the reason for moving away from Scrum temporarily was to be able to adapt to rapid change on a daily basis, rather than the strict rules of Scrum mandating that changes not be accepted mid-sprint, else the sprint be terminated.

    Sprints are usually at least 2 weeks in length (appreciate that some people can pull off 1 week sprints, which is awesome), which is still too long for us to be able to handle the hectic nature of iterating towards launch.

    In this circumstance, I believe that sticking to the values & principles of Agile, whilst ensuring that appropriate checks & balances (inspect & adapt) is being carried out, is more effective than abiding by a framework that was going to make life miserable during this short time frame.

  3. Barry Barry

    Hi Brendan,

    Great article and very valuable for me right now! Thanks for posting your experiences.

    As a scrum master we’re going to launch a project that we’ve worked upon for more than a year (with a team of 10 members). I recognise most of the reasons to consider a different approach. Because of the upcoming launch we’ve switch from 2-weekly sprints to 1-weekly sprints. Hereby being able to respond quickly to changes and using a more pragmatic approach. (even more than Scrum already offers). But I’ve also considered Kanban. To make it even more recognisable: we’re also using Jira Greenhopper 🙂

    I do have some questions:

    1. Is the customer the product owner? Or is the PO part of the team? In our case the PO is part of our scrum team and the customer is a stakeholder that provides input.

    2. Do you still have a sprint planning? When are you deciding what you’re going to deliver? Is this done on a daily base?

    3. Are you estimating the work in story points or hours? Normally we estimate the amount of story points we can handle in a sprint. And communicate this with our customer. This way he knows what to expect from us as a result of the weekly sprint.

    4. In Jira; have you switched the ‘scrum board’ for a ‘kanban board’ with an existing project?

    5. My fear is that this will lead to more ‘chaos’. Therefore we’ve still respect the Scrum principles but you short weekly sprints. Do you recognise my concerns? Are they valid?

    For now, these are my questions, the more I think about it, the more questions however arise.. 🙂


  4. Hey Barry,

    First up, I’m curious about the fact that you’ve been working on this for a year, is there are a reason you haven’t released early? (That’s a year without feedback from customers!)

    1 week sprints are great if you can do it, some teams can & some can’t (or find it too difficult based on the scope of work). The sooner you can get feedback, the better! We also used GreenHopper to manage this process, we kept the same backlog within the original Scrum Board, but used a new Kanban board to transition tasks through this process. (This probably makes no sense unless you’ve used Jira before!)

    A1. We’re a client-servicing company that funnel some of our profits to our own projects, this was one of them. In our case, the Product Owner is both our Marketing Manager (of the product) and Product Owner, which we consider ‘part of the team’. Not a ‘developer’ (obviously) but we all consider him a part of the team, working towards a common goal. Our ‘customers’ are both the general public & charities, with whom our PO interacts with frequently.

    The role of PO didn’t change much in the temporary transition to Kanban, instead of a fortnightly review, we would notify him via email at the end of the day of deployed changes. We’d also involve him in our daily standups.

    I’m assuming that your “Customer” is a client? There’s much debate about whether or not a client can/should be a PO & ideally I think he/she should be, but it’s a very tough sell & steep education process. I’ve heard some companies require their client / stakeholder / product owner to attend a Scrum training session before they begin work.

    A2. As there were no ‘sprints’, there was no need for sprint planning. We just discussed upcoming work with the PO & bundled it all into a general daily grooming & standup session.

    A3. We stopped estimating, as most tasks could be turned around in the space of a day or two. After launch, we spent some time re-estimating the backlog before we transitioned back to Scrum. The Product Owner was fine with this. Typically we use Story Points for estimating when we’re using Scrum. (Planning Poker sessions)

    A4. Kinda ran both in parallel… Used the original Scrum Board implementation for the “Plan” section (backlog) but used a new Kanban Board, with the same Project. There were no sprints in progress on the Scrum Board whilst this was all running.

    A5. You’re absolutely right to have concerns and yours is completely valid, but agile is all about trying something, amplifying what works & dampening what doesn’t. What works for us, may not work for you and your team… And thats OK. Kanban is all about starting with a simple flow of what you’re doing now, then committing to improving it. When we began, it got a bit chaotic, so we introduced some checks and balances to reduce the level of chaos and that worked well. But honestly I don’t think we could have sustained the process without continuing to change it as our developers were taking on way too much work.

    Good luck Barry & keep the questions coming!

  5. Barry Barry

    Hi Brendan,

    We’ve been working on it for more than a year, in the meantime every two weeks we demonstrate the product to our client and process the feedback received. However, the product never went to production yet. This is caused by multiple reasons, eg scope changes, dependencies (with other projects), product not being production ready etc.

    I’ve discussed your blogpost with our team during the latest retrospective. Our conclusion was that we’re not doing sprints anymore according to the Scrum principles. Accepting this together (PO, SM en delivery team) provided relief for some members. Because they really committed themselves to the scope of the sprint, but all the risks/changes/ad hoc requests/hot fixes/bugs etc it was impossible to stick with the original scope.

    Therefore we:

    – decided to keep the weekly sprint rythme but accept that the upcoming weeks really should be seen as one big sprint and we’re analysing and adjusting the priorities daily.

    – we still groom the backlog but do this more quicker and frequent

    – we’ve asked the prior business analist/consultant from our customer to work in our office in the middle of our team -> this works great! (should have done this earlier)

    – we still do all the scrum sessions but shorter and more pragmatic

    – we don’t really commit ourselves to sprints anymore. We do a daily commitment and are committed to a successful product launch

    We’re still in the middle of the product launch, may 27th is the technical launch. It seems to work fine, although it still is a hectic and busy period.

    A1: our customer is indeed a ‘client’. Best case the client delivers the product owner. But it’s exactly like you describe; it’s quite a tough sell and the role of PO is mostly underestimated. We do however try to involve the customer with our process to create support, understanding and foster making decisions.

    A2: check. At the start of the day we contact our customer and discuss the work we’re going to do. We still do our sprintplanning but this isn’t much different than grooming anymore.

    A3: we still estimate all the issues with story points but I doubt the value of it. Estimating is especially valuable with new functionality. Adding story points to bugs, meetings etc is quite arbitrary. But because everybody involved is accustomed to SP’s we keep using them. (we always know on gut feeling how much we can handle in a day/week).

    A4: check

    A5: totally agree. Our team also make lots of hours and long days, doing my best the minimize the pressure. The described measures have certainly helped and we’re inspecting the process daily trying to improve it.

    Thanks for your answers, we’ll keep you posted!


  6. Andreas Andreas

    Great article, great tool 🙂
    Thanks for sharing, Brandon!

Comments are closed.