The Why of FlowChain: Deliberate Continuous Improvement

In my career, working with hundreds of companies, I’ve almost never seen organisations* take a truly deliberate approach to continuous improvement. It’s nearly always treated as an afterthought or add-on to business-as-usual (BAU). But real transformation requires making continuous improvement an integral and core part of daily work. This is the “why” behind FlowChain – enabling deliberate, in-band continuous improvement.

In other words, applying the same disciplines from product development, delivery, etc. to the business (sic) of delivering continuous improvements  – continuously improving the way the work works.

What Is FlowChain?

So what is FlowChain? At its core, it is a system for managing flow – both the flow of outputs and the flow of improvements to the way the work works, concurrently and by the same means. And by “flow”, I mean the steady progress of work from request to completion through all steps in a process. Flow is optimised when the right work is happening at the right time by the right people. Roadblocks, delays, and waste are minimised or eliminated.

Flow

Optimising flow delivers the following benefits:

• Increased productivity – less time wasted, more work completed
• Improved quality – fewer defects, rework minimised
• Better customer service – faster response times, reliability
• Higher employee engagement – less frustration, more joy

But achieving flow requires continuous improvement. Problems must be made visible. Waste must be reduced iteratively. Roadblocks must be cleared continuously.

This is why FlowChain incorporates improvement into its regular rhythm. Each cycle follows a deliberate sequence:

• Plan – Select and sequence the upcoming work.
• Execute – Complete the work while tackling issues.
• Review – Analyse completed work and identify improvements.
• Adjust – Make changes to improve flow.

Unlike most continuous improvement efforts – that are separate from BAU – FlowChain makes improvement an integral in-band activity. The rapid cycles provide frequent opportunities to reflect, gain insights, and act.

Compounding Benefits

Over time, the compounding benefits are immense. Teams develop a “flow habit”, where improving flow becomes second nature. Powerful capabilities like root cause analysis, A3 problem-solving, improvement katas, and change management are honed.

In my experience, this deliberate approach is transformative. Teams gain tremendous agency to systematically improve their own flow. The organisation as a whole cultivates a culture of continuous improvement. And customers experience ever-better service and responsiveness.

The “why” of FlowChain is simple – create focus, visibility, accountability, and agency to drive continuous improvement. The results – ever better flow, reduced waste, and sustainable transformation. Deliberate, in-band continuous improvement stops being an aspiration and becomes a reality.

*Ask me about the exception.

Teams for the Flow Era

Teams that are capable of smoothly and swiftly reconfiguring themselves is becoming the norm in the software industry today. Rather than old-fashioned rigid structures and siloed employees, progressive organisations opt for a more fluid approach that allows for responsiveness to shifting conditions.

Team members work across multiple projects in these flexible arrangements, contributing versatile skills as needed and rearranging team composition to suit the task in hand. Situational leadership – a.k.a. Fellowship – emerges based on expertise instead of formal titles. With boundaries that allow copious and timely information sharing between interlocking teams, rapid coordination becomes commonplace.

Self-direction and mutual trust enable these dynamic teams. A strong, shared strategic purpose coupled with developmental training and organisational support gives members the confidence to take initiative without constant top-down control. Teammates understand how their piece connects, empowering local decision-making even as larger configurations reshape around evolving challenges.

This fluid team format creates adaptable organisations capable of smooth reprioritisation as demands change, unencumbered by bureaucratic processes. People, ideas and resources flow to each new focus area in turn, adjusting teaming patterns seamlessly to current priorities. Progress keeps pace with the opportunities and demands of the day.

Some continuity and purposeful guidance balances out the flux. Respected, experienced figures may anchor successive teaming waves, providing continuity of culture and knowledge transfer. As thought leaderBob Marshall describes in his acclaimed book ‘The Team Fruit Bowl’, fluid teams’ steadiness enables ongoing realignment around the organisation’s North Star.

Self-aligning, versatile teams represent the leading edge of organisational design today. Staying responsive without getting swept away, they ride currents of change toward transformative performance.

Ditch the Project Mindset?

Yes. Many organisations have yet to even hear of #NoProjects, let alone embrace the idea. Many still cleave to the idea of projects, despite it being an outmoded anachronism.

Why Are Projects Failing Us?

You’ve allocated resources, set deadlines, and monitored key performance indicators. Yet something’s off. Projects aren’t delivering as promised. Let’s cut to the chase: the traditional project framework is unfit for the agility and productivity demands of modern organisations.

What’s Wrong with the Project Model?

The project model suggests a start and an end, often disregarding what happens both before and after. This closed-loop system stunts innovation and adaptability. It also usually operates in isolation from other projects, creating silos rather than fostering integrated growth. Essentially, projects set us up for a short-term win but often ignore the long-term game.

Do Agile Methods Help?

Agile approaches tried to rectify some of these issues, but they often get shoehorned into the project mindset. In essence, the Agile Manifesto preaches responsiveness over rigid planning. However, an agile project is still a project; a cage is still a cage, even if it’s golden. Agile methods within a project framework can only do so much (and that’s precious little).

What Replaces Projects?

So if we throw the baby out with the bathwater, what’s left? Systems thinking, that’s what. Instead of isolating issues and opportunities as projects, look at them as ongoing aspects of your organisation’s functioning. Focus on products, processes, value streams, and organisational health. Work towards adaptability, building capability, and continuous improvement rather than temporary, isolated gains.

How to Make the Shift?

It’s a significant cultural shift and it won’t happen overnight. Employees need to understand the broader business landscape, not just their tiny slice of the pie. Training, communication and the buy-in of the Folks That Matter™ are key. It’s not about ticking boxes; it’s about ongoing, holistic improvement. Forget “project completion”; think “system capability.”

Are There Any Downsides?

Every coin has two sides. You’re moving from a structured, time-bound approach to something more fluid. That can be unsettling and might even meet resistance. However, the potential for increased productivity and agility far outweighs the initial discomfort.

Is It Time to Say Goodbye To Projects?

Short answer: Yes. Ditch the traditional project framework. Embrace a more fluid, systems-oriented approach and make room for real agility and productivity. It’s not just a change, it’s an evolution. Are you ready?

A Question of Flow

A New Take on Flow?

When we hear about flow, it’s often linked to a psychological state of focus and immersion. But flow isn’t just a psychological state popularised by Mihaly Csikszentmihalyi. There’s another kind of flow that plays a critical role in organisations. This type of flow refers to a well-coordinated series of actions, events, or processes that work in harmony – flow as a smooth succession of actions that take place within an organisational setting

Why Should You Bother?

Paying attention to flow in your organisation is not just an academic exercise; it’s a practical necessity. Improved flow means fewer bottlenecks, quicker turnarounds, and more satisfied employees. Given these benefits, can you afford to overlook the importance of achieving good flow?

Is Structure the Solution?

While structure might seem constraining, it offers a foundation upon which flow can thrive. Roles and responsibilities are clearer, and tasks follow a more predictable pattern. However, there’s a limit to the benefits of structure. Could too much structure curtail creativity and inhibit the capacity for innovative solutions? How much structure is “just enough”?

How Tech Can Contribute

Modern technology provides tools that make it easier to achieve flow. Automated systems can handle repetitive tasks, freeing humans to focus on complex challenges. Additionally, real-time data analytics can identify potential bottlenecks before they become major issues. But what’s the cost of getting your tech choices wrong?

Humans in the Equation

A finely tuned system isn’t just about technology or well-drafted processes. The human element—morale, motivation, and collaboration—also plays a pivotal role. When employees work well together, the flow is more natural and less forced. How can we foster a culture that encourages this kind of harmony?

What Metrics to Use

Choosing metrics for gauging flow involves more than just picking numbers to track. Do task completion times, takt times, employee engagement levels, or customer satisfaction rates resonate with your organisational goals? How do you know if you’re focusing on the right measures to sustain or enhance flow?

Ready to Make a Change?

Embarking on the journey to improve organisational flow is a complex but rewarding endeavour. It involves continuous assessment, involving multiple stakeholders, and making frequent adjustments. Are you willing to commit the necessary time and resources to achieve a state of optimal flow?

Flow, in this organisational sense, is a multifaceted concept. By asking the right questions and taking a balanced approach, you can create an environment where flow becomes a natural aspect of your operational landscape. So, are you prepared to rethink what flow means for you and your organisation?

A Question of Flow: Extending into the Software Realm

Does Software Development Redefine Flow?

In the complex landscape of software development, flow takes on nuanced dimensions. Beyond well-coordinated actions and processes, here it’s about managing interdependent systems, handling data, and synchronising multiple contributors. How does the concept of flow evolve when applied to software?

What Are the Stakes for Software Projects?

The relevance of flow extends far beyond general organisational theory when we delve into software projects. It’s not just about speed but also about code quality, user experience, and sustainable development. How does focusing on flow lead to more resilient and robust software systems?

How Does Architecture Influence Flow?

In software development, the architecture itself can facilitate or hinder flow. Modular designs and well-defined APIs can dramatically streamline the work process. How could architecture be leveraged to enhance flow, without compromising quality?

Are DevOps and CI/CD Flow Enablers?

DevOps culture and Continuous Integration/Continuous Deployment (CI/CD) pipelines are revolutionising the flow in software development. They merge development and operations, automating much of the workflow. Is the automation brought by these practices always beneficial, or could there be drawbacks?

Can Open Source Cultures Teach Us About Flow?

The open-source community often exhibits a unique kind of flow, built on collective intelligence and decentralized collaboration. Can traditional organisations learn from this paradigm?

What About Flow in Remote Teams?

The rise of remote work presents new challenges and opportunities for achieving flow in software development. How do time zones, cultural differences, and virtual communication affect flow? Can they be harnessed to enhance it instead?

Is Ethical Software Development Compatible with Flow?

Rapid development cycles and the pursuit of flow might conflict with the need for ethical considerations in software design, such as accessibility and data privacy. Can a balance be achieved where ethical imperatives don’t disrupt the flow?

Are We Ready for the Future of Software Development Flow?

As technologies like AI and quantum computing mature, they’ll inevitably impact the flow of software development. Will we adapt our notions of flow to these advancements, or will the concept of flow itself undergo a transformation?

By integrating these big-picture considerations, we can explore new frontiers of flow in both traditional organisations and software development landscapes. The question remains: Are we ready to adapt and evolve?

Beyond the Agile Trap

Failure Writ Large

Have you ever questioned why Agile so often falls short of delivering on its impish promises? You’re not alone. Many find their Hail Mary agile initiatives underdelivering, leaving everyone perplexed, frustrated and embarrassed. The answer isn’t hidden within Agile, but it’s found in the overlooked, holistic mindset called “systems thinking”.

Cuckoos

Like a cuckoo, Agile’s brood parasite nature has strong-armed it a significant place in the field of software development, with its proponents’ knavish boasting of flexibility, adaptability, and rapid value delivery. However, despite its siren qualities, Agile frequently disappoints. But why?

The answer isn’t nestled in the details of Agile approaches, but rather within an organisation’s broader perspective.

Agile almost inevitably promotes mere local optimisations – approaches with immediate and tangible improvements that miss the context for organisation-wide benefits such as flow.

Systems Thinking

This is where systems thinking approaches like the Theory of Constraints (ToC) comes into play. This perspective urges us to look beyond individual silos and examine the system as a whole, identifying bottlenecks and developing comprehensive flow-oriented solutions. The move from local to system-wide optimisation isn’t a minor tweak; it’s a sea change. It requires a transition from concentrating on isolated elements to understanding the wider interdependencies of the entire system.

Rarely Seen

Regrettably, true systems thinking is rarely seen in organisations. It’s challenging to grasp, tough to implement, antithetical to the near-ubiquitous silo style of organisation, and calls for an open mind to coordinate – or better yet, merge – multiple silos.

However, it’s a crucial journey, a leap of faith necessary to build a robust, resilient, and more effective organisation.

Summary

When we ask, “why does Agile fail so often?”, the response isn’t found within Agile’s principles or practices. Instead, it lies in the broader organisational mindset that often overlooks the system-wide view. Moving from Agile’s local optimisation to the more comprehensive approach of system-wide optimisation isn’t a simple journey. Still, it’s a journey towards enlightenment. Let’s not settle for improving just the software development silo. Let’s strive to create a balanced, stable, and impressive flow chain. The essence of this conversation is about challenging our views, moving beyond our current practices, and welcoming the rewarding shift towards systems thinking. Here’s to building a future that doesn’t merely copy blindly, but optimises and truly excels.

I’m Done

Memeology, Quintessence

I’m done with inviting folks to discover better ways to run collaborative knowledge work businesses and other organisations. 

The Antimatter Principle

I’m done with inviting people to build more humane, engaging organisations.

Rightshifting

I’m done with illustrating the gulf in performance and effectiveness between the average organisation or business, and the best. And how much productivity just goes begging.

