A System of Continuous Improvement
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.
Continuous Improvement
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.
FlowChain Basics
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.”
Flow
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.
– Bob
Think Different 
Continuous improvement, what a simple but fantastic philosophy! The only thing it requires is having an open mind to criticism – but once one realizes the criticism is constructive versus critical, great improvements can be felt! Looking forward to more of your posts 🙂
Thanks for the post. I understand Flowchain much better now.
If no work is done off-plan, and improvements are captured as stories, does that imply that even small ideas for improvement have to go through the public backlog? Could that stifle serendipitous small efforts of improvement?
Hi Chris,
Thanks for joining the conversation.
My preference would be for every improvement idea to go through the backlog, with e.g. the scheduling (prioritisation) policies tuned (tailored) to streamlining small improvements. Others may choose a different approach. After all, one could argue that even the smallest of improvement ideas merit a PDCA/A3/experiment approach?
Alternatively, combining FlowChain with Prod•gnosis allows for major works to be done by specialists/engineers from the pool, with minor works (user stories/features and improvement stories both) to be actioned by the operational value stream folks themselves, right at the grass roots.
I’d suggest the choice comes down to context.
– Bob
Thanks for this Bob. This reminds me of some of the systems practice stuff I’ve learned through the Open University, but presented in a much prettier, relevant way! I really do need to read more of this kind of thing.
I’m sure you’ve heard of Stafford Beer and his Viable Systems Model (http://en.wikipedia.org/wiki/Viable_System_Model) – your diagram reminds me a bit of that. I struggled the most with this aspect of the OU course but did think that some of the concepts of VSM were very pertinent to healthy organisations.
Continuous improvement is /hard/ for many organisations, because they’re not geared up for changing the system, or are at the very least very slow at doing (double loop learning). Something like Flowchain could be very useful I think.
Cheers for making me think, and for reinvigorating my systemic practice.
Dave
Great post. We’re using JIRA, and we’ve set up one project(backlog) per project/system. I have pondered for some time where to put more cross-project issues and improvement suggestions.
Simply creating a project/backlog where we put any improvement suggestions as placeholders for discussing and executing these improvements makes perfect sense. We prioritize the backlog across all projects, so that means the improvements will pop up in the backlog alongside project related issues.
Thank you! 🙂
Anyone care to comment on the TOC 5 step continuous improvement process?
Pingback: How Can We Do This Better? « Quick Thoughts « Agile Mindstorm
How should a software consulting firm bill this type of approach? Time and materials?
My preference would be some form of output-based contract (assuming a desire on both “sides” for a long term relationship). See e.g. http://www.grantrule.org/wpress/wp-content/uploads/2014/07/2007-PGROutputBased.pdf
– Bob
I really love it whenever I get to develop in this flow based style. A prioritised list of tasks, grab the next one you’d like to do, do it — cheer — and start again. Some folks have told me that this is “Kanban”. I prefer to think of it as continuously winning. This flow style prevents problems with fixed iteration based development where iterations tend to be either unloaded (leading to a false sense of “winning”) or overloaded (leading to self-flagellation). Do we really need time boxes to have people work productively?
I’m curious what numbers/metrics you manage by (and how you avoid traps that Deming talks about with “management by numbers”).
You also mention BAU. I’ve found that this term is usually cryptic for “support”. I like the idea that there’s no distinction between development (aka green field) and support (aka maintenance). Is it your intention to remove this distinction?
Pingback: Meeting Folks’ Needs At Scale | HiveMindNetwork.com