This blog is a case study of an Agile implementation which started off as a classic Scrum implementation, and then evolved to use Scrumban and Kanban techniques.
In the Beginning.
It is day 1 of sprint 1 for a team.
To set some context, a Business Analyst had spent several months preparing a product backlog of nicely written user stories. They were conveniently written in the user story format:
‘As a <who>’
‘I want <what>’.
Unfortunately they were written by the Business Analyst alone, therefore not benefiting from conversations with the team, and they were missing the ‘So that <why>’ part of the user story.
The team had been put together a couple of weeks ago, and its members were sourced mainly from external contractors.
The team members had spent the last two weeks running a sprint 0 to prepare themselves for the development.
I joined on day 1 of sprint 1, having little context of the team, the project, or of the preparation that had been undertaken.
Somehow, on my first day, we managed to put together a sprint plan for the first sprint.
The first sprint then actually went well. In fact, really, really, well. In the sprint review, at the end of the first sprint, we managed to demonstrate some completed features of the product. This was the first time the company had such a success on its first sprint. ‘Hurrah, this is going to be an easy assignment’, I thought.
Then the problems started to rear their ugly head.
The first sprint went so well that it led to the expectation that such leaps and bounds would be made every sprint. In reality, the first sprint delivered a thin slice through the system, dealt with a happy path scenario, and mocked out some of the complex integration points, some of which were dependant on a third party. This was a massive lesson in good stakeholder expectation management.
We continued to run sprints adding functionality, but we never had the same ‘success’ achieved in the first sprint.
One of the problems arose from the fact that it was difficult to see where and why things were being slowed but we didn’t know why.
This was our team Scrum board:
Problems we were observing where that:
- Work stayed in progress for too long, progress wasn’t visible.
- There were a lot of work items blocked in the sprint
- We were regularly missing our sprint goals.
The start of Scrumban
In order to tackle these problems, we decided the best thing to do was to start to visualise them, and tried implementing a Kanban system. We mapped out the process that the team was following on a Kanban Board, took a stab at applying our first WIP limits, and identified the blocked items with a red magnet. We decided for now that we would maintain our sprints, and continued to plan our sprint every two weeks and review the work every two weeks.
Here is our initial Scrumban board:
One of the early improvements we made to the board was around our blocked issues. We were using a magnet to identify blocked items. But we found that we didn’t know why the items were blocked. So our simple improvement was to add a red sticky note with the description of the blocker.
This was working really well. The act of visualising the work really helped us understand some the problems we were encountering. Still, we didn’t know who was working on what, what the different types of work were, and we didn’t now when work was done at each stage.
So we visualised these things. We created avatars for each team member, allowing us to see who was working on what. And actually, we only gave each team member three avatars, so that team members’ personal WIP was being limited.
We used different coloured cards for different types of work, e.g.:
User Stories - Pink
Defects - Yellow
Technical tasks - Blue
Tasks - white.
Finally, we added ‘Done’ columns to each of the stages on our Scrumban board, and we named these as ‘Ready for ‘ the next stage.
The Scrumban system was working really well now. Over time we found that we were able to spend less and less time running sprint planning as the team got to know the work more and more. This led us to make the decision to drop sprint planning all together.
Instead of filling the ‘To-Do’ column every two weeks we were able to populate the To-Do column on demand. We kept the fortnightly Sprint review, as this was a good cadence for the stakeholders to review the work done.
We also made some final revisions to the board. We visualised the Process Policies - for us these were the rules that work had to meet before it could be moved into the ‘Ready For’ column. We also visualised a separate swimlane of work that was being delivered by a third party.
So we got there: the team was running a great Scrumban system. We were able to measure lead time for different types of work flowing through our board. Also, we could give stakeholders good estimates of how long it would take us to develop the work item. This meant we could predict with some certainty when we would finish development of a set of work items, but the stakeholders really wanted to know when a set of work items would be going live.
The team that we’ve been talking about here wasn’t responsible for pre-production testing, and then the live release. This was managed by another team, who was working to monthly release cycles.
So we decided to try the same approach and visualise this downstream process too.
This is a drawing of the board that we created. It visualised the release process, from items going into a release queue, being packaged as a release, going into Pre-Production and then into a live release.
The board allowed the release team to visualise their work, allowing us to see and measure the progress of our work into the live environment.
This process started to work well and made us think. We have visualised the downstream work. But what about the refinement work that is done to prepare work items for the development team? This happens ahead or upstream of the development team.
So we decided to visualise this too, on the board below:
This board was really useful to the team members. It visualised the work items that will be coming their way, and allowed them to refine the work so it was ready to be pulled into the team board.
Now we have visualised the Upstream Board, the Team Board, and the Downstream board, we have visualised the entire end-to-end process from idea, to delivering into a live environment.
Going above and beyond
Our work was gaining great kudos from senior management, infact from the MD. The Managing Director took interest in the techniques we were using at team level, and wanted to apply them to his senior leadership team. Soon, there was a visual board in the MD’s office, which mapped the projects / portfolio items that were being delivered by all the teams.
From my experience, in this team and others, Scrum is a great place to start. It gives you the simplest Agile process you need to get a team going. But when a team is going layering Kanban over Scrum, it provides the team with a lens to see where they can make improvements. You can call this Scrumban. Further Kanban can be infectious. At the same time, Scrum only thinks about the product development, whereas Kanban can be applied to a whole system or value stream, and can be applied at the team level, the programme level and at portfolio level.
If you want to find out more about how to use Scrum and Kanban, check out our range of training courses.