The Marshall Model

I’m done with inviting people to understand the role of collective assumptions and beliefs in the effectiveness of their organisations.

Effectiveness

I’m done with even mentioning effectiveness. No one seems to need it or want it or even to understand what it is and its role in organisational success.

Emotioneering

I’m done with inviting organisations to consider the way people actually go about buying goods and service, and the role of emotions therein.

FlowChain, Prod•gnosis, Flow•gnosis

I’m done with providing food for thought on how the work in collaborative knowledge work organisations can work awesomely better.

Product Aikido

I’m done with inviting folks to look more deeply into the principles of product development and what makes for more effective product development.

The Giants

I’m done with mentioning the Giants such as Ackoff, Deming, Drucker, et al.

Software

I’m done with software and helping people improve software development, reliability, quality, predictability, etc.. #NoSoftware’s the thing.

Recruiters and the Job Market

I’m done with know-nothing recruiters only focused on their next commission. And a totally broken job market focussed on mediocrity and the status quo. Oh, and CVs too. #NoCV.

The Closed-Minded

I’m done with people that are happiest sitting on their arses (metaphorically speaking) and keeping their eyes, ears, and minds closed to possibilities. Which is everybody, AFAICT.

The Unreliable

I’m done with people that promise to do things, and then, silently, do fuck all.

Agile

I’m done with Agile. Actually, as you’re probably aware, I’ve been done with Agile for a decade and more. I’m just adding it here for the sake of completeness. Oh, and I’m SO done with ignorant people who continue to promote the Agile busted flush.

I’m Done With Better Ways

I’m done with it all. Given there’s zero demand for “better”, better ways seem entirely irrelevant.

And good luck with that status quo. 

– Bob

Quintessential Product Development

In my most recent book “Quintessence” I map out the details of what makes for highly effective software development organisations.

