This is the third chapter of “When a Scrum Team tastes Kanban series”. By now, you already know why we decided on this experiment and how the process of transition from Scrum to Kanban worked. This article will be more meaningful if you revisit the previous two chapters.
We designed this as a 6-week experiment, with certain steps that should be taken in that period. As with all experiments, there should be a review and evaluation to decide whether to continue or drop the idea.
In this final article, I would like to describe what happened after our experiment: what the team decided, what changes we made in the process, where we are now, and what impact it had for the whole company.
How we analyzed and adjusted the process
Our experiment was set to last for 6 weeks – after this period, we carried out a team review and analyzed how the process had met our needs. It turned out that with a few small adjustments, this was a way of working that we wanted to continue using.
What did we decide to change?
- We added regular refinements with the Product Team.
- We changed responsibilities for changing the status of stories – at the beginning, it was a responsibility of the Product Owner to push them to the ’select for development’ stage, but it was easier when it was the decision of the development team who took priorities into consideration.
- We added more flexibility to the push/pull flow – Kanban is a pull flow, but for us it was more natural, for example, to push for ‘code review’.
- We began to use timelines for bigger functionalities – it was necessary for the Product Owner to know when a story/epic would be ready, and this also helped the development team to coordinate deployment and see real progress.
- We decided to have review meetings on demand, as and when needed.
Right now we have been in the Kanban flow for a few months and recently we decided to re-check our impressions. We thought that our conclusions might be different for different roles – Scrum Master, Developer, Business Analyst, etc. Let’s see…
- It was a positive change to have made.
- We didn’t solve all of our problems – some of them are still current.
- We haven’t wasted time on ineffective planning meetings – we planned meetings only when needed, giving us more time for coding.
- We had very clear of when a story was ready for development.
- We had more continuous development – when a story was ready for development, free developers were organizing themselves along a planning timeline and estimating this feature (asynchronously, without pushing from the Product Owner or Scrum Master).
- QA was looking more via the product board, with the Development Team more focused on the developer’s board – with all the subtasks and more detailed development statuses, this was more convenient for us. However, we lost the total overview – the Product Owner didn’t think about stages of implementation (for example ‘code review’), and developers were not thinking about the bigger picture.
- QA had the opportunity to convince the Product Owner to engage in story-splitting, to decrease refinement time.
- Developers didn’t notice communication with the client being easier, but both QA and the Scrum Master did.
It was a big surprise for us, that for the most part, we were thinking along the same lines, with only small details being different.
What are current problems
- Refinement time (before the story is ready for development) – sometimes we were still tied, with QA BA having to wait for answers.
- Unclear responsibilities and priorities – it was hard to decide who should make a final decision on what is going to be “selected for development”, and what is more important, the backlog or the story map for the whole quarter.
- Respecting limits for each column and adjusting limits for a smaller team.
Kanban was a good solution which helped us with a lot of the problems we had been experiencing, but the core for a good agile development process is good communication and clear information: who is responsible for making important decisions and answering questions? Without this, you can work on the process on your side, but you will still be stuck with some of the problems.
How transition from Scrum to Kanban has influenced our company
This was the first time XSolve had a team experiment with a deep use of Kanban, allowing us to think more about flow, opportunities, and metrics. The rest of the company was pretty sceptical about it because of the low amount of boundaries and strict instructions/checkpoints in this framework. When we dug into the process, we found some important bottlenecks and now we can work on them. We are not masters of Kanban, but our understanding is much greater than before.
We opened the eyes of the rest of the company to new paths and ways of working – that maybe Scrum isn’t the answer to everything, maybe there are some projects which are better done in Kanban. We were the trailblazers and after this project there have been more experiments. For example one project relating to maintaining applications for our HR team decided to try Kanban and found it the best option for them.
After a few months, and watching different teams and projects try the Kanban approach, we are definitely more knowledgeable about when to use it and when not to. For sure, it’s always good to try Scrum at the beginning of a project because of its well-defined checkpoints (sprints).
If you are wondering, we have so far decided Kanban may be a good choice for:
- maintenance projects,
- projects with frequently changing priorities,
- anything where resolution time is important.
To sum up – we believe in agile work, and Kanban is one flavour of Agile. If you won’t try it, you can’t say you don’t like it. It’s always worth experimenting, but for the experiment to be meaningful you should know exactly why you are making the attempt and how you will know whether or not it is a success.
Inspired by this article? Don’t miss previous pieces: