Transitioning from Scrum to Kanban
Making the Agile jump from Scrum to Kanban
Having been personally involved in large scale transitions from Scrum to Kanban I know from first-hand experience (and some scars!) that the process is far more complex than a simple ‘framework switch’. Teams (and the organisations in which they exist) are challenged technically, operationally and culturally. Those who believe the fluidity of successful Kanban environments is synonymous with freedom from the shackles of governance couldn’t be further from the truth.
We currently have an inflight project making the transition. I took the opportunity to sit down with our Lead Consultant Project Manager, Matt Pyle, to chat about the change, his experiences so far, and the impact the transition is having, even at these early stages.
For those not familiar with the terminology, what are the key differences between Scrum and Kanban?
Scrum focuses on autonomous teams delivering incrementally, in time boxed periods, or sprints. Each sprint delivers production ready code, in line with the team’s definition of ‘done’. Work is pushed through sprints, with the team committing to delivering an agreed body of work. Scheduled ceremonies (story time, sprint planning, sprint reviews, retrospective) are planned in line with sprints in order to make sure (a) work being accepted into a sprint is ‘sprint fit’ and (b) the team regularly reflects on how the processes are working and makes changes with a view to improving performance and team velocity.
Kanban operates independently of time boxed windows. The team works through a backlog of deliverables prioritised in collaboration with a product owner. Kanban workflow establishes the ‘flow’ of development, through the introduction of work in progress (WIP) limits at each workflow stage. The team constantly evaluates whether there are ‘blockages’ in workflow, and acts accordingly to remove them to improve development throughput.
Unlike Scrum’s regimented ceremonies, Kanban drives constant iterations in requirements gathering, UCD (User-Centred-Design) processes and technical designs. There are no all-day planning sessions. These sessions take place constantly as a piece of development is promoted in priority to be delivered.
One thing which is absolutely the same, regardless of the framework, is the adoption of a ‘stop starting, start finishing’ mind-set, in which our focus is ultimately delivering efficiently, and with quality.
Why was the decision made to move from Scrum to Kanban?
For a start, simply because a project starts using one framework doesn’t preclude it from changing. We never fit a project into a framework, we fit frameworks into projects.
We delivered a minimum viable product (MVP) with our customer, using the Scrum framework. The scope and timescales were defined in our ‘discovery’ phase, giving everyone involved a roadmap view of what we were going to deliver – this is critical in ensuring our client had confidence in a milestone plan, against which we were frequently able to measure. On completion of MVP we had a platform which was stable (both technically and functionally). We had a good base which we could incrementally enhance.
We’re now into the process of testing the MVP with the end users, and we felt it was right for the project to transition from a project model to a product model. We’re seeking feedback from many users, across multiple customers and as such wanted to ensure we had absolutely flexibility in our approach to be responsive.
The nature of deliverables has altered slightly. The focus is not purely on development, but on migrating ‘alpha’ customers onto the platform. As such we felt forecasting against a velocity could introduce false positives in planning. Adoption of Kanban workflow allows us to deploy team members to tasks without constant refactoring of sprint commitment.
Why didn’t we start the project using Kanban?
Answer projects typically start life as Scrum projects. We collaborate with a client in delivering a ‘discovery’ phase in which we ascertain the intended business outcome, project scope, technical and user centred designs and scale of effort (both for the MVP and the broader project). This drives the creation of an MVP sprint plan, giving everyone involved a roadmap view of what we plan to deliver.
The nature of our work, building bespoke systems, means we’re working from a blank canvas. We look to give the clients we’re working with confidence. The best means by which to do so is to track progress against short term milestones from the get go. It allows us to validate scope, designs and estimates as early as possible in delivery.
The Scrum ceremonies provide structure for a new team to get into an Agile mindset. Often we work with teams who are either new to Agile, or who have adopted the approach with varying degrees of success.
How are we measuring success?
This comes back to the drivers for adopting the change. We want to measure that we’re more flexible and responsive. We’re still a work in progress in quantifying this, however we’re certainly seeing the adoption of great behaviours in working to have deliverables ‘sprint fit’ much more incrementally, albeit in the absence of sprints!
Key for me is seeing members of our team becoming increasingly ‘T Shaped’. With Scrum teams there are clear demarcations of responsibilities. Developers develop, testers test, for example. We’re looking to evolve beyond that. Where we have a breach of a WIP limit threshold, rather than picking up new development tasks, we’re challenging developers to support other stages of the Kanban workflow to improve overall flow. It’s fair to say this has been a challenge, but is something we’ll continue to embrace.
In terms of improved flow, we’ve started to utilise JIRA to monitor ‘Cycle time’ (the time a development item is in a particular workflow stage) and ‘Lead time’ - the elapsed time from when a development ‘starts’ (in our case the 3 (or 4!) Amigo’s session) to when it is complete in line with our definition of done. A measure of success would certainly be in reduction of these metrics!
How has the change been adopted?
With enthusiasm, some questioning and a little frustration – all of which I see as positive! Certainly the reduction in some of the lengthier meetings has been embraced. The review and preparatory work has been retained, however it’s broken down and happening iteratively, every day.
The physical working wall has become a real focal point of our working space. Where our previous wall was reviewed daily as part of the stand-up, the whole team is now constantly engaging with the wall as a working tool.
There has been some frustration, predominantly to do with our adherence to WIP limits. Developers see they have capacity to pick up new tickets and immediately (and understandably) want to do so. However the focus on the wall constantly identifies where WIP limits have been breached at other stages of the workflow. We’re challenging people to operate out of their traditional comfort zones and roles – to become T-Shaped.
One consequence of short term sprinting is the ratcheting of pressure as the sprint completion nears. There have been occasions where the focus has shifted away from quality into a ‘get the job done in time’ mentality. Whilst we were cognizant of it, and actively worked to mitigate it, this clearly doesn’t occur when operating the ‘pull’ Kanban model.
Until the transition the team were estimating in man days of effort. This has now been superseded with T-Shirt estimating, where we assign small/medium/large estimates, relative to the perceived level of complexity. Our intention is to drive relative estimation which, when combined with our tracking of lead times, will help us to more accurately forecast when a feature will be delivered. We’re working towards a truer sense of velocity for the team, and what it delivers.
What, if anything, has changed technically?
Nothing – because we were equipped to make the transition. Significant time and effort had been invested by the team in ensuring we had agreed coding standards, code quality tooling, and continuous integration, build and release pipeline and automated regression framework. As we move forward we’re evolving our approach to application monitoring, logging and alerting in order for us to more efficiently manage both migration and proactive development concurrently.
What can we take away from the conversation with Matt?
- Transition from Scrum to Kanban is more than simply changing ways of working. Teams need a level of maturity in Agile mind-set. Moving away from a cadence of time boxed cycles can be challenging.
- Development, test and build pipeline infrastructure, tooling and processes are critical to enabling flow.
- Fluidity does not mean a lack of governance or control - quite the opposite. Kanban drives transparency in workflow efficiencies.
- Tracking tooling (in our instance JIRA) needs to be configured to support the team in monitoring key performance indicators, such as cycle and lead times.
- The team needs to constantly work with the product owner to validate the concept of value, and prioritise the backlog accordingly.
- ‘Definition of done’ is just as important in Kanban as it is in Scrum.
- Team members need to be open to the concept of becoming ‘T-Shaped’, becoming comfortable contributing to flow outside the parameters of traditional Scrum roles.
We help retail companies of all sizes to shape, design and develop innovate bespoke digital experiences that put digital enablement at the heart of the company to increase growth and fulfil their potential.