As fas as software development organisations are concerned, it’s a bit of a moot point – as software is generally something to be avoided, rather than sought (see also: #NoSoftware).

“The way you get programmer productivity is by eliminating lines of code you have to write. The line of code that’s the fastest to write, that never breaks, that doesn’t need maintenance, is the line you never had to write.”

~ Steve Jobs 

Foundational Concepts

There are just a few complementary concepts that mark out the quintessential product development company. These are:

• Whole Product.
• Systematic Product Management.
• Whole Organisation (systems thinking).

Whole Product

The quintessential product development organisation embraces the concept of “whole product”. Which is to say, these organisations emphasise the need to have every element of a product i.e. core product elements plus a range of “intangibles” – everything that is needed for the customer to have a compelling reason to buy (Mckenna 1986).

Systematic Product Management

Quintessential product development organisations take a systematic approach to flowing new product ideas and features through a number of stages – often in parallel (Ward 1999) – to predictably arrive at a successful new product in the market:

• Inception – spotting a gap in the market, a.k.a. some (potential customer) needs going unmet, interesting enough to do some discovery.
• Discovery – uncovering and proving the real needs of customers, the things they value, the likely usability of possible solutions, the feasibility of meeting everyone’s needs, and the viability of a product as a means to these ends. In essence, the key risks facing the proposed product. 
• Implementation – building a whole product solution, i.e. both core elements and “intangibles”.
• Launch – Placing the product on sale (or otherwise making it available to customers).
• Feedback – Seeing how the market responds.
• Pivot or Augmentation – Acting on feedback to either reposition the solution (in response to unfavourable feedback) or to incrementally update / extend the “whole product” offering to continually strengthen the product’s value proposition and appeal.
• Cash Cow – Reap the commercial rewards of a strong product and market share.
• Sunsetting – Wind down the product in a way that meets the ongoing needs of all the Folks That Matter™️ (e.g. continued support, spare parts, etc.; easing customers’ transition to newer products; etc.). 

Whole Organisation

It’s common for organisations to think in terms of silos. A Product Management or Product Development silo being but one more silo in a long and ever-lengthening list. 

In the quintessential organisation, the whole organisation is geared around – amongst other things – the task of regularly and predictably getting new products and new product features/updates out the door and into the hands of customers. In the longer term, new products are the life blood of most organisations, especially in the technology industries.

We only have to look e.g. Toyota and their TPDS (Toyota Product Development System) to see both an example of how this works in practice, and the huge benefits of the whole-organisation approach.

Quintessential product development organisations embrace a range of progressive ideas such as Prod•gnosis and Flow•gnosis.

– Bob

Further Reading

Marshall, R.W. (2013). Product Aikido. [online] Think Different Available at: https://flowchainsensei.wordpress.com/wp-content/uploads/2013/04/productaikido041016.pdf [Accessed 13 Jan. 2022].

Mckenna, R. (1986). The Regis Touch: New Marketing Strategies for Uncertain Times. Reading, Mass.: Addison-Wesley Pub. Co.

Perri, M. (2019). Escaping The Build Trap: How Effective Product Management Creates Real Value. O’Reilly.

Ward, A.C. (1999). Toyota’s Principles of Set-Based Concurrent Engineering. [online] MIT Sloan Management Review. Available at: https://sloanreview.mit.edu/article/toyotas-principles-of-setbased-concurrent-engineering/. [Accessed 13 Jan. 2022].

Incompatible

Ever wondered why so many “Agile Adoptions” end up in the crapper?

Here’s the thing: Agile development, as described in the Agile Manifesto, and as aspired to by the gullible, is fundamentally and irredeemably incompatible with traditional management approaches (commonly known as command and control, Taylorism, Scientific Management, or some such).

This is neither a matter of opinion nor of experience (although I have many such experiences to relate), but of logic. I’ll not make the logical connections here, although I’m happy to do so if anyone is interested. I predict no one will be so interested.

This fundamental incompatibility is the reason we see so many failed Agile adoptions. Management is almost never going to swap out its existing mental models of how an organisation must be run, and so almost never will we see effective software development. (And almost no one seems in the slightest bit bothered).

BTW This incompatibility accounts for the approximately 80% failure rate of Agile adoptions we now know of.

The Gullible

The real kicker, though, is how Agile, as a local optimisation of the first order, will never deliver the benefits its proponents claim. Even those instances that have some impact on the traditional management worldview will only ever serve to enhance, and only marginally, the effectiveness of the development silo. And have little to no effect on the wider organisation. So much effort and risk of failure for so little gain.

The Alternative

I’m often asked “What’s the alternative, then, Bob?”. In a kind of despairing tone, as if it’s impossible to imagine a viable alternative at all.

I suggest at least one alternative is to look at the organisation as a (whole) system. And apply the precepts of flow to bring that system towards the Quintessential. If you need help with that, I’d be delighted to assist.

– Bob

ICYMI: The Future of Work

“The most important, and indeed the truly unique, contribution of management in the 20th century was the fifty-fold increase in the productivity of the MANUAL WORKER in manufacturing. The most important contribution management needs to make in the 21st century is similarly to increase the productivity of KNOWLEDGE WORK and the KNOWLEDGE WORKER.”

~ Peter F. Drucker

And in case you missed the original post:

The Future of Work

ICYMI: Product Development Flow

In case you missed it:

Product Development Flow

 

First Principles

I was reading the other day about how Elon Musk “reasons from first principles“. And I was thinking, “Well, d’oh! Doesn’t everyone do that? I know I do.” And then, upon reflection, I thought, “Hmm, maybe most folks don’t do that.” I certainly have seen little evidence of it, compare to the evidence of folks reasoning by extension, and analogy. And failing to reason at all.

Now, allowing for journalistic hyperbole and the cult of the celebrity, there may just still be something in it.

So, in case you were wondering, and to remind myself, here’s some first principles underpinning the various things in my own portfolio of ideas and experiences:

The Antimatter Principle

The Antimatter Principle emerges from the following basic principles about us as people:

• All our actions and behaviours are simply consequent on trying to get our needs met.
• We are social animals and are driven to see other folks’ needs met, often even before our own.
• We humans have an innate sense of fairness which influences our every decision and action.

Flowchain

Flowchain emerges from the following basic principles concerning work and business:

• All commercial organisations – excepting, maybe, those busy milking their cash cows – are in the business of continually bringing new products, or at least new product features and upgrades, to market.
• When Cost of Delay is non-trivial, the speed of bringing new products and feature to market is significant.
• Flow (of value – not the Mihaly Csikszentmihaly kind of flow, here) offers the most likely means to minimise concept-to-cash time.
• Autonomy, mastery and shared purpose affords a means for people to find the intrinsic motivation to improve things (like flow).
• Building improvement into the way the work works increases the likelihood of having sufficient resources available to see improvement happen.

Prod•gnosis

Prod•gnosis emerges from the following basic principles concerning business operations:

• All commercial organisations – excepting, maybe, those busy milking their cash cows – are in the business of continually bringing new products, or at least new product features and upgrades, to market.
• Most new products are cobbled together via disjointed efforts crossing multiple organisational (silo) boundaries, and consequently incurring avoidable waste, rework, confusion and delays.
• The people with domain expertise in a particular product or service area are rarely, if ever, experts in building the operational value streams necessary to develop, sell and support those products and services.  

Emotioneering

Emotioneering emerges from the following basic principles concerning products and product development:

• People buy things based on how they feel (their emotional responses to the things they’re considering buying). See: Buy•ology by Martin Lindstrøm.
• Product uptake (revenues, margins, etc.) can be improved by deliberately designing and building products for maximum positive emotional responses.
• Quantification serves to explicitly identify and clarify the emotional responses we wish to see our products and service evoke (Cf. “Competitive Engineeering” ~ Gilb).

Rightshifting

Rightshifting emerges from the following basic principles concerning work in organisations:

• The effectiveness of an organisation is a direct function of its collective assumptions and beliefs.
• Effectiveness is a general attribute, spanning all aspects of an organisation’s operations (i.e. not just applicable to product development).

The Marshall Model

The Marshall Model emerges from the following basic principles concerning work in organisations:

• Different organisations demonstrable hold widely differing shared assumptions and beliefs about the world of work and how work should work – one organisation from another.
• Understanding which collection of shared assumptions and beliefs is in play in a given organisation helps interventionists select the most effective form(s) of intervention. (Cf. The Dreyfus Model of Skills Acquisition).

Organisational Psychotherapy

Organisation psychotherapy emerges from the following basic principles concerning people and organisations:

• The effectiveness (performance, productivity, revenues, profitability, success, etc.) of any organisation is a direct function of its collective assumptions and beliefs about the world of work and how work should work.
• Organisations fall short of the ideal in being (un)able to shift their collective assumptions and beliefs to better align with their objectives (both explicit and implicit).
• Having support available – either by engaging organisational therapists, or via facilitated self-help – increases the likelihood of an organisation engaging in the surfacing, reflecting upon, and ultimately changing its collective assumptions and beliefs.

– Bob

Solutions Demand Problems

I’m obliged to Ben Simo (@QualityFrog) for a couple of recent tweets that prompted me to write this post:

I very much concur that solutions disconnected from problems have little value or utility. It’s probably overdue to remind myself of the business problems which spurred me to create the various solutions I regularly blog about.

FlowChain

Problem

Continually managing projects (portfolios of projects, really) is a pain in the ass and a costly overhead (it doesn’t contribute to the work getting done, it causes continual scheduling and bottlenecking issues around key specialists, detracts from autonomy and shared purpose, and – from a flow-of-value-to-the-customer perspective – chops up the flow into mini-silos (not good for smooth flow). Typically, projects also leave little or no time, or infrastructure, for continually improving the way the work works. And the project approach is a bit like a lead overcoat, constraining management’s options, and making it difficult to make nimble re-adjustments to priorities on-the-fly.

Solution (in a Nutshell)

FlowChain proposes a single organisational backlog, to order all proposed new features and products, along with all proposed improvement actions (improvement to the way the work works). Guided by policies set by e.g. management, people in the pool of development specialists coalesce – in small groups, and in chunks of time of just a few days – around each suitable highest-priority work item to see it through to “done”.

Prod•gnosis

Problem

Speed to market for new products is held back and undermined by the conventional piecemeal, cross-silo approach to new product development. With multiple hands-offs, inter-silo queues, rework loops, and resource contentions, the conventional approach creates excessive delays (cf cost of delay), drives up the cost-of-quality (due to the propensity for errors), and the need for continual management  interventions (constant firefighting).

Solution (in a Nutshell)

Prod•gnosisproposes a holistic approach to New Product Development, seeing each product line or product family as an operational value stream (OVS), and the ongoing challenge as being the bringing of new operational value streams into existence. The Prod•gnosis approach stipulates an OVS-creating centre of excellence: a group of people with all the skills necessary to quickly and reliably creating new OVSs. Each new OVS, once created, is handed over to a dedicated OVS manager and team to run it under day-to-day BAU (Business as Usual).

Flow•gnosis

Problem

FlowChain was originally conceived as a solution for Analytic-minded organisations. In other words, an organisation with conventional functional silos, management, hierarchy, etc. In Synergistic-minded organisations, some adjustments can make FlowChain much more effective and better suited to that different kind of organisation.

Solution (in a Nutshell)

Flow•gnosis merges Prod•gnosis and FlowChain together, giving an organisation-wide, holistic solution which improves organisational effectiveness, reifies Continuous Improvement, speeds flowof new products into the market, provides an operational (value stream based) model for the whole business, and allows specialists from many functions to work together with a minimum of hand-offs, delays, mistakes and other wastes.

Rightshifting

Problem

Few organisations have a conscious idea of how relatively effective they are, and of the scope for them to become much more effective (and thus profitable, successful, etc.). Absent this awareness, there’s precious little incentive to lift one’s head up from the daily grind to imagine what could be.

Solution (in a Nutshell)

Rightshifting provides organisations with a context within which to consider their relative effectiveness, both with respect to other similar organisations, and more significantly, with respect to the organisation’s potential future self.

The Marshall Model

Problem

Few organisations have an explicit model for organisational effectiveness. Absence of such a model makes it difficult to have conversations around what actions the organisation needs to take to become more effective. And for change agents such as Consultants and Enterprise Coaches attempting to assist an organisation towards increased effectiveness, it can be difficult to choose the most effective kinds of interventions (these being contingent upon where the organisation is “at”, with regard to its set of collective assumptions and beliefs a.k.a. mindset).

Solution (in a Nutshell)

The Marshall Model provides an explanation of organisational effectiveness. The model provides a starting point for folks inside an organisation to begin discussing their own perspectives on what effectiveness means, what makes their own particular organisation effective, and what actions might be necessary to make the organisation more effective. Simultaneously, the Marshall Model (a.k.a. Dreyfus for Organisations) provides a framework for change agents to help select the kinds of interventions most likely to be successful.

Organisational Psychotherapy

Problem

Some organisations embrace the idea that the collective organisational mindset – what people, collectively believe about how organisations should work – is the prime determinant of organisational effectiveness, productivity, quality of life at work, profitability, and success. If so, how to “shift” the organisation’s mindset, its collective beliefs, assumptions and tropes, to a more healthy and effective place? Most organisations do not naturally have this skill set or capability. And it can take much time, and many costly missteps along the way, to acquire such a capability.

Solution (in a Nutshell)

Organisational Psychotherapy provides a means to accelerate the acquisition of the necessary skills and capabilities for an organisation to become competent in continually revising its collective set of assumptions and beliefs. Organisational Psychotherapists provide guidance and support to organisations in all stages of this journey.

Emotioneering

Problem

Research (cf Buy•ology ~ Martin Lindstrom) has shown conclusively that people buy things not on rational lines, but on emotional lines. Rationality, if it has a look-in at all, is reserved for post-hoc justification of buying decisions. However, most product development today is driven by rationality:

• What are the customers’ pain points?
• What are the user stories or customer journeys we need to address?
• What features should we provide to ameliorate those pain points and meet those user needs?

Upshot: mediocre products which fail to appeal to the buyers’ emotions, excepting by accident. And thus less customer appeal, and so lower margins, lower demand, lower market share, and slower growth.

Solution (in a Nutshell)

Emotioneering proposes replacing the conventional requirements engineering process (whether that be big-design-up-front or incremental/iterative design) – focusing as it does on product features – with an *engineering* process focusing on ensuring our products creaate the emotional responses we wish to evoke in our customers and markets (and more broadly, in all the Folks That Matter™).

The Antimatter Principle

Problem

How to create an environment where the relationships between people can thrive and flourish? An environment where engagement and morale is consistently through the roof? Where joy, passion and discretionary effort are palpable, ever-present and to-the-max?

Solution (in a Nutshell)

The Antimatter Principle proposes that putting the principle of “attending to folks’ needs” at front and centre of all of the organisation’s policies is by far the best way to create an environment where the relationships between people can thrive and flourish. Note: this includes policies governing the engineering disciplines of the organisation, i.e. attending to customers’ needs at least as much as to the needs of all the other Folks That Matter™.

– Bob

Holistic Solutions for Product Development Businesses

Several people have been in contact this week to say “It’s all very well talking about holistic solutions for software development, but who really has any notion of what that might even look like?”

Which is a fair question.

Aside: Let’s note that the phrase “holistic solution for software development” is an oxymoron of the first order. By definition, software development is but part (and generally a small part) of any solution that addresses customer or market needs. Even software “pure plays” have a lot of non-software components.

So, I thought I’d describe just one holistic solution for whole organisations that develop new products containing some software. For want of a better name, I’ll call it this example “Flow•gnosis”. With this example, I hope that maybe one or two readers might find a spark of insight or inspiration to broach the question of a True Consensus in their own organisation.

I’ll try to keep this post brief. I’d be happy to come talk with you about holistic product development solutions for organisations, in person, if you have any real interest.

Flow•gnosis?

Flow•gnosis is a hybrid born of FlowChain and Prod•gnosis. FlowChain is not specifically a holistic solution, focussing as it does on improving the flow of knowledge work through a development group or department whilst moving continuous improvement “in-band”. Prod•gnosis is specifically a holistic solution for effective, organisation-wide product development, but says little about how to organise the work for e.g. improved flow or continuous improvement.

Together, they serve as an exemplar of a holistic solution for knowledge-work organisations, such as software product companies, software houses, tech product companies, and organisations of every stripe with in-house product development needs.

Let’s also note that Flow•gnosis is just an example, to illuminate just a few aspects of a holistic solution. Do not under any circumstances consider copying it or cloning it. Aside from the lack of detail presented here, you’d be missing the whole point of the challenge: building a True Consensus, as a group, with your people, in your context.

What’s the Problem?

Before talking more about a solution, what’s the problem we’re trying to solve?

I’ll work through an almost universal problem facing organisations that “do” software development. A problem that some enterprising supplier or management team might choose to address with an “innovative” solution.

Understanding the Problem

Here are some typical Undesirable Effects (UDEs) I hear from many companies involved in software and product development:

UDE: Delivery is not fast enough (long time-to-market)

UDE: New products cost too much to develop (high cost to bring to market)

UDE: We struggle to keep our products at the cutting edge

UDE: We always drop balls in hand-offs of tasks (i.e. between specialists, or business functions)

UDE: Continual contention for in-demand specialists

(For the sake of brevity, I’ll skip the building and analysis of the cause and effect graph. Your analysis will be different, in any case).

Root cause: Developing new software, products and services through a byzantine labyrinth of tasks and hand-offs, between and across dozens of specialisms within the company and its network of suppliers and distributors. This approach causes many delays (waste of time), mistakes (waste of effort, money), contention of resources, etc.

Conflict: A) Specialists must work together in their own specialist groups or silos to maintain their cutting-edge skills and know-how. B) Specialists from across all specialisms must work together as a group else handoffs and queues will cause many delays and mistakes.

