Archive

Software Delivery

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.

Are Managers Killing Their Golden Geese?

Cognitive Function Rules

Cognitive function encapsulates the mental processes needed for problem-solving, abstract thinking, and quick decision-making. In the realm of software development, high cognitive function is indispensable for understanding complex algorithms, creating efficient code, delivering quality, and solving intricate problems.

Why Does Cognitive Function Matter?

When cognitive function is at its peak, developers can perform their tasks not just quickly but also effectively. It enables them to come up with innovative solutions, debug issues proficiently, and contribute meaningfully to a project’s success.

How Do Managers Disrupt Cognitive Function?

Routine managerial practices like frequent check-ins, status reports, micromanagement, and unclear objectives can negatively impact a developer’s cognitive function. Added to this, loaded work schedules and harsh deadlines contribute to stress, which further degrades cognitive performance.

What About Toxic Behaviour?

Abusive and toxic conduct from managers goes beyond disrupting cognitive function. This behaviour often leads to severe emotional stress, causing long-term harm – including brain damage – that manifests as burnout, poor performance, and staff turnover.

What’s the Consequence?

When cognitive function suffers, the ripple effect is felt throughout the team and the organisation. There’s a decline in product quality, an increase in mistakes, and a noticeable lag in delivery timelines. In such a scenario, managers are essentially killing the very geese (developers) that lay the golden eggs (software).

Is There a Remedy?

Creating a more nurturing work environment can help. Managers might choose to adopt practices that allow for focused work, respect individual needs, and most importantly, eliminate toxic and abusive behaviours.

Will Change Happen?

The ball’s in the managers’ court. The cognitive well-being of their software developers—and by extension, the quality and success of their own wellbeing—depends on how they choose to adapt their management styles.

Improving Without Measuring

The Mirage of Measuring Productivity

Most organisations regard metrics as the Holy Grail of productivity. But what if we’re wasting our time, trapped in a Sisyphean cycle of measuring, adapting, and then measuring again, without achieving improvement? Metrics often mislead us. The more relevant question is: How do we truly make a difference?

The Complexity of Social Systems in Software Development

To get to the heart of the issue, we have to confront the chaos that comes with human beings working together. People aren’t variables in an equation; they’re living, breathing agents of unpredictability. In such an environment, even if we find a metric that looks promising, the inherent complexity could render it meaningless.

Deming’s Caveat: “The Most Important Figures are Unknown or Unknowable”

Before we take another step down the rabbit hole of productivity metrics, let’s pause to reflect on a pertinent insight from W. Edwards Deming, the father of modern quality management. He stated,

The most important figures that one needs for management are unknown or unknowable.

If one of the most influential minds in quality management and productivity warns us against an over-reliance on metrics, it’s worth taking note.

Why Metrics Often Fail in Social Systems

Metrics tend to misfire when applied to the inherently chaotic world of human interaction. It’s not a mechanical system with predictable outcomes; it’s more of an organic entity with complex, non-linear interactions. So, when metrics disappoint, it’s not the numbers that are at fault but our misplaced expectations of their ability to capture reality.

Turning to Systemic Improvements: The Untold Chapter

If we heed Deming’s advice, our focus shifts from trying to measure the immeasurable to creating conditions for productivity to flourish. When we step back from the Sisyphean task of trying to pin down productivity with metrics, as per Deming’s counsel, we make room for a paradigm shift.

Instead of fixating on measured outcomes, the focus turns towards the fertile ground from which these outcomes naturally emerge. Here’s how this shift fundamentally changes our approach to productivity. (Cf. Quintessence).

Systems Thinking: The Big Picture

Deming was a strong advocate for systems thinking. This perspective urges us to see the workplace not as a collection of isolated variables but as a holistic system. Individual performances are interrelated, affected by the entire system, including leadership styles, workplace culture, communication pathways and a host of other memes. By optimising the system as a whole, we inherently create conditions for better productivity.

Quality of Interactions Over Quantity of Output

If we’re not bogged down by the numbers, we can invest time and energy into what really matters, such as the quality of interactions among team members. High-quality interactions naturally lead to high-quality output. Team members who communicate clearly, collaborate effectively, and feel psychologically safe are more likely to be productive.

