I wrote recently that I have come to think about Flow, Value and Capability as the primary impacts I hope a Kanban System will have. Flow, Value and Capability are not independent entities, however, with Capability being the link between Flow and Value. We can think of Flow as “doing the thing right”, where good flow is the result of a good process. Similarly, we can think of Value as “doing the right thing”, where high value is the result of good outputs from the process. We want both, however, and we can think of Capability as “doing the right thing right”, where a good process delivers good outputs.
Here’s another way of looking at it…
A common scenario is creating projects, and assigning people to those projects to form a project team. This is great for the project in isolation, but when the project finishes the team is usually disbanded, and all the capability that was created as tacit knowledge in the team is lost.
A further challenge (amongst many) with this approach is that when another project comes along – and then another – people get assigned to multiple project teams, at which point they’re not really teams any more. This might seem efficient, but it is not effective, and is not good for the people or the work. In the diagram below, the person in the middle on three projects is not in a good place!
An alternative idea is to form teams around organisational capabilities – things which will enable the business to make an impact. Small pieces of valuable work which enhance this capability can then be individually pulled by these teams, creating flow. This is what I call a Capability Team.
Pursuing this approach, the notion of the project goes away, replaced by a Flow of Value through Capability teams who are able to “do the right thing right”. These teams can stay together for as long as the capability is important, building knowledge about all aspects of what they are building, and how they build it.
splitting ressources in overlapping teams is a big issue. Only few companies handle this efficiently
[…] Karl Scotland suggested to favor teams over projects in Kanban, too: Linking Flow, Value and Capability. […]
Karl,
that‘s interesting, thank you!
I have a slightly different view an flow. I find the Csikszentmihaly stuff useful which states that flow means “skills match challenges” or – transferred to our domain – “capabilities match demand”. In this view “doing things right” is not enough for creating flow, because it will generate more and more demand for value-added features, and that means it leads to less flow in the long run. So this would mean one should focus on flow and not on capabilities in the first place, because flow is what really maters in the end.
What are your thoughts on this?
Cheers,
Arne
Hi Arne,
I like the Csikszentmihaly view as well. And I hadn’t made the connection to capability and demand so thank you!
I’m not sure I agree when you say that just “doing things right” will lead to less flow. The opposite. Just “doing things right” leads to greater flow, but flow of what? Conversely, just “doing the right thing” will generate the increase in demand, which could reduce flow.
So I still think you need both, which is what I have called Capability. I can see how capability might just associated with flow, as in balancing capability against demand. I wonder what other word might describe the ability to achieve flow and deliver value?
Karl
Hi Karl,
Interesting post. The last option, a capability team, is really going back in time some 20 years, before we started to do projects.
There were teams, and when there was incoming work, the team just picked it up.
The result then was often a big lack of focus. Everybody working on all kinds of assignments all the time.
The idea of projects was then taken up to mitigate this problem.
And that idea worked, but created lost of other problems at the same time.
Are we in the position right now to prevent the problems from the old-style teams? I would hope that visibility techniques like Scrum/Kanban boards would bring us in that direction.
What are your ideas on that?
Hi Andre,
I think the difference between a capability team and what you described is the strong alignment between the team and a business capability that creates the focus and avoids “all kinds of assignments”. Designing a system around that capability, and avoiding any separation between “biz” and “dev”, helps maintain the focus on Flow and Value.
Karl