Conflict arrow: Specialists cannot work in their own groups advancing their specialist knowledge at the same time as they work together with other kinds of specialist on new product ideas.

Flawed assumption at the root of the conflict: Specialists must work together. What makes this so? Only the old rules of the organisation. That silos (a.k.a. business functions) “own” their clutch of specialists. What if we changed that rule? (Note: this change is one key element of Toyota’s TPDS). And if we changed that rule, what other rules would we need to change too?

A Bird’s Eye View of Flow•gnosis

Prod•gnosis looks at an organisation as a collection of parallel Operational Value Streams, each dedicated to the selling and support of one of the organisations’ (whole) product or service lines. And each with its own team or collection of people doing the daily work of that operational value stream. Further, Prod•gnosis asks “How do these operational value streams come into being?” And answers with “They are made/created/developed by a dedicated Product Development Value Stream.”

FlowChain describes a way of working where a pool of self-organising specialists draws priority work from a backlog, executes the work, and delivers both the requested work item, and posting new work items (for improving the ways the work works) into the backlog. In this way, FlowChain both improves flow of work through the system, and brings continuous improvement “in-band”

By merging Prod•gnosis and FlowChain together into Flow•gnosis, we have an organisation-wide, holistic example which improves organisational effectiveness, reifies Continuous Improvement, speeds flow of new products into the market, provides an operational (value stream based) model for the whole business, and allows specialists from many functions to work together with a minimum of hand-offs, delays, mistakes and other wastes.