By heeding Deming’s advice, we engage in a more holistic, humane, and, ironically, effective approach to boosting productivity. We may not have a neat vanity metric to showcase in the next board meeting, but the signs will be everywhere—in the engagement of the team, the quality of the work, and the satisfaction of your clients.

Improving Without Measuring: Sounds Like Heresy, Doesn’t It?

Here’s the part where some people might think we’re heading into taboo territory. How do we know we’re making progress if we’re not measuring it? The key is to focus on systemic improvements that are intuitively beneficial, such as:

  • Surfacing and reflecting on collective assumptions and beliefs
  • Attending to folks’ needs
  • Enhancing communication channels
  • Making things visible
  • Reducing work-in-progress
  • Emphasising learning and personal development
  • Promoting psychological safety

By attending to these areas, we’re likely moving in the right direction, even if we can’t quantify it.

Feedback Loops: Your New Best Friend

Feedback loops provide insights without the narrow focus of traditional metrics. They allow teams to observe patterns, adapt, and continuously learn. These can range from daily stand-ups to sprint reviews, to customer feedback sessions. The idea is to keep the feedback continuous and actionable.

Holistic Approaches: Taking a Cue from Organisational Psychotherapy

Improving productivity in complex systems requires less of a mechanical approach and more of a therapeutic one. Techniques like organisational psychotherapy aim to uncover underlying issues at the collective subconscious level. By addressing these foundational aspects, we’re more likely to see a genuine shift in productivity.

So, Are We Moving the Needle?

The perennial question still stands: How do we know we’re improving? But maybe we’ve been asking the wrong question. The more relevant question is: Are we creating an environment where improvement is not just possible but inevitable? And what does that environment look like?

So, let’s leave behind the vanity of metrics and embrace the nuanced, often messy journey of actual improvement. The numbers may not make it to a glitzy PowerPoint presentation, but the positive change will be palpable. And isn’t that what really matters?

The Deming Way to Measuring Software Developer Productivity

Many software folks pay lip service to Bill Deming and his work. Few if any pay any attention to the implications. Let’s break the mould and dive into how the great man himself might look at software developer productivity (a subset of collaborative knowledge worker productivity more generally).

This isn’t just a thought experiment; it’s an invitation to rethink our existing assumptions and beliefs about productivity.

Why Traditional Metrics Don’t Cut It

If Deming could peer over our shoulders, he’d likely be aghast at our fascination with shallow metrics. Lines of code? Bugs fixed? DORA? SPACE? These are mere surface ripples that fail to delve into the depths of what truly constitutes productivity. Deming was a systems thinker, and he’d want us to look at productivity as an outcome of a complex system. It’s influenced by everything from the quality of management practices to the clarity of project goals, and yes, even the standard of the coffee in the break room.

Aside 1

Let’s not get too hung up on staff productivity and the measurement thereof.

Deming’s First Theorem states that:

“Nobody gives a hoot about profits.”

A corollary might be:

“Nobody gives a hoot about software developer productivity.”

Which, drawing on my 50+ years experience in the software business, rings exceedingly true. Despite all the regular hoo-hah about productivity. Cf. Argyris and espoused theory vs theory in action.

Aside 2

While we’ve on the subject of measurment, let’s recognise that measuments will only be valid and useful when specified by and collected by the folks doing the work. I’ve written about this before, for example in my 2012 post “Just Two Questions“.

Aside 3

Let’s remember that the system (the way the work works) accounts for some 95% of an individual’s productivity. Leaving just 5% that’s a consequence of an individual’s talents and efforts. This makes it clear that attempting to measure individual productivity, or even team productivity, is a fool’s errand of the first order.

Here’s the Deming Approach

So, how would the statistician go about this? Hold on to your hats, because we’re diving into an eight-step process that marries statistical rigour with psychology and humanistic care.

1. Understand the System

First things first, get to grips with the holistic view. Understand how a line of code travels from a developer’s brain to the customer. This involves understanding the various elements in the software development lifecycle and how they interact.

2. Define Objectives

Random metrics serve no one. Deming would urge us to link productivity measurements to broader business objectives. What’s the end game? Is it faster delivery, better quality, or increased customer satisfaction?

3. Involve the Team

The people on the ‘shop floor’ have valuable insights. Deming would never neglect the developer’s perspective on productivity. Involving them in defining productivity criteria ensures buy-in and better data accuracy.

