A System of Continuous Improvement
“If continuous improvement isn’t in-band then realistically it ain’t gonna happen.”
This post is about FlowChain (which btw, is the inspiration for my Twitter handle, @flowchainsensei). Not only does FlowChain afford a means for moving continuous improvement in-band, but also does away with the need for projects, and offers a means for dramatically improving product development flow.
These changes mean:
- Shortest possible concept-to-cash times.
- Steady, reliable flow of new features into the market.
- Earliest possible return on product/software development investment.
- Standardised, reliable numbers to manage by.
- No more project overheads.
- Simple coordination of work streams (no more PMO overheads).
- Improved business agility.
- Compatible with Agile development (team) methods.
- Your highly-utilised specialists are always working on the company’s most important (highest cost-of-delay) features.
A.K.A. Continual Improvement – for those who prefer that variant.
I wrote last year about continuous improvement as a vaccine. This was an attempt to raise the profile of the value of a systemic approach to making organisations work better and better (more and more effectively). In a related post I’ve explained how it’s fruitless to try to change people, but very fruitful to change the way the work works (“the system”) so as to effect changes in folks’ behaviours, without any coercion, obligation or other forms of violence (in that the folks doing the work are the same folks that choose and effect the changes to their collective way of working). And with transparency – both in terms of intent (to change behaviours) and so that everyone can see what is going on, every minute of every day.
In FlowChain we see these themes (and others, not covered here) woven together. Flowchain illustrates a system of work in which continuous improvement is integrated right there into the way the work works, on a daily basis. The following diagram illustrates the general FlowChain idea:
Here we see the enterprise-wide backlog. This contains all the work-items – a.k.a. deliverables – the enterprise is presently interested in producing. Through BAU, the Operational Value Stream Owners, engaged as they are, daily, in dealing with the constraints (cf. TOC) in their respective value streams, make requests for changes to their products, line-of-business applications, and so on. Let’s assume they choose to do this through a succession of “User Stories”. The enterprise backlog, then, allows the organisation as a whole to review and prioritise this workload – most likely according to some set of agreed policies. (We might choose to think of this as black-box backlog prioritisation).
The folks who choose to participate in the Pool (of e.g. “engineers” – in the most general sense), when not working on an existing item, are free to “pull” an item from at or near the head of the enterprise backlog and start working on it. These folks will get to know that:
- Their skills and experience – plus personal interests and enthusiasms – will suggest which items they might best pull.
- Some folks might like to work with the same folks on each successive item (standing teams).
- Some might choose to work with different folks from item to item (fluid, self-assembling teams).
- Some might choose to flit from one mode to another, item by item, as the fancy takes them.
Note: As a rule of thumb, each work item will be of a size requiring the efforts of around three to four people for one to three days. There may be benefits in making work items a consistent size, and even in balancing the flow through e.g. Heijunka
Aside: The nature of FlowChain is also informed by an old Familiar policy:
“Absolutely no work in the organisation is done off-plan.”
The yellow arrows in the above diagram illustrate the flow of i.e. product development work through the enterprise. As each e.g. user story is pulled from the backlog and worked-on by folks from the pool, ideas and innovations pertinent to improving the way the work works – most likely item-dependent – may be generated. These potential improvement ideas are captured in the form of e.g. “improvement stories”.
(Remembering that each “story” is a placeholder for a conversation.)
These improvement stories then also find their way into the enterprise backlog (the blue arrow shows this route). This allows the enterprise – through the backlog prioritisation algorithm (set of policies) – to balance and adjust the flow of user stories and improvement stories in real-time.
The backlog “management” may also include visualisation of the demand, work and flow – through e.g. an enterprise kanban board with kanban (cards) for the user stories and improvement stories both.
The Holy Grail – In-band Continuous Improvement
In this scheme of things, then, we integrate continuous improvement into the heart of the flow of BAU. This allows Flowchain-type organisations to square the circle and effectively serve the two masters of production and improvement with full transparency, non-violence, real-time flexibility and control.
Incidentally, this also allows FlowChain organisations to do away with the whole rotten edifice of projects, programmes, Programme Offices, internecine strife over resources, and so on.
My thanks again to all those folks that have made this post possible. I’d love to hear your thoughts.