The latter point is perhaps the most significant aspect of Flow•gnosis. Having customer, supplier, marketing, sales, finance, logistics, service, billing, support and technical (e.g. software, usability, emotioneering, techops, etc.) specialists all working together (cf. Toyota’s Obeya or “Big Room” concept) enables the evolution of “Mafia Products” and “Mafia Offers” which the more traditional silo-based models of business organisation just can’t address effectively.

Out With the Old Rules, In with the New

Flow•gnosis is an innovation. Irrespective of the promised benefits of Flow•gnosis, we have learnt in recent posts that adopting an innovation ONLY brings benefits when we change the rules.

Let’s apply the four questions to our Flow•gnosis innovation and see what rule changes will be necessary to truly reap the benefits.

Q1: What is the POWER of Flow•gnosis?
A1: Flow•gnosis makes it commercially feasible for a company to repeatably come to market with new “Mafia Products”.

Mafia Product: “A product (or service) so compelling that your customers can’t refuse it and your competition can’t or won’t offer the same.”

Q2: What limitation does Flow•gnosis diminish?
A2:  Serialisation of specialist work (passing things back and forth between various specialist and business functions).

Q3: What existing rules served to help us accommodate that limitation?
A3: Handoffs. Queues. Batches. Separation of command and control from the work. Process. Process conformance. Local measures. Constant expediting. Critical path planning (Gannt charts, WBS). Local optima. Functional management (discrete management of each separate business function).

Q4: What (new) rules must we use now?
A4: Flow. Value streams. SBCE. Holistic measures. Ubiquitous information radiators. Cost Of Delay prioritisation. Buffer management. Constant collaboration. Dedicated teams of generalising specialists. Self-organisation. In-band continuous improvement. Resource levelling. Limits on WIP.

Summary

This post has been a – necessarily brief – look at one holistic solution to (software) product development. Crucially, we have seen how old rules have to be replaced, and what many of the replacement new rules might look like.

I invite you to remember that Flow•gnosis is just an broad-brush example of a holistic solution. Please don’t consider copying it or cloning it. And remember the real challenge: building, as a management group, a True Consensus.

– Bob

Further Reading

Meeting Folks’ Needs At Scale – Think Different blog post

The Simplest Thing That Could Possibly Work

Here’s an excerpt (pp 206) from “Birth Of the Chaordic Age” by Dee Hock, about “an odd project management scheme” they adopted in the early days – circa 1974:

“Swiftly, self-organisation emerged. An entire wall became a pinboard with every remaining day calendared across the top. Someone grabbed an unwashed coffee cup and suspended it on a long piece of string pinned to the current date. Every element of work to be done was listed on scraps of paper with the required completion date and the name of the person who had accepted the work. Anyone could revise the elements, adding tasks or revising dates, providing they coordinated with others affected. Everyone, at any time, could see the picture emerge and evolve. They could see how the whole depended on their work, and how their work was connected to every other part of the effort. Groups constantly assembled in front of the board as need and inclination arose, discussing and deciding in continuous flow; then dissolving as needs were met. As each task was completed its scrap of paper would be removed. Each day, the cup and string moved inexorably ahead.”

I’m struck by the similarities with FlowChain, and as with FlowChain, it seems an exemplar of simplicity and flow. I also note the implicit “Advice Process” vibe, and the emphasis on “making the work visible” (Cf Personal Kanban).

– Bob

Further Reading

Birth of the Chaordic Age ~ Dee Hock

Meeting Folks’ Needs At Scale

Scaling Agile is one of those oxymorons that has, nevertheless, consumed endless column-inches and hours of debate. I have no time for it. Agile was meant for development-in-the-small. For teams of five to seven people, give or take. Even at that “scale”, I have serious reservations about its efficacy and effectiveness. The idea of scaling it up to multiple dependent teams, or even to whole development departments or groups of hundreds or thousands of people, seems just crazy.

The Demand

Yes. There are organisations with hundreds or thousands of developers working on more or less dependent things. Huge systems. Ginormous products. And these organisations have problems. Boy, do they have problems. They’ve had the same kind of problems for decades now. Advances in tech and tools seems to have made little dent in those problems. Similarly, advances in methods and processes have barely scratched the surface.

So there is a demand. A demand for something better. A demand for a packaged solution that can be simply (ha!) “installed” and run with. And the folks with the problems have money. Lots of money. Bags of moolah.

No wonder it looks like an interesting problem to solve. The thing is, I don’t see many people, either on the demand or the supply side, that actually understand the nature of the problem.