4. Data Collection

We’ve got our objectives and our team’s perspective. Now it’s time to roll up our sleeves and get to work on data collection. But this is Deming we’re talking about, so not just any data will do. The focus will be on meaningful metrics that align with the objectives we’ve set.

5. PDSA Cycle

Implementing the Plan-Do-Study-Act (PDSA) cycle, any changes aimed at boosting productivity would be introduced in small, incremental phases. These phases would be assessed for their effectiveness before either full implementation or going back to the drawing board.

6. Feedback Loops

You’ve made changes; now listen. Feedback from developers, who can offer a real-time response to whether the changes are working, is invaluable.

7. Regular Reviews

Productivity isn’t a static entity. It’s a dynamic component of a system that’s always in flux. Regular reviews help recalibrate the process and ensure it aligns with the ever-changing landscape.

8. Leadership Commitment

Finally, if you think increasing productivity is solely a developer’s job, think again. The leadership team must be as committed to this journey as the developers themselves. It’s a collective journey toward a common goal.

The Long Game

Deming never promised a quick fix. His was a long-term commitment to systemic improvement. But the fruits of such a commitment aren’t just increased productivity. You’re looking at more value for your business and greater satisfaction for both your developers and customers. So, let’s stop paying lip service to Deming and start actually embracing his philosophy. After all, a system is only as good as the assumptions and beliefs that shape it.

Maximising the Amount of Work Not Done: The Power of Attendants in Tech Teams

The world of technology is evolving rapidly, and to keep pace, we must continually reassess how we approach our work. A concept gaining popularity in tech leadership circles is the idea of “Maximising the Amount of Work Not Done.”

Counterintuitive

While this may sound counterintuitive, it is a strategic move towards efficiency and streamlined operations. The role of the “Attendant” embodies this principle. Let’s delve deeper.

The Attendant’s role is less focused on coding intricacies and more on recognising and satisfying the needs of various stakeholders – customers, fellow team members, other teams within the organisation, senior management, and the organisation as a whole. The attendants’ goal? To find the simplest and most efficient solutions to meet these needs.

In doing so, Attendants embody the principle of maximising the amount of work not done. Here’s how:

  1. Focusing on What Really Matters: In any project, there can be a multitude of potential features, tweaks, and enhancements. However, not all are equally important or add significant value. Attendants prioritise based on the actual needs of stakeholders, focusing efforts only on work that meets genuine needs. This eliminates unnecessary tasks and promotes efficiency.
  2. Streamlining Communication: Miscommunication can lead to rework and delays. Attendants foster clear, effective communication among various parties, ensuring everyone understands the goals and requirements from the start. This reduces the chance of misunderstandings that can lead to unnecessary work and rework.
  3. Advocating for Simplicity: Attendants champion the philosophy that simplest is often best. They seek to develop solutions that meet everyone’s needs effectively without unnecessary complexity. This can drastically reduce development time, cut down on potential bugs, and increase the speed of product delivery.
  4. Preventing Over-Engineering: By maintaining a sharp focus on stakeholders’ needs and the simplest ways to meet them, Attendants help prevent over-engineering— the practice of making a product more complicated and/or feature-rich than necessary. This not only saves time and resources but also results in products that are easier to use and maintain.

Game Changer

Embracing the Attendant’s role and their commitment to maximising the amount of work not done can lead to more efficient, streamlined operations. It brings a focus on delivering value quickly and eliminating tasks that do not directly contribute to meeting stakeholders’ needs. In a rapidly evolving tech landscape, this approach is a game-changer.

“Not Everybody Matters”: A Bold Approach to Streamlining Software Development

💡 Need to unlock your team’s full potential and supercharge your software development process? Uncover the game-changing strategy behind embracing “Not Everybody Matters”, and learn how mastering the Needsscape and understanding the Cost of Focus can catapult your project to success! 🎯💥🚀

➡ In the world of software, service and product development, catering to every stakeholder’s needs can be both challenging and resource-intensive.

Embracing the idea that “Not Everybody Matters” can lead to more effective development processes by prioritising the most critical needs and stakeholders. By focusing on the essential elements of a project, teams can allocate resources more effectively and reduce development time.

