Interesting post from John Cutler:
Anyone experimenting in this realm?
Flow, Decoupling Cadences, and Fixed-Length Sprints
kschlabach
#2
It may be brain inertia and stubbornness, but I’m not following this article well. I was mentored to think of sprint boundaries as mile markers on the highway while driving… mile markers don’t move. You can change speed, take detours, even park on the side of the road, but mile markers are constant. Human behavior responds really well to a drumbeat (anyone have friends that dragon boat race?)…
That being said, I also don’t get hung up on “sprint goals” or “cancelling sprints” either. (as I’ve noted over here: Incomplete Sprints - what to do? ) I like to transition a team from strict scrum towards a continuous flow approach, and I use sprint boundaries as a way to roll up metrics and reporting to the upper business. Even in continuous flow teams, having a standup the same time every day, and the team meetings every Tuesday afternoon (review or grooming alternating every two weeks), a PoC release every 15th, and the reporting rollup to management every 2nd Friday of the month… (my current company’s various cadence’s) everyone always works backwards from these upcoming and known “mile markers”. Even during windows of failure, people spend the time entering the room for these ceremonies and are honest and transparent in order to recalibrate and move forward.
So… that’s what works for me when I coach teams. The idea of shifting iteration boundaries is uncomfortable for me…
That being said, I’m not saying it can’t work. I see no issues with it in theory, I’d just want to talk to practitioners that pull it off successfully to learn how they compensate for the things I’m assuming they’d lose (that drumbeat/cadence).
hdietrich
#3
I am currently thinking about possibilities to mix Scrum and Kanban.
Scrum: fixed cadence, ceremonies like planning, reviews, and retrospectives, commitment; all of this is very helpful to raise claims and drive motivation of people.
Kanban: high throughput, limit work in progress, focus, deliver as early as possible; all of this is very helpful to maintain maximal flexibility and drive autonomy and quick learning
Why not maintaining two boards: one Scrum board where we plan for commitments (raising claims for what we want to achieve) and a Kanban board, if we feel like we need to be as fast as possible or need more flexibility (to run experiments and deliver continuously).
A shared backlog and the team is free to decide on which board they would like to push items. They even can move items between the boards if they like (e.g. if impediments are in the way).
Sounds crazy, but I have the gut feeling that this could solve many problems about motivation, flexibility, and transparency in teams.
andycleff
#4
Intriged by the idea of the experiment.
How would you know if things were getting better or worse?
How could you make the experiment simpler? More complex?
andycleff
#6
One more question: what is your goal for the “future state”?
mixing Scrum and Kanban feels like an interim state to me…
I can see fixed cadence for retro as the only thing that remains in the future state…
The rest of the “ceremonies” would be when needed, as dictated by WIP limits…
A true pull system…
hdietrich
#8
When starting to reply to your questions, I experienced that it was getting more and more I have to tell. So sorry for not having replied yet, but I am close to pressing the send button now 
Yes. I wrote a blog post about this earlier this year, https://www.jrothman.com/mpd/agile/2017/04/thinking-about-cadence-vs-iterations/. When I coach teams, I rarely find that teams new to agile can use the idea of a sprint goal because they have so much interrupting work.
When they use the idea of: flow small stories that are valuable and release them, and then plan and retro as necessary, they find that they release more value more often. I find that the PO needs coaching for what a small story is. (So does the team, but the PO is first for me.) I wrote more about this in Create Your Successful Agile Project.
For me, it’s not so much about mixing kanban and scrum, as much as it is seeing how a team can flow work through their system and get something out on a frequent basis. I like to encourage teams to release something every day.
hdietrich
#10
@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!
andycleff
#11
<3 x 10^23
This is wonderful!
My early morning thoughts:
c) which ones need urgent action and cannot wait on a specific release date (Emergency Lane of a Kanban Board)
I am always worried about expedited class of work items. I’ve never ever found a way to accept them without heavily impacting the delivery of everything else. Instead, I’m striving for better flow efficiency, and predictable cycle times that are getting shorter and shorter.
Daniel Vacanti goes into great depth on the impact of an “emergency lane” in his book https://www.amazon.com/Actionable-Agile-Metrics-Predictability-Introduction/dp/098643633X
measures for continuous improvements
If you have a clear way of tracking arrivals and departures into your kanban, you’ll be able to get a CFD going where you can visualize the impact of service level agreements, policies, WIPs, etc.
You’ll only have to measure two out of three variables in Little’s Law, you’ll get the third for free : )
Either version will do:
- Average Items In Queue = Average Arrival Rate * Average Wait Time
- Average Cycle Time = Average Work In Progress / Average Throughput
I like very much your four lines of team health inquiry.
Sandi Mamoli developed something similar; she calls it the “Happiness, Innovation, and Productivity Survey”
There are a half-dozen questions, some coming from Daniel Pink’s Drive. Team members respond using on a 5-point Likert Scale.
- Purpose: Are we doing meaningful work that comes to fruition?
- Creativity: Are you allowed to do what’s best for your work by focusing on one thing at a time?
- Autonomy: Do you have a direct influence on how you and your team works and solves problems?
- Relationships: Do you work on a team where people support and challenge each other?
- Mastery: Have you been able to learn new skills at work?
- Creativity: Can you be creative at work, through success and failure?
There are many other Team Health and Wellbeing visualization models I’ve come across:
And would love to chat with you more on the topic of visualizing team wellbeing… without it becoming another Hawthorne Effect or example of Goodhart’s Law
And finally, since we had a thread of music, I can’t help but draw a parallel to your experiment…
This is agile jazz improv at its finest! Can’t wait to hear a few tracks from the album…
hdietrich
#12
Big thank you for the extensive ad-hoc feedback! I highly appreciate your views.
On the emergency lane we do not have to argue: Whenever someone finds a way to come around this lane, do it!
In practice I did not find a way to come around some specific emergency handling in the past. Presumably that’s due to the nature and maturity of the products and teams I have been working with.
I appreciate your links to Management 3.0 and Daniel Pink. Both of them are a source of infinite ideas. I always get back to them again.
The moving motivators are an excellent tool for personal reviews. I have used them several times and they worked always.
Furthermore your post points out several ideas I did not hear of so far. I need to dig into more details 
Visualizing team wellbeing is an interesting topic. There is a high interest in visualizing the status and keep track of it. Even though I feel like there is always a delay in the recording - it captured what has been recognized, not what is coming up. So you are mostly looking at the past. That’s becoming boring soon.
I always find it interesting to look for ways to identify the gap between the status and the vision. This is where the creativity goes.
I always appreciate a good jam session
andycleff
#13
I’m experimenting with TeamMood.com - a daily email or slack prompt. Closest to real time I’ve found. Great for large and or distributed/hybrid teams.
You could play with the timing of the prompt - beginning of day vs end of day…
Regardless, I am finding the Team’s Mood to be a strong leading indicator of other things, especially when we can visualize trends over time:
The peaks are vacation days (July 4th, Thanksgiving, Xmas).
And guess the quality of code shipped in August…
andycleff
#14
Simple but never easy, say “No.”
Can you show the impact of saying, “Yes” on all the other work in the stream?
Introduce them to Dr. Little.
And if that all fails, have a WIP limit on the lane = 1 and enforce it.
And if cycle times are too long, reduce the WIP further
hdietrich
#15
What is the purpose of team metrics? Isn’t it another way of reflection on the effectiveness?
Btw. your mood board looks pretty stable.
My experience with mood boards have been major deviations in mature teams. There were times they felt like heroes and times they felt really bad. Anyhow, there was no surprise to them and to me, as everyone knew it more or less. Unexperienced teams knew they were no heroes and they never dared to tell they feel bad. But I was partially able to influence the voting by doing small exercises upfront. Anyhow, there was no long term effect or value from it.
That’s why I started to think about more robust health checks and I have started to put things in relation - allowing even contradiction in terms, if people were unsure about reasons (like delivering bad quality, but being happy about the work as such).
Measuring teams - how, what, when, why?
andycleff
#16
The plot is an aggregate of 110 people. So on average, yeah, things are stable.
Where things get interesting is when we drill down by “tags” - particular teams, and/or particular roles.
Also, another feature of TeamMood that is nice: optional, anonymous commenting that goes along with the moods. A real time journal.
Becomes fodder for the upcoming retro…
Long term effect or value? Not sure yet… so much depends on the overall system. One potential I see is a looking glass for those who are not so connected on a daily basis with the teams (Senior Leadership, for example).
More robustity (i made that word up) is indeed needed… measure many things… get a holistic view… and don’t set targets…
I’m curious to hear you unpack “But I was partially able to influence the voting”
AnLeBe
#17
Thanks for the interesting link and discussion. I thought https://hackernoon.com/scrum-is-the-best-thing-in-the-whole-wide-world-a2eb19a26c32 was a bit aggressive, and I say that even though in principle I agree…
hdietrich
#18
Yes, there is some kind of aggressive, nagging tone in there.
What is the message that John Cutler is sending with his posts? I know that he is a string advocate of simplifying things, but I am not sure how especially that message has been perceived by others.