The Journey of Merging Scrum with Kanban in My Context
During the last year and a half, I was working as a Scrum Master with a team that was working on a product with a history of about ten years. When I started working with the team, they finalized a platform migration and were still struggling with a lot of remaining work. There was a climate of mutual blame between product management and the development team. They told me they are using Scrum, but there was no Scrum Master, no potentially releasable increment at least at the end of the Sprint, no event discipline, several Product Backlogs and so on. All in all, a very challenging situation. I took some time to at least enact “mechanical Scrum” with its roles, artifacts & events and motivate the team to be constructive with each other. However, at the beginning of last year, there were still a lot of things to improve regarding value delivery and team morale.
The Scrum with Kanban Beta class
Having used Kanban before and as a lean practitioner, I was excited that end of January last year I had the chance to join a Professional Scrum with Kanban beta class, facilitated by Steve Porter in the awesome office of Prowareness in Delft. I think it is a great initiative to cross the bridge between Kanban and Scrum. The class was a great learning experience, where a bunch of Professional Scrum Trainers discussed the class material and the approach itself. At the end of the class, we mostly shared the opinion that it is worth it to continue and on my way back home, I was very motivated to make the things happen that I learned in the class with the team.
The Team Start
Following the Kanban principle of "Start with what you do now” and causing an evolutionary change while respecting the current process, I decided to start working with Kanban as a complementary strategy on my own. For me, the usage of flow metrics was the central learning in the class, and I was curious about what would happen when I started to measure them. To do that, I began to define our workflow. Concretely, I defined when we consider work to have started and to have finished. Additionally, I decided that it is valuable to track each type of Product Backlog.
The first big issue that was obvious to me was that we had many “Orphans” in our workflow - items that we start working on, but that we never finished. We accumulated more and more work so that we were constantly increasing the item's cycle time and decreasing our throughput. Thereupon we had some bold discussions with the Product Owner and the Development Team on how to proceed with these “Orphans”. Several we quit working on because they got obsolete, others we sliced into something that we could finish and the others we finished item by item. We paid back our flow debt step by step, by finishing more and starting less. That was our first significant step to achieve a stable system where work was getting predictable.
For more information about the underlying assumptions, you can check Daniel Vacanti’s whitepaper on “Little’s Law for Professional Scrum with Kanban”.
Flow Metrics and Flow-Based Events
After we already had a lot of good discussion about flow in general and the metrics themselves, it was time to use them more broadly and dedicate more focus to manage our work in progress actively.
In the Sprint Planning, it happened quite often, that the Development team pulled too many items into their forecast. Combined with working on too many items in parallel, it happened quite often that at the end of the Sprint we did not reach our Sprint Goal nor the forecast. Introducing Throughput combined with the Monte Carlo Simulation “How Many” as a Sprint forecast indicator gave us a much better instrument to learn what we really could achieve in one Sprint and led to much healthier discussions, than something like, that is our velocity, and most of the items we nearly finished, so let us take on a lot of new items.
After some Sprints we realized that this helped us to make a more predictable forecast, it was obvious that using estimation and velocity as we did it before did not make much sense anymore. The Development Team was not confident to drop estimation at all, so they changed estimation in a way to estimate the number of weeks to finish an item. As we have three weeks Sprints, the Development Team estimated an item as 1, 2 or 3. I am not sure if I would recommend this, but it worked well for us, as it moved the discussions from what is the relative effort to how long it takes to get done.
The event that has changed the most definitely was the Daily Scrum. Before we used to do the standard three type, I related questions, Daily Scrum flow, that tends to end in a boring status report. Now we are focusing on items from right to left in our workflow and talk about what we as a team can do to get them done and where we have to synchronize. We identify and discuss bottlenecks and items that are aging and reaching our agreed Service Level Expectation. Likewise, team members ask for support if needed. Our Daily Scrum events now are precious and lovely social events that everyone enjoys.
As many other teams that I know, we have a regular timeslot where the whole team meets for Product Backlog refinement. From my experience teams often tend to do refinement at the dedicated time and do not focus on balancing the amount of “ready” items. That can lead to a situation where there are not enough or too many “ready” items. In our case, we tend to have too many “ready” items. As an instrument to balance the amount and effort we need for refinement, we started using the Monte Carlo Simulation “When”, which helped us to balance our funnel of “ready” items and not waste our time.
During our Sprint Retrospectives, we used the flow metrics to have evidence-based discussions on our way of working and found valuable action points and experiments for upcoming Sprints. As we are a distributed team with three locations, some things are better to discuss when we gather. We used one of these events to visualize our actual workflow and define explicit policies. Of course, we also defined how we limit Work in Progress (WIP). Interestingly enough, we came to an ad-hoc decision of two items per each developer. Yes, I know developers should not “own” items, but I think you could not prescribe swarming or mob programming and that is something that can evolve within the team.
The picture below shows our one year Cycle Time Scatterplot, which gives clear evidence of our flow improvements and time to market. To amplify this, we came from a release cycle of every three Sprints to a cycle of three releases a Sprint, while reducing our release stabilization time.
Conclusion so far
While we improved our time to market and team satisfaction, it became more and more evident that we need to put more focus on the outcome and impact of our work. How can we gain customer impact and improve our customer’s satisfaction? The problem that is worth solving, we call that “Shakura”. A first step was better predictions on reaching our Sprint Goals, what we achieved.
The next step on our roadmap is to integrate UX Design in our way of working better; make the Sprint Goals more tangible, valuable and customer-centric; learn to think in terms of business outcomes, customer collaboration, user-centricity to find our new definition of success.
Our Product Owner meditating on Product Vision & - Metaphor
During the journey I described, I developed the stance of a Flow Manager. As the team and its members are still quite inexperienced on their Scrum journey and need more influenced-based orders, I think it is good that I took that stance and coached the team in their growths. (For more information about Leading Scrum Teams to maturity read Ron Eringa’s blog post of the same name.) Mainly when I was not there, the discipline sometimes slipped away, WIP limits were not respected, and work item age exceeded our Service Level Expectations. I would be delighted to see more Flow Managers in our team and finally start self-organizing flow management.
As a trainer, I am happy that now I am licensed to facilitate the Professional Scrum with Kanban (PSK) class in a way that through my practical experience that I have, I can give a profound learning experience to all the trainees with whom I will still work. What helped me on my journey of reflecting my knowledge were Daniel Vacanti’s books and the Scrum.org PSK assessments. The two books also gave me some good arguments for the challenging discussions we had several times in the team. I like thrillers, and as a kid for some time, I wanted to be a detective. Therefore, I think I am fascinated to play with the ActionableAgile analytics tool. There are so many things you can find out by just inspecting the metrics and then pointing out your evidence-based assumptions.
Everyone who is interested in optimizing the flow of customer-value, I strongly recommend to take an in-depth look at Professional Scrum with Kanban stuff and try it out your own Scrum context. This strategy cannot only improve value by a faster and more predictable time to market, but also increase the Scrum Team collaboration. By doing it right it is fun and leads to a more enjoyable working atmosphere.