The Needsscape
The Needsscape is a concept that helps identify and dynamically prioritise the needs of various stakeholders. By carefully tracking the Needsscape, development teams can determine which needs have the most significant impact at any given moment, and align their efforts accordingly. This approach acknowledges that not all needs are equally important, and allocating resources to meet every need regardless of relative impact leads to increased costs and inefficiencies.

The Cost of Focus
The Cost of Focus is the trade-off that occurs when concentrating on one are over another. By acknowledging that “Not Everybody Matters,” development teams can make informed decisions about where to invest their time, effort, and resources. This approach might involve prioritising features that have the highest value for the majority of users or focusing on the needs of specific subsets of the audience.

The concept of “Not Everybody Matters” in software development is a bold approach that encourages teams to prioritise the most critical needs and stakeholders by leveraging the Needsscape and understanding the Cost of Focus. By doing so, they can streamline the development process, maximise the value delivered, and ultimately create more successful software products.

Software Development: It’s Not Even Slightly About Tech Skills and Coding Practices

💡 What’s the undervalued secret sauce of software success? You’re in for a wake-up call as we reveal the overlooked ingredients that make or break software success in the business world.

➡ Blimey, it’s no surprise that most execs – those few that are even slightly interested in software development – reckon it’s all about tech skills and coding practices. But I’ll tell you, there’s more to this picture than meets the eye. Sure, being a dab hand at coding is somewhat useful, but in the context of business operations, it’s just the tip of the iceberg.

You see, the nitty-gritty of software development, especially in a business setting, also involves top-notch communication, teamwork, and adaptability.

And let’s not forget, building strong interpersonal relationships is a piece of cake for no one, but it’s a skill developers need to master to keep things from going pear-shaped.

A good understanding of the customer’s needs and the company’s goals is also crucial. After all, you can’t score a winner if you don’t know where the goalposts are. So, execs might choose to realise that there’s more to software development than just cranking code. And much more to hiring than the recruitment of code toads.

A successful software development team is the whole package. It’s not just about having a bunch of coding whizzes; it’s also about fostering a culture where everyone’s on the same page, working together as a community to bring work to fruition. Otherwise, businesses might find themselves up a creek without a paddle.

Software Development: Culture Shift is More Vital Than Any Coding Practices

With 50+ years experience in the software development industry, I’ve come to understand that the key to progress in this field lies not in technological advancements, but in cultural changes.

Alan Kay’s concept of obliquity highlights the idea that the most effective way to achieve a goal is not always by pursuing it directly, but rather by approaching it from a different angle. In the context of software development, this means that our focus might better be placed on changing the underlying culture that shapes how software is created and delivered.

The current state of the industry is far from optimal, with over 90% of Agile adoptions failing to deliver the promised benefits. The pressure to meet unrealistic deadlines, the lack of whole-systems thinking, and the absence of a learning culture all contribute to the failure of Agile initiatives.

A critical aspect of cultural change is the need to embrace failure. Failure is not something to be feared, but rather an opportunity to learn and grow. It is through failure that we discover what works and what doesn’t, and can adapt our approach accordingly. A culture that embraces failure as a natural part of the learning process is one that is more likely to succeed in the long run.

In addition, we must move away from the traditional focus on individual performance metrics and instead measure success based on the collective achievements of the whole organisation. This means redefining success as the ability to deliver high-quality software that meets the needs of the business and its customers. It also means recognising and rewarding collaborative behaviour, rather than individual contributions.

Finally, we must recognise that cultural change is a continuous process, not a one-time event. It requires ongoing effort and commitment, and must be reinforced through the actions and behaviours of leaders at all levels of the organisation. By fostering a culture of collaboration, learning, and continuous improvement, we can create an environment conducive to the adoption of effective practices.

In conclusion, technological advancements are of little import in software development, unless accompanied by cultural changes. Alan Kay’s concept of obliquity reminds us that sometimes the most direct path is not the most effective. By focusing on building a culture that values collaboration, learning, and continuous improvement, we can deliver better outcomes for our businesses and customers.

Revolutionising Solution Delivery: The Power of Artefact Driven Delivery

