In this post I’ll describe the evolution towards ScrumBan as a natural way for the growth of Scrum teams. Let’s in addition ask the questions why to start with Scrum at all.
There is a lot of discussion ongoing and lately I followed an interesting one about Scrum is designed for misuse by Mike Sutton and the great reply Scrum fails, I’m told endlessly by Ron Jeffries.
In the beginning…
In my experience Scrum is a great starting point for young teams – teams that are new to agile software development – where applying an agile method makes sense (e.g. use the Cynefin-Framework to check when to use what method). Scrum provides a simple set of rules and ceremonies including a role for the agile coach – the ScrumMaster – that focus on helping the team understanding agility and how to apply Scrum properly.
Structure helps in the beginning as it removes the trap of too much freedom and missing important pieces. Scrum and it’s parts build a memeplex and removing parts of it can destroy the whole meaning of it.
Scrum’s set of practices, already exercised around the world, like
- cross functional and self organizing teams,
- retrospectives,
- daily standups,
- the focus on the most important topics,
- customer value focus,
- to include the customer/user as early and often as possible
- …and more
combined in a properly described format is of high value to get into thinking and working the agile way.
A group of people become teams and not just a bunch of individuals sitting together in a room. The focus on meaningful outcomes provided by the role product owner supports the intrinsic motivator purpose.
For me this makes Scrum a great starting point to introduce teamwork and agility. It should always be accompanied by professional coaches who really guide you through the heavy change process connected with introducing such a fundamental shift.
The evolution starts…
Over the time when teams get to a more mature state they’ll realize that some of the defined boundaries by Scrum (or the quasi standard added features like estimation) are actually hindering in becoming high productive and reaching the optimal flow for delivering high quality product increments. It’s time to adjust and add/change/remove artifacts consciously.
Changing based on a deep understanding of the original subject to change and supported by data during the change (e.g. by using experiments) is in my opinion really important (e.g. by applying a lean change approach).
Consider other influences in agile like lean, management 3.0 to discover possible extensions and changes – some great teasers are:
- 2 pillars of Toyota production system
- 14 principles the Toyota way
- 5 principles of Lean Thinking
- 7 principles of Lean Software Development
- Deming’s 14 principles of management
Based on lean we strive to optimize our flow (by removing all kinds of waste like inventory, delay, rework and overproduction), to deliver highest quality possible and address+discover market needs as fast as possible all done in a joyful way.
I like the 5 guiding questions by Mike Sutton:
Estimates using Story Points or Ideal days are not longer necessary (by the way so far I did not get the deep understanding of the Story Point concept …beside it’s a relative estimation of SoMeThiNg and I really tried to understand it by discussing, reading blogs/books … discovering that there is even no consensus among the leaders in agile) … but good news … use #NoEstimates and remove the waste of estimation (and still continue understanding what to build!)


Prioritization is done on demand, keeping only that much stories prepared in advance to avoid a stalling flow.
The ideal work planning process should always provide the development team with the best thing to work on next, no more and no less.
Standups start enumerating on work items and not longer people and are focussed on problems to the flow (it’s not a reporting how busy everyone is but a full focus on our product delivery, trusting everyone that they will raise impediments and do a meaningful work).
Burndown charts get uninteresting as soon as variation is under control and cycle time + WIP become key measurements.
The release cadence gets decoupled from the iteration length searching for the optimum point between cost of deploying a new release vs. opportunity cost of carrying finished inventory … with ideal target of deployment on demand.
And leads to…
Evolution leads to having a ScrumBan environment. Combining the best of the two approaches (Scrum and Kanban). Using retrospectives in intervals (iterations ;-), using dailies, maybe reviews but all considering lean.
Have fun in your journey and evolution! I’m looking forward to hear your steps? Do you see a contra-dictionary way?
[…] Scrum and Scrumban as it’s next evolutionary step […]