I’m fed up with organizational dysfunctionality
What is Large Scale Scrum (LeSS)?
Talking about Sizing and Forecasting in Scrum
Can Scrum be used outside software development?
Who is responsible for a scrum team’s performance?
What is Cycle Time in Kanban?
What is Cycle Time?
Who is responsible for a scrum team's performance?
Who writes the acceptance criteria?
Setting Expectations in Scrum and Monte Carlo Probabilistic Forecasting
Why you might need an island of agility?
So, what is organizational agility? 2022 UPDATE
How can Scrum with Kanban help people solve complex problems?
How to use Evidence-Based Management and Scrum (Part 1): Bridging EBM goals with the Scrum Guide
Tobias Mayer on Agility
Haydn Shaughnessy - Digital Transformation hero
Pia Maria Thoren and John Coleman discuss agility & its importance
Why organizations need to widen the scope of agile, and how to start?
lDiscussing “Agendashift” with Mike Burrows
So what is organizational agility?
So, what is value, really?
2020 Scrum Guide — addition of commitments to each artifact
Don’t be an apprentice in the negative sense of the word
Kanban - the Flow Strategy and Kanban for Complexity (Kanplexity)
Bulls? Bears? Wall Street's pigs at the trough
The black hole - a story of indigestion and constipation
MORE SUCCESS
Leave the place tidier than you found it.
Agile Vs. Scrum – what is the difference?
A Workforce Of Multi-Skilled People – what's in it for the executive or the employee?
Clarity, Strategy Deployment, and Strategy Realization
The nature of the human condition
Pivot: Real Cut Through Stories by Experts at the Frontline of Agility and Transformation
Kanplexity
X-agility Executive Agility
Basic/ally Agile
Orderly Disruption
Top 50 Agile Leaders of 2022
Journey to an Agile Island
Why you might need an agility island?
Hit Delete - unlocking executive agility one deletion at a time
Xagility podcast - Pia-Maria Thorén of Agile People
Flight Levels Day
Panel of experts
Flight Levels Conference - Experts Panel
Balancing UX with shipping fast in scrum? A deeper look into each box of the Lean UX canvas
X Agility Podcast: Joe Justice
Constraints, work capability, throughput and flow
Joe Justice on his career, Tesla, Space X and agility
What the developers do in the last week of the sprint?
Can scrum and agility be scaled and what’s the best way to do it?
Gene Gendel on his LeSS career, LeSS case studies and whether we can measure adaptiveness
Value and Kanban: isn't Kanban just about outputs?
Bruce McCarthy on his career, product vs project management and, getting roadpmaps right
Jim Benson on Personal Kanban, The Collaboration Equation and the system of Humane Management
Daily Flow - dealing with complexity in a Kanban footprint
Daily Flow: a story about story points and an alternative, throughput
Indi Young on why you shouldn't look at a problem through the aperture of a solution
An interview with Jared Spool
Klaus Leopold on the value of Flight Levels and his book Rethinking Agile: Why Agile Teams Have Nothing To Do With Business Agility
Reviewing Cynefin - weaving sense making into the fabric of our world with Dave Snowden
John Coleman of Orderly Disruption meets Pia-Maria Thoren of Agile People
The theory of Scrum team effectiveness and evidence supporting it with Christiaan Verwijs and Dr Daniel Russo
Robert Kinnerfelt chats with John Coleman about Holacracy and Sociocracy (Teaser)
Walking through Empowered with Marty Cagan
University of Westminster PSM classes
Teaching at University College London (4 day User Experience workshop)
John Coleman profile on LeadersHum
Hit Delete
Author of Kanplexity
ProKanban.org Applying Professional Kanban
Professional Scrum with Kanban
Scaled Professional Scrum (SPS)
Professional Scrum with User Experience (PSU)
Professional Agile Leadership - Essentials (PAL-E)
Teaching Scrum.org Professional Scrum Master I for University of Westminster
How to manage discovery and delivery work on a Kanban board?
On a Kanban board, you have
- a definition of workflow,
- a start point,
- a finish point,
- a cycle time (how long does the work take to get from the start point to the finish point),
- throughput (what is the rate of items being delivered across the finish point per time period, e.g. per day, per week, per sprint),
- work item age (what is the elapsed time from which a work item has started, but has still not yet finished),
- Work-In-Progress (WIP) (all the items that are within the starting point and the finish point).
Types of Work on a Kanban board
You could argue, on a Kanban board we have:
- discovery work;
- development work; and
- delivery work.
Discovery Work
Discovery work would be, for example, research to figure out whether this is the right thing to build for the customer. Maybe we are doing some experiments or some prototyping. It is very wise to do experiments when we have insufficient evidence so we can harvest the proposed value because at the end of the day, our work items are bets at best. They are ill-informed opinions at worst if you do not experiment. You could just fill your funnel with stuff to develop and maybe there is no evidence you should actually develop it. So discovery is about discovering value, it is about learning.
Development Work
Development is about building the product, making the product.
Delivery Work
Delivery is about getting that work that we have made and giving it to the customer.
The 4 Time Horizons You need to think about on your Kanban Board
You could argue there are four time horizons.
- Discovering the “next best thing”.
- Developing what we now have evidence is the right thing to do.
- Delivering the stuff that we have got to a stage that is ready for a customer to consume.
- Looking back at those previous releases that we had, those deployments that we had to the markets, did they actually make a difference? Did we change customer behaviors? Do we reap some organizational value? Do we improve our reputation as an organization? Do we improve employee satisfaction? Do we reduce our plastic footprint? Do we reduce our carbon footprint? And so on.
The question is…what do you do with this work?
Kanban vs Scrum: the approach to the backlog
In Kanban, the backlog is optional. Unlike in Scrum, where there is a product backlog, which is mandatory, it is an artifact.
In Kanban, the backlog is optional. You can also have a funnel, which is like the backlog for a backlog. This is another optional container that you might have on your definition of workflow.
Managing the Time Horizons
There are multiple patterns available for managing these four time horizons. The thing is that we are managing WHAT type of work it is as opposed to WHO is doing the work.
In a modern team that is trying to practice agility, I would hope that people are trying to learn other skills. The reality is that the people who do discovery have a lot of work to do and there are usually fewer people who have the skill to do that discovery. What I often find is the people who do discovery are often coaching, mentoring, teaching, and willing volunteers who want to learn how to do that discovery.
For example, someone doing development might be invited to a customer interview to just take notes and gain an appreciation of what the customer/ end-user wants.
Another example is a developer who might be asked to do some low-fidelity prototyping. Perhaps maybe even practice their skills doing customer interviews because we need to be careful: either avoid loaded questions or as Indy Young would say, maybe just do some deep listening. Listening to where the customer wants to go with the conversation.
John Carter (the inventor of the BOSE noise canceling headphones) said in the test shop that they had in BOSE, when they had people come into the music store they were purely just observing where the customer goes, not pointing them to new innovation. They were just seeing if they pick it up, what they do with it, what did they discover. Lo and behold, instead of discovering that customers wanted to improve the sound fidelity, they liked the whole idea of noise cancellation. Noise canceling headphones were discovered by accident, through an accident of innovation.
So we are trying to have as many innovation accidents as possible, because in reality that is where most innovation comes from (and also through twisting previous inventions for a new purpose).
Discovery is never finished: How do we navigate this?
The challenge is that there is so much of that discovery work and discovery is never finished because the people who do discovery also were involved in doing usability testing as the work is going through development, for example. They also analyze what is going on after the work has been released to the market to see how people are interacting and what or where they are dropping out. So maybe helping product managers to look at the customer analytics and understand what is going on.
In a dynamic trio, for example:
- a technical person;
- a design person; and
- a product manager
could get together to talk about, okay, what do we understand we need to do here? What do we need to discover next? What do we need to deliver next?
So how do you manage all of this?
You could have, for example, columns for:
- discovery;
- development;
- delivery;
- getting feedback.
“Measure and Tweak” is a column name that I quite like.
The thing is that not every item that goes through discovery will go through development because we will probably discover that most of the items should not be built.
We know, for example, from several editions of the Chaos Report from the Standish Group that two-thirds of what we build is never/rarely used. So we want to discover as much of that as possible before we build something. If not, we are just filling the development funnel and the delivery funnel with work that might not be valuable.
Another pattern that I have seen is, instead of having columns for those stages (which assumes that there a sequential process), maybe having swim lanes for those. This is because some work might go back from development into discovery, and some might go from measure and tweak back into discovery.
REMEMBER: On a Kanban board, we do not want work items moving backwards.
The use of swim lanes can avoid that problem.
Using good heat map reporting, you would be able to see where the work is spending most of its time.
Split work-items
In terms of work items, I tend to separate discovery work items from development work items. You could argue that development and delivery could be combined because we want to get some value.
There is value in discovery because remember, value is also about learning. So, as long as the discovery results in some learning about something being good or bad, validation of some hypothesis, meeting some people matching our personas, for example. Perhaps you are not into personas, but you have talked to some people, you have run some experiments. What did you learn?
There is value in that learning.
I have no problem with work items being there for discovery. And then there would be other work items maybe for development/delivery.
As long as each work item is valuable, that is fine.
So I talked about split items, and now I will be talking about combined.
Combined work-items
You could also have work items that have all:
- the discovery work;
- the development work; and
- the delivery work on the same item.
With subtasks for the individual discovery, development, and delivery tasks, for example.
Each of those subtasks in themselves contributes to the delivery of value, but in and of themselves are not valuable. So the entire work item itself is valuable.
The problem that I see with that approach is that it leads to what I refer to as execution bias, where there is almost a kind of path of least resistance to continue to develop and deliver, even though we might not have evidence that we are on the right track. So we want to visualize as many signals as possible. We want to see what options we have. That maybe is building up some evidence that we should develop and deliver them.
We want to see what is going on in development and delivery. We want to also see what are we measuring and tweaking and what are we learning. So we are getting that learning cycle, that empirical loop of deciding what to do next based on what we learned last.
Often what you will discover is the outputs that we deliver to achieve outcomes are not the same as maybe what you might have expected. So it is important when you are setting goals and a direction of travel for the teams that they are outcome-oriented.
- What change in behavior are we looking for in terms of the customer, end- user, or consumer?
- What business value metrics, customer value metrics, or end-user value metrics are we looking to move the needle on that would demonstrate that we know we made a difference, either better or worse?
Classes of Service in Kanban: what are they?
How do we actively manage items in the workflow/items in progress in Kanban?