Artefact Driven Delivery is a method of solution delivery, created at Familiar, that focuses on using artefacts as the main unit of progress, instead of tasks. This approach avoids the Cost of Delay, deferred feedback, and other risks associated with traditional approaches to solution delivery. Approaches which delay work on implementing a solution until all requirements, designs, etc. are fully defined. Instead, skeleton standard artefacts are available from the beginning of the solution development process, are based on standard templates. The artefacts are then gradually filled with solution-specific content as they are needed for implementation and delivery.

The standard artefacts used in this approach include the Control Document, Articles of Understanding, Glossary of Terms, Statement of Purpose, Case for Action, Vision, Folks That Matter and their Needs, Risk Parade, Top Risks, Functional Requirements, Non-functional Requirements, Critical Success Factors, Feature Schedule, Quality Plan, Test Plan, Change Control, Cycle Plans, and Cycle Reviews. These artefacts are continually shared with clients and serve as a running history of the endeavour.

The Artefact Driven Delivery approach follows the Antimatter Principle which is covered extensively on my blog. For the curious, the “Javelin” White Paper provides a more in-depth explanation of each of the artefacts.

In conclusion, Artefact Driven Delivery is a method of solution delivery that emphasises the use of artefacts as the main unit of progress. It avoids the risks associated with traditional approaches, by establishing standard artefacts from the beginning of the solution development process and gradually filling them with solution-specific content as needed.

This approach results in a running history of the solution development and better communication between clients and the development team.

Waiting In The Wings

What’s going to the next big thing in terms of approaches to software delivery? And when might we expect the transition to that next big thing to become apparent?

“The future’s already here – it’s just not evenly distributed.”

~ William Gibson

The Days of Agile Are Numbered

We can argue about how much life the Agile approach to software delivery has left in it. What’s beyond dispute is that there will be something after Agile. And I propose it will  look much different from Agile. I find it inconceivable that Agile is so perfect that there’s no room for improvement. Even though – ironically, give the exhortations to “inspect and adapt” – many in the Agile supply chain don’t want to talk about it AT ALL. Why rock the boat and derail the gravy train?

Customers and users, however, are waking up to the inadequacies of presently lauded approaches. And current upheavals in organisations, such as remote working and the scramble for talent, are accelerating these folks’ dissatisfaction.

Holding You Back

What’s prolonging the transition towards any new approach? Basically, it’s the prospect of the serious pain that comes with the adoption of effective new approaches. SAFe’s transient popularity illustrates how many organisations prefer an ineffective approach, with the illusion of change, rather than an effective approach that actually brings benefits. Any significant uplift in software delivery and product development performance implies a much different approach to running technology organisations, including, not least, different styles of management.

Your View?

What’s your view? What promising new approach(es) do you see waiting in the wings? And if there’s nothing with a recognisable name or label, what characteristics will a new approach have to have to boost it into consideration?

– Bob

Reasons To Be Cheerful, Part 3

Some of you dear readers may, entirely reasonably, assume that I mention my books in the hope of increasing sales. However, this just ain’t so.

I mention my books in a vainglorious attempt to effect some positive shift in the world of business. I’ve written many times about my motivation. Specifically, my delight in helping people have a more joyful time in the world of work (in particular, Collaborative Knowledge Work).

I truly believe that Organisational Psychotherapy is a path to saner, more joyful, more humane workplaces. And my book “Quintessence” illustrates and maps out what a saner, more joyful organisation looks like and works like, in detail.

Maybe you share my enthusiasm for change, and for seeing things improve. Maybe you’re content with – or at least resigned to – the status quo.

In any case, I’d hate for my enthusiasm to be a source of frustration or angst for you.

On the other hand, I’d be delighted if through reading one or more of my books – or even blog posts or white papers – you might find a different perspective on what ails you, and new, more effective ways to meet folks’ needs, including your own.

– Bob

Further Reading