Absent an understanding of the problem, and given their desperation, the demand side will embrace any and all solutions that bear even a vague whiff of credibility. And the “Agile” label these days confers that smell.

Needs

All product development is, in essence, an exercise in attending to folks’ needs. The more kinds of folks with needs, the more of their needs we bring into scope, and the quicker we want to see those needs met, the more people we might choose to commit. The question of agile (or not) is a huge irrelevance. Things like communications overheads, coordination, partitioning of needs, a regular cadence, flow, and effective use of resources (time, money, equipment) hold sway. TPDS had these issues sorted out (mostly) years ago with e.g. the Obeya or “big room” concept, set-based concurrent engineering, etc.

I have suggested that something like FlowChain might afford an effective model for organising to meet folks’ needs at scale. I have yet to hear anyone suggest why this model is flawed. Until that day, I will continue to invite you to consider its merits.

The demand side continues to have needs that are not being well-met (due to e.g. a host of pathological beliefs). The supply side has needs that are being more-or-less well met by selling solutions largely disconnected from the real problem. Scaling agile seems to me a very one-sided, cynical and exploitative bargain.

– Bob

Further Reading

Moving Past the Scaling Myth ~ Michael Feathers
Lean Product and Process Development ~ Allen Ward

Emergence

You may have noticed that I write regularly about the different mindsets that explain the relative effectiveness of the organisations we work for and with. Things like Theory-X (strong in the Ad-hoc and Analytic mindsets) vs Theory-Y (Synergistic and Chaordic mindsets), and organisations-as-machines vs organisations as social/biological/complex adaptive systems.

One difference I have not touched on much is the part that emergence has to play in the effective organisation.

Gall’s Law

“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.”

~ John Gall

Does Your Organisation Embrace or Ignore Gall’s Law?

Ad-hoc and Analytic minded organisations generally believe that systems are best designed, up front, with acts of conscious will and intent. Be they organisational structure, policies, products or a myriad of other systems upon which an organisation depends.

Synergistic organisations learn, by degrees, that John Gall nailed it – complex systems that work require evolution from simple systems that work. For effective (working) organisations, we need to embrace emergence. We need to allow our systems – and our thinking – to evolve to the point where emergence is working for us. This is hard.

Messy

Emergence seems messy. Allowing things to take their own course is hard for folks who seek certainty and control as means to getting their needs met. It can often feel like a crowd of people trampling over your nice, neat, manicured lawns. But the properties of beauty and simplicity can emerge more or less unbidden, too.

Whilst we opposed emergence, we lock ourselves into relatively ineffective ways of thinking, and thus, of working.  Only when we embrace and encourage emergence, do we open the door to more effective ways of thinking and working.

FlowChain

One of the fundamental guiding principles of FlowChain is to encourage emergence:

• Emergence of products
• Emergence of teams
• Emergence of methods (“the way the work works”)
• Emergence of systems
• Emergence of priorities
• Emergence of flow
• Emergence of needs (and e.g. stakeholders)
• Emergence of purpose (the “why”)
• Emergence of ideas (i.e. creativity)

Would you be willing to consider, and share, where your organisation is at regarding the role of emergence?

“My ideas have undergone a process of emergence by emergency. When they are needed badly enough, they are accepted.”

~ R. Buckminster Fuller

– Bob

Further Reading

Obliquity ~ John Kay
Systemantics ~ John Gall

Out Of House FlowChain

When I conceived of FlowChain, some six years ago now, my immediate context was development shops with their own in-house developers, and other supporting staff.

But it strikes me that with just a few adjustments, it’s also suitable for organisations that sub-contract out most or all of their development projects to third parties.

These adjustments centre around arranging for the various third parties (assuming, in the likely case, that there’s more than one) to each contribute staff to the “Pool” (see diagram). These arrangements include:

Commercial

How will the third parties be paid? Some UK government functions use function points as a measure of “work done”, with a set price for each function point “delivered”. See: Output-based contracts. I can imagine other contractual arrangements, too.

Social

How will the third parties’ staff integrate or form healthy relationships with the in-house commissioning staff (a.k.a. product owners)? Will there be shared spaces? Regular visits to and fro? Some more technical forms of communication (Twitter, chat, video conferencing, etc.)? Remember, each backlog item is sized for two to three people working together for two to three days.

Tooling

Third parties remain free to pull items from the backlog as they see fit (just as with in-house FlowChain), and use their own tools, languages, etc.. I foresee some advantages in having a common code repository, coding and other standards, agree requirements around test suites, and so on.

Delivery Into Production

Maybe the organisation contracting the third parties has its own Ops department. In this case the interface between development (teams, third parties) and Ops would probable best be standardised and agreed (like an API). If the third parties have their own Ops folks, then they can do DevOps in their own space and time, and serve the “production” services – or even micro-services – they each operate, directly to users.

Shared Backlog

For clarity, this variant of Flowchain retains the enterprise-wide backlog, with user stories, improvement stories, etc. being prioritised by some black box (or white box) prioritisation algorithm, committee, manager, or whatever. The only real change is in how the Pool is constituted. Note: I see no particular reason why the general FlowChain principle of “ANY unassigned development folks from the Pool can coalesce around each new top backlog item” cannot stand, here.

There may even be emergent advantages in having e.g. developers from different third parties coming together to collaborate on specific backlog items. How weird would that be? Again, policy would guide folks’ actions here.

Who would “manage” the backlog?  This could be done by a small in-house staff, or itself subcontracted out to one or more third parties. Note: the backlog in FlowChain is largely self-managing, in any case, given an effective prioritisation algorithm or approach.

Flow

Flow (of e.g. software into the hands of those whose needs are being attended to) remains the key objective of the whole approach.

Growing An In-house Capability

For organisations without an in-house development capability, this approach provides a simple(r) path to establishing and growing an in-house development capability. In-house developers can be added, one by one, as and when circumstances (budgets, priorities, etc) allow. These new folks can work alongside – and learn from – third-party staff already used to Pool working, and the balance between in-house and out-of-house staff, skill sets, etc. adjusted dynamically as needs dictate.

Drawbacks

The key drawback I foresee is in the matter of dev-ops integration (DevOps). This could prove more difficult, in the case where developers, etc. are out-of-house and Ops in-house. This seems a special case of the issues of outsourcing and offshoring, generally. But I’m sure a bunch of smart developers and smart ops can work this out, especially with some help and guidance.

– Bob

NeedsFlow

