@andycleff @bradstokes thanks for showing interest; that’s making this thought experiment exciting to me as well
Let’s be clear - everything I am writing is lacking a proof. It is based on observations, experience with different Scrum and Kanban setups, several experiments, and a strong, gut feeling about how things should be. So we need to be brave to dive into the topic:
My belief: we will benefit a lot from the duality of Scrum and Kanban!
Duality is the key to stability and flexibility at the same time. While both seem to be exclusive, they need to come together.
I am not saying, that there is no way to maintain flexibility in Scrum and Kanban does not provide ways to introduce more stability.
But if you want to be successful on the long run, you should get back to the strength of each of them. And I am looking for long term effects, not short term solutions.
Two metrics are building the foundation: the happiness of the users (consumer) and developers (creator) happiness.
Both parties will run for stability and flexibility at the same time. [more on measuring metrics later on]
The user community will want to get an idea of what and when they can expect updates and upgrades (results). It is their understanding of a stable development. It is the core value they perceive.
Development teams prefer to have a fixed framing for releases as it is their basis for planning for quality from the beginning. Knowing what, why, and how is their understanding of stability. It is the basis for predictions (what can I achieve)!
Still, developers know that software development cannot be planned in detail. It is creative work, which needs some flexible approach to be successful.
Also, users want to see a timely response to change and they want software to be free of issues. I think it is also valid to point back to the Kano model in this context (https://freeagile.org/2017/10/01/prioritizing-product-features-using-the-kano-model/), which shows the importance of “delighters” in relation to expected features. Flexibility means, being able to delight users.
Here is my statement for long term success in product development:
We will not survive without a cadence - nothing will be of value without the vital pulse.
But we want to be flexible to do steps out of sync with the pulse.
It will help us to accept and cope with stumbling blocks.
Escape from a prime rhythm - for a while - adds tremendous value; a bit like a funky groove in a classic beat.
Becoming better over time - as we maintain retrospectives on a regular basis - we could expect to learn how to move stumbling blocks out of the way.
On the long run pure Scrum would become the perfect scenario, as we would know which things to come at which time.
Let’s be clear: there is no perfection! So for me there is no reason to bother around with perfection. We need to accept the duality.
But enough for the reasoning. Let’s move over to the implementation of such an dual model:
What needs to be done?
We are only interested in things likely to happen in a reasonable amount of time (for the products I have been working for, six months was always a reasonable timeframe to look at).
Users are interested in what come next in a sense of what can I expect to happen.
For existing products, everything beyond this timeframe would be part of a vision - “it would be great to have, but I will not wait for it now”.
So I start from a funnel of things, which need to happen “next”. The rest is moved back to the universe of endless things, which would be great if we just would have more capacities.
At this stage we can consider already,
a) which things are stable enough to be planned in sprints (Scrum Boards)
b) which ones are too complex and require more thinking and/or discovery and cannot be predicted (Kanban Board) (see also https://freeagile.org/2017/10/01/stacey-matrix-adapted-to-software-development/)
c) which ones need urgent action and cannot wait on a specific release date (Emergency Lane of a Kanban Board)
It is a bit like distributing stories to the studio, where our “commodity work” is happening, which helps to move on the product with a steady speed, the scientific lab, where new opportunities are created and we will invest into “delighters”, and the hotline for those things, which are annoying and cannot wait.
You might see the analogy with the Kano model again.
Distribution of stories is happening in grooming sessions (exception: urgent issues reported by users are assigned to the emergency lane immediately!).
Now, the team can pull items from the funnel (they also can kill items from the funnel and add new ones in line with Product Owner and UX expertise).
In general the team will decide from where to pull items based on their capacities and urgencies.
The first look will always be at the Scrum Board. Where am I right now?
What is the status of the current iteration? When will we plan the next iteration?
This will give the team an idea of the possibilities to plan for a new sprint or changing the scope for the existing sprint.
This is the contribution to stability - for developers and users.
The second look goes back to the funnel. What else is of importance?
What kind of items are planned? Is there anything, which needs to started urgently?
This will give the team an idea of the need to start items outside of a sprint.
This is the contribution to flexibility - for developers and users.
Now the team has to consider:
a) if the upcoming iteration is to be planned by picking new stories
b) if they are ahead of plans in the current sprint and the scope can be extended by an appropriate story
c) if an urgent item is to be done before end of the next iteration
d) if they have to start working on another item outside of an iteration
If the considerations result in a conflict, there is no simple rule to decide what to do next.
Literally it is the sense of urgency within the team, which is to be considered. Everyone can propose next steps and everyone can oppose to proposals.
Anyhow, one item has to be picked in the end.
Conflicts are to be moderated and resolved by the Scrum Master (and if nothing else helps: one of the tools can be tossing a coin).
Planning a new iteration is following the Scrum principles.
We are planning for a steady throughput of stories. The team is picking adequate stories for the next iteration they will want to deliver.
As we are adding the ability to pick arbitrary items, we need to make sure, that the team is not overloaded by too many work in progress.
We need to apply a “work-in-progress” (WIP) limit to all items.
Limits will enforce strategic decisions in the team. They cannot start new items for an iteration, if the WIP limit is reached.
The development aspect, where all of this culminates, is the delivery.
The delivery is the occasion, where expectations and efforts are traded (I love the analogy of development plans are like placing a bet). The team will be happy or disappointed about the results and the users will be happy or disappointed about the results.
Upfront I wrote that happiness of developers and users are the core metric. So here it is.
How can we make the most of this metric now? Definitely not by doing sporadic or percipitate releases.
Deliveries are events and require some preparation
Unless super urgent or super special I advocate to make use of the base cadence for regular deliveries:
With the end of every iteration a shippable increment should be in place (this is the purpose of an iteration!). This can be assembled from a) the results of the iteration (as planned) and b) things, which have been done in the meantime outside of the box.
The delivery at the end of an iteration will be expected by the user. We need to keep track of it and maintain transparency on the content to set expectations.
On top, we add delighters, like additional goodies or resolutions to known short comings.
Only things, which are super urgent (blockers and critical issues - not only bugs, but also corrupted features) or which are really special, go into individual releases.
Special occasion could be the revamping of an UI, where user tests will not allow a concrete prediction and/or the impact is that high, that it should happen outside of the standard cadence.
For retrospectives no special considerations have to be taken. They must happen on a regular basis and involve the whole team.
Eventually you will want to add the finding from a retrospective to the board. It allows to plan for intermediate actions!
How could such an implementation look like?
A board for maintaining transparency on the implementation of the “Dual Beat Model” could look like this:
The complexity will be a challenge - maintaining the board in a team requires more strategic thinking, than a pure Scrum or Kanban board.
I am looking for cross-functional teams, which are taking over responsibility and are accountable for their plans. This requires a strategic thinking anyways.
It requires a team.
A complete team must consist out of team members taking over the functions of Product Ownership, UX Expertise, various Development Skills, DevOps and QM Know How, plus a Team and Process Facilitator (aka Scrum Master, see https://freeagile.org/2017/12/14/daily-routine-the-scrum-masters-challenge/).
Without such a team there will be no pull, but a push at some point again.
About using measures for continuous improvements I have some specific ideas.
There are various numeric metrics, which can become relevant - throughput of stories, number of issues reported by users, time to response. The value of them depends on the interpretation.
I have good experiences from starting from a health check. Based on the results I prefer to align on adequate measures within the team.
For this reason I have developed and tested a survey sheet, which helps a team to reflect on its performance. It has been perceived very well. Results are tangible objectives rather than pure metrics.
Why is this important? It is not about anyone from the outside to measure and rate a team. The team has to develop the measures on its own.
This is the basis for trust, which will be relevant for working in a team again.
This is the survey I have been using:
Final words on this write-up:
I am a system thinker and a “power-to-the-people” romantic.
This is my idea of a working system. It is not the story about how to get there!