Marshall, R.W. (2021). Quintessence: An Acme for Software Development Organisations. [online] leanpub.com. Falling Blossoms (LeanPub). Available at: https://leanpub.com/quintessence/ [Accessed 16 Jun 2022].
Marshall, R.W. (2021). Memeology: Surfacing And Reflecting On The Organisation’s Collective Assumptions And Beliefs. [online] leanpub.com. Falling Blossoms (LeanPub). Available at: https://leanpub.com/memeology/ [Accessed 16 Jun 2022].
Marshall, R.W. (2018). Hearts over Diamonds: Serving Business and Society Through Organisational Psychotherapy. [online] leanpub.comFalling Blossoms (LeanPub). Available at: https://leanpub.com/heartsoverdiamonds/ [Accessed 16 Jun 2022].
Marshall, R.W. (2021). Organisational Psychotherapy Bundle 1. [online] Leanpub. Available at: https://leanpub.com/b/organisationalpsychotherapybundle1 [Accessed 16 Jun. 2022].
http://www.youtube.com. (n.d.). Ian Dury and The Blockheads – Reasons To Be Cheerful, Pt. 3 (Official Lyrics Video). [online] Available at: https://www.youtube.com/watch?v=1injh4-n1jY&ab_channel=IanDury&TheBlockheads [Accessed 16 Jun. 2022].

Building Things

We could describe my whole career as one of building things.

Early on, these things included software, hardware and tech products such as fax servers, compute clusters, compilers, interpreters, network systems, operating systems, development languages, applications, databases, and so on.

Later, things morphed to building teams, communities, software development and delivery groups, business units and tech companies.

Most recently, the things I build have morphed again, into techniques, approaches, tools and know-how applicable to building things.

Learnings

This post is mainly concerned with sharing some of the insights I’ve gleaned over the years. Insights into effective ways of building things:

Purpose

When embarking on building a new thing, I choose to dwell for a while on the purpose of the thing I’m building: Who’s it for? What will they use it for? How will they use it? What needs do they have that this thing willl address?

Needs

What does the Needsscape look like? How can we anticipate it changing over time? And how will we monitor and respond to those changes?

Intentionality

Doing things with a clear understnading of where those things fit in the scheme of things. Rather than just spinning the wheels for the sake of feeling busy.

Quality

Answer the question: “How will we ensure that what we’re building manifests the quality/qualities needed by all the Folks That Matter?

Risks

Manage all key risks facing us in bulding the thing (and in deploying, using it too). See Tom Gilb’s “All Holes In The Boat” principle (any one key risk can sink the whole effort).

Incrementality

Build things in small increments. Get regular feedback from all the Folks That Matter, early and often. Whilst continually remaining open to the system-wide impact of what’s being built.

Clarity of Communication

One can never have too much communication. One can never have too much clarity of communication. I prefer to use Quanitification as the means to improving clarity of communication.

Make Things Visible

Particularly with the kinds of things I’ve been building over the years, things nebuluous and more or less invisible most of the time, it helps to find ways to make e.g. progress visible and clearly understandable to all the Folks That Matter.

PDCA

Often called the Shewhart Cycle or Deming Cycle. PDCA (Plan-Do-Check-Act) offers a conceptual framework for building things:

  • Plan what we’re going to do in the next days or weeks.
  • Do stuff according to that plan.
  • Check how well we did stuff (identify shortcomings)
  • Act to address some shortcomings in our doing, so that the next cycle’s doing goes better.

Ownership

Deming banged on about the necessity for people to have pride in what they do. I find pride is enhanced through people feeling they own what they’re building.

Build Less

Build as little a possible. With the lowest tech possible. Commensurate with meeting folks’ needs. Remember YAGNI.

Summary

I don’t expect the above list to be of much use to anyone. Because, normative learning. C’est la vie.

– Bob

The Future Of Software Delivery

Are you curious about how software will get written and delivered in the future? When all the Agile malarkey has faded away?

About your career and what skills and abilities will be in demand in a few years’ time?

Take a look at my book “Quintessence“ for a detailed road map of what the future of software delivery looks like.

My book “Memeology” describes in detail how organisations can make this future theirs, starting today.

And “Hearts Over DIamonds” sets out the foundations for Organisational Psychotherapy – the core principles for our Quintessential future.

Or read the whole series, and get a deep understanding of the role of Organisational Psychotherapy in businesses of the future.

– Bob

Further Reading

Marshall, R.W. (2021). Quintessence: An Acme for Software Development Organisations. [online] leanpub.com. Falling Blossoms (LeanPub). Available at: https://leanpub.com/quintessence/ [Accessed 12 Jun 2022].
Marshall, R.W. (2021). Memeology: Surfacing And Reflecting On The Organisation’s Collective Assumptions And Beliefs. [online] leanpub.com. Falling Blossoms (LeanPub). Available at: https://leanpub.com/memeology/ [Accessed 12 Jun 2022].
Marshall, R.W. (2018). Hearts over Diamonds: Serving Business and Society Through Organisational Psychotherapy. [online] leanpub.comFalling Blossoms (LeanPub). Available at: https://leanpub.com/heartsoverdiamonds/ [Accessed 12 Jun 2022].

You Don’t Understand Software Delivery

And the more senior you are, the less you understand. Even if you were once a developer, given that most developers don’t understand software development / software delivery, a developer background is not going to help you much.

Who does understand software delivery? Folks who have studied it as a discipline. And that’s precious few indeed. Of all the “development” folks I’ve met over the years – and that’s thousands – wayyy less than one percent actually have an effective understanding of the field.

Yes, there’s thousands upon thousands of folks who understand coding (programming). But that’s not much help at all in forming a broader and effective understanding of the wider software delivery discipline.

The upshot? The software industry is stacked to the gills with folks who have no clue what they’re doing, except in the narrowest of specialism. And worse, no ability to recognise the one percent. Result? The blind leading the blind. And the hegemony of the one-eyed man.

– Bob

More On Sea Change

Do you need to see a Sea Change in the software industry, or does the status quo suit you and your needs just fine and dandy, thank you very much?

As the inventor of Agile software development circa 1994, I feel uniquely placed to suggest the need for such a sea change,and what that sea change might look like.

It’s all laid out in my most excellent book “Quintessence“, along with its companion volumes “Hearts Over Diamonds” and “Memeology“.

How often have you discussed the subject with your peers, friends, colleagues, higher-ups, etc.?

Without your active support and involvement, a sea change ain’t never likely to happen. Until then, status quo FTW.

– Bob

Further Reading

Marshall, R.W. (2021). Quintessence: An Acme for Software Development Organisations. [online] leanpub.com. Falling Blossoms (LeanPub). Available at: https://leanpub.com/quintessence/[Accessed 08 Jun 2022].
Marshall, R.W. (2021). Memeology: Surfacing And Reflecting On The Organisation’s Collective Assumptions And Beliefs. [online] leanpub.com. Falling Blossoms (LeanPub). Available at: https://leanpub.com/memeology/ [Accessed 08 Jun 2022].
Marshall, R.W. (2018). Hearts over Diamonds: Serving Business and Society Through Organisational Psychotherapy. [online] leanpub.comFalling Blossoms (LeanPub). Available at: https://leanpub.com/heartsovediamonds/ [Accessed08 Jun 2022].

We Need Your Help!

We so need your help in increasing the reach of our message about Quintessence. The more folks that get to hear, the sooner we’ll all benefit from a saner, more humane, more joyful way of delivering software. It’s way past time we all explored together what’s next.

We’re not asking you to subscribe to our assumption and beliefs. Just to mention (not recommend, not talk up) Quintessence to your friends, peers, colleagues and higher-ups.

Something along the lines of:

Have you heard about Quintessence? That batshit crazy Bob Marshall (FlowChainSensei) has invented/discovered an approach to software delivery entirely different from what we all know. He says it’s five times more productive than e.g. Agile approaches. Mental!

Would you be willing to help us spread the word about Quintessence.?

Thanks!

– Bob & Ian

Further Reading

Marshall, R.W. (2021). Quintessence: An Acme for Software Development Organisations. [online] leanpub.com. Falling Blossoms (LeanPub). Available at: https://leanpub.com/quintessence/[Accessed 25 May 2022].
Marshall, R.W. (2021). Memeology: Surfacing And Reflecting On The Organisation’s Collective Assumptions And Beliefs. [online] leanpub.com. Falling Blossoms (LeanPub). Available at: https://leanpub.com/memeology/ [Accessed 25 May 2022].
Marshall, R.W. (2018). Hearts over Diamonds: Serving Business and Society Through Organisational Psychotherapy. [online] leanpub.comFalling Blossoms (LeanPub). Available at: https://leanpub.com/heartsovediamonds/ [Accessed 25 May 2022].

The #NoSoftware Option