[Tl;Dr: The essence of software and product development is about continuously exploring and meeting folks’ needs. How about as in industry we stop shilly-shallying and place this reality at the core of our approach to development?]

The Essence Of Software And Product Development

Essentially, every approach to software and product development is about a flow of things (including services) whereby a development team, group or organisation attempts to satisfy some selection of folks’ unmet needs.

In batch-and-queue (e.g. Waterfall, etc.) approaches, needs are batched-up into large batches, and flow (not very effectively) through a sequence of queues. Each batch (in the pathological case, only one) eventually gets dropped onto those assumed to have said needs, and that’s about it.

In iterative (e.g. Scrum, Kanban, etc.) approaches, needs are batched up into many, relatively smaller, batches, and flow (rather more effectively) through a sequence of queues (at its simplest, e.g. Backlog, Doing, Done). Each batch gets dropped onto the folks assumed to have said needs, and these folks get the chance to say if their needs have been met well enough, or not. When budgets and timescales allow, a later iteration can then have another go at better meeting those needs deemed to have been poorly-met, along with a new attempt to address any other priority needs that might have emerged along the way.

Different approaches differentiate themselves on e.g. batch sizes, selecting of the kinds of folks whose needs will be attended to, cadence and strategies.

Needs Trump Value

Why Needs flow? Why not just stick with the more common “value” flow? Well, for me there’s a whole bunch of issues around the notion of value. Including:

• Value for whom?
• Who gets to specify how any particular “value” is measured or quantified (most often folks ill-equippped to do so).
• The whole notion of “value” (often overlooked, often misunderstood).
• Value is too often though of in simple economic or financial terms. Human beings perceive value differently, and much more richly (e.g. emotionally).
• How can we tell when we’ve delivered “value”?

So, I propose that needs trump value. And therefore, that when focussing on flow, it’s more useful – and effective – to focus on the flow of needs.

The above diagram shows a system boundary – this could be the whole organisation, the development organisation, or just one development team. Bundles of external needs flow into the system, and merge with other bundles of needs coming from inside the system. These bundles pass though various stages (and queues) where “development” strategies are uses in moving the bundles from stage to stage, and from queue to queue. Ultimately, candidates (things we hope will meet the needs that entered the pipeline) flow back to external parties, and also to internal stakeholders, such as the developers themselves.

Impediments

This perspective allows for the simple integration of dealing with impediments. Things that are impeding e.g. flow or the outflow of effective candidates may themselves be needs. And may enter the pipeline much as any other needs. Of course, there may be some( or many) such impediments than no one has any need of dealing with. These may be filed or ignored.

Abstract FlowChain

Whilst FlowChain was conceived to be awesomely effective at handling bundles of e.g. User Stories, Use Cases, Improvement Stories, etc., it can very easily embrace the unit of flow being bundles of needs, or – in the single-piece-continuous-flow scenario – individual needs.

Limiting WIP, Making Things Visible

From the diagram, you may begin to see how we might simply make the flow of needs visible, should we so choose. And personally, I’d like to make visible the ultimate fate of the candidates too, with a little expansion of the scope of the diagram.

And the queues (particularly the first) can serve as a convenient means to limit Work In Progress (a.k.a. Needs in Progress).

No Projects

It may not be immediately obvious, but the NeedsFlow perspective implicitly removes the need for projects. NeedsFlow decouples development (flow) from products and product lines (each of which meet a more or less related collection of needs).

– Bob

No Projects

The idea of “projects” in software and product development is a glaring anachronism, traceable back to the days when organisations saw each new project as “the last one we’re ever likely to run”. Absent the expectation of ever running another project, why bother moving to a more continuous, flow-based (non-project) set-up?

And of course, the idea of breaking things down into parts, and managing those parts separately, is another glaring anachronism, and one still grasped so tightly by those of the Analytic mindset.

But even the briefest of reflections about the nature of development work in organisations reveals a simple truth: just about every organisation today has a more or less continual flow of work – of new ideas transforming into products, of concepts becoming cash revenue generators.

I won’t dwell further here on the case for #NoProjects – Grant made the case quite well in his piece “What’s Wrong With the Project Approach?”. Maybe you’d like to consider the relative (dis)merits of “projects” – compared to a more flow-oriented approach?

May I just invite you to consider whether there may be other, maybe better ways of getting folks’ – and organisations’ – needs met?

And, by the by, offer up FlowChain as a simple – and complete – example of what I’m talking about in terms of one such better way.

– Bob

Seven Changes To Improve Flow In Your Software Development Process

Many folks drinking the Lean coolade seem to believe that removing waste is at the heart of the Lean approach. I beg to differ. I’d say that improving flow is the heart of Lean.

Here’s seven ways in which your team or, preferably, your organisation as a whole, might go about improving flow:

1. Adopt a small thing as the universal unit of work. And by universal, I mean some unit of work that everyone across the whole organisation can recognise and adopt. This could be Use Cases, User Stories, or something else. Just keep the “small thing” small (never more than a couple of days work for a couple of people). cf Heijunka, FlowChain.
2. Make flow visible. In particular, make e.g. queues, queuing times, and end-to-end cycles times visible for all to see.
3. Know your WIP (work in progress) and work to reduce (limit) it. Cf. Little’s Law.
4. Use demand to “pull” units of work through the system (as opposed to “pushing” work through).
5. Eliminate – or at least minimise – hand-offs. That is, having work pass from one specialist to another. Each hand-off typically introduces another queue, with the inevitable costs and delays. One way to do this involves multi-disciplinary teams, or better still, up-skilling individuals so each person can competently take on a variety of specialist tasks.
6. Identify the goal; understand demand (by various means – for example follow individual “demands” through the system, end-to-end;) identify the constraint; and apply the Five Focussing Steps (repeatedly). Cf. Theory of Constraints
7. Experiment continually: trial possible improvements to flow, one by one, to assess their actual efficacy, in isolation from one another. Cf. PDCA a.k.a. the Shewhart Cycle.

And of course, none of the above suggestions will do much good, or even get acted on, unless and until the folks doing the work internalise a basic appreciation of the very notion of flow. And that’s unlikely to happen unless and until the work environment supports and nurtures folks’ curiosity and innate desire to do a good job.

Further Reading

The Principles of Product Development Flow ~ Donald G. Reinertsen
Seven Changes To Remove Waste From Your Software Development Process ~ Cecil Dijoux
Product Development Flow ~ FlowchainSensei
LondonCD Talk based on this post ~ Video
Getting People to Limit Their Work In Progress ~ Ben Linders