One of the many things that distinguishes The Quintessential Group from the Software Delivery also-rans is that our Quintessential Teams service provides our clients and prospective clients with a #NoSoftware option. John Seddon and his company, Vanguard Consulting, advise deferring software automation of new business processes and process steps at least until those steps have been trialed and proven through manual implementations – Post-its, paper-based processes, manual steps, etc. For those organisations that buy into this perspective, our #NoSoftware option means our teams will deliver these non-software solutions quickly and cheaply.

Also known as “software last”, a #NoSoftware solution is one that minimises the amount of software in a solution – in particular minimising the amount of custom-written software – ideally to the exclusion of software from the solution entirely.

As Steve Jobs famously said:

The way you get programmer productivity is not by increasing the lines of code per programmer per day. That doesn’t work. 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

The Benefits of #NoSoftware

  • Less maintenance overhead

The fewer lines of code in any given solution, the less needs to be spent on keeping that code up to date in line with e.g. changing requirements and discovered defects.

  • More flexibility

Did you know that the term “software” was first coined back in the 1950’s to reflect the idea that software could be changed more easily, quickly and at lower cost than the hardware solutions that then predominated? It was supposedly easier to change a line of code than to reroute traces on a PCB, or swap out soldered components. Nice wishful thinking, but it hasn’t turned out that way. Software is notoriously expensive, inflexible and difficult to change. Less software means increased flexibility and business agility.

  • Savings on up-front costs

Software costs money to write, even before it goes into service. Not only to pay for ever more expensive programmers and their friends, but also the opportunity costs of having to wait for the software to be ready to deploy. In most organisations this can mean months or even years of waiting.

  • Minimal automation

When a new business process or process step is implemented, it’s rare for the implementors to fully understand what’s needed, and to anticipated the unintended consequences of their choices. Premature automation can lock in inappropriate or suboptimal design choices. Once a process or process step has been up and running live in a manual form for some time, it’s generally easier to see where (limited) application of software-enabled automation may bring benefits. Hence “software last”.

  • Try before you buy

Use a #NoSoftware solution live in your business to prove your process or process steps to trial the solution before committing to implementing a software-based solution. You may actually find that a software-based solution is in fact unnecessary, or can be much more limited in scope – and cost – than originally imagined.

Attending To Folks’ Needs

Implicit in the idea of #NoSoftware is the imperative of attending to folks’ needs – the primary focus of The Quintessential Group. Generally speaking, folks have little need for software per se. As the old adage goes; folks don’t need a 1/4″ drill so much as they need a 1/4″ hole. When considering the means for attending to – and meeting – folks’ needs, software is often the default, but rarely the optimal means.

Chat More?

We’d be delighted to discuss the idea of our #NoSoftware solution option and how it will be suitable for your business or organisation. Curious? Please get in touch.

– Bob

Further Reading

Seddon, J. (2019). Beyond Command And Control. Vanguard Consulting.

Software Delivery Today

Software delivery today is in a state of crisis, and has been for decades. There is little recognition that available approaches are inadequate for meeting the needs of businesses of all stripes.

Of course, available approaches are seen as sufficient. But they do not deal adequately with the challenges we face in the day-to-day work of delivering solutions that meet folks’ needs. And in particular the need for predictability, flexibility and economy. We become swamped by the complexity of large solutions, lost in a maze of folks’ needs, and mystified by confusing and ambiguous priorities.

When we look at the typical mix of deployed solutions assembled from multiple sources, the situation is even worse.

The crisis in software delivery is far greater in overall magnitude at least than the situation of the early noughties. A situation that led to the spread of Agile approaches to relieve the burden of long timescales, delivering the wrong things, and highly risky schedules. The challenges are harder to solve and the costs of not solving them are in the $trillions. “The symptoms appear in the form of disengaged and demotivated employees, disgruntled and disappointed customers, unreliable, excessively expensive, untimely, inflexible and ultimately unsuitable solutions.”

There are ways to improve things a little, are they are slowly gaining recognition. But to achieve a fundamental jump in our delivery capabilities, we need to rethink what we doing, from first principles, and using a different frame.

– Bob

Further Reading

Firment, D. (2017). Tear Down The Wall Of Confusion. [online] Medium. Available at: https://cloudrumblings.io/devops-tear-down-the-wall-46656151d71d [Accessed 23 May 2022].