Archive

Product development

Hardware design / development has had Muntzing since the 1940’s. How about importing the idea into software design / development?

Could this facilitate the spread of #NoSoftware?

Or are programmers too self-indulgent to cut out much of their crap?

 

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

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].

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 imperativeb 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.

28 Years Ago

Twenty eight years ago (i.e. 1994) almost no one was interested in doing software development differently. Waterfall and the V Model ruled the roost. And structured methods (SSADM, Dataflow diagrams, etc.) were de rigeur. I was fortunate in finding the ear of the Finance Director of Barclays Bank, who had two urgent projects he needed to see completed in double-quick time, and with no wiggle room for missing the delivery dates. He felt he could no afford to go down the traditional (slow) route.

Of course, in 1994 the term “agile” had not then been applied to software development (at least, in the way the Snowbird folks appropriated the term circa 2001),

After successfully delivering Barclay’s projects, I moved on to Sun Microsystems’ UK Java Center and brought my “new” approach (then being called “Jerid”) with me.

Having transferred my approach and ideas into several of Sun’s corporate client base (mainly banks and other financial institutions in the City), I moved on to found “Familiar” circa 1996. (Being then the first 100% Agile software house in Europe). Jerid served us well, and continues to do so – now named Javelin – up to the present day.

28 Years On

Twenty eight years on and history repeats itself. Almost no one is interested in doing software development differently. This time around, I find myself the guardian and steward of the Quintessential approach. Another step forward at least as great as Jerid was in 1994.

Sigh. And deja vue.

– Bob

An Open Letter To All Organisations

Having been involved in software (and hardware) for some fifty years now, I thought it might be time to mark the occasion with this open letter to all organisations. Especially to those organisations engaged in CKW (Collaborative Knowledge Work), such as product development and software development.

Enormous Levels of Waste

You’re wasting 80% of your time, effort, money, and human potential on bullshit work*.

You may know this already, but are too embarrassed, fearful of the consequences, or indifferent to admit it.

Or maybe your owners have so much money that wasting 80% of your operating costs is of little or no consequence to them, and thus to you.

Or you may be unaware of the potential upside of adopting modern organisational practices, and of the downside of retaining your traditional management assumptions and beliefs**.

*Bullshit work: a.k.a. busywork – work that consumes time, effort and energy yet adds no value, and meets no needs of any of the Folks That Matter™️.

Rightshifting

The Rightshifting Chart illustrates just how much time and effort gets wasted in CKW organisations:

The Marshall Model

And the Marshall Model explains the source of such waste (it’s the consequence of the collective assumptions and beliefs a.k.a. mindset, or memeplex, of these organisations):

Over the years, various independent consultants have validated these models.

Consultation in Confidence

**If you’d like a brief, utterly confidential, and no obligation chat about how your organisation could benefit from wasting less of your time, energy and effort, please get in touch via e.g. LinkedIn: https://www.linkedin.com/in/bob-marshall-flowchainsensei-3a2a5b164/ – or via whatever channel you may prefer.

– Bob

Seeds of Failure

Agile has become widespread and popular mainly because it promises “improvements” without demanding that the decision-makers change. Of course, without people changing (in particular, managers changing their collective assumptions and beliefs) Agile has zero chance of delivering on its promises. It then becomes “just one more packaged method to install in the development teams” – and just one more debacle.

As the French say:

“Plus ça change, plus c’est la même chose”.

Thus Agile carries with it the seeds of its own inevitable failure.

“But what if managers DO change?” I hear you ask.

Well, if they change themselves in ways that move them and their organisations towards the quintessential, they won’t chose Agile.

Seeds of Success

And if you’re wondering what the seeds of success might look like, you may like to take a look at my recent book “Quintessence” (Marshall 2021).

– Bob

Further Reading

Marshall, R.W. (2021). Quintessence: An Acme for Software Development Organisations. Falling Blossoms (LeanPub).

Rightshifting and Quintessence 

Long-time readers of this blog will already be familiar with the concept of rightshifting. 

Shifting an organisation to the right (i.e. in the direction of increased organisational effectiveness, and towards the quintessential) is not for the work-shy or indolent. Yet the rewards are massive. 

Whilst the Marshall Model provides a general framework for such rightshifting, there’s not been a detailed roadmap describing the shifts necessary to acquire such improved effectiveness. 

My most recent book, “Quintessence”, provides just such a roadmap (or blueprint). It details the shifts in collective assumptions and beliefs necessary to become a highly effective knowledge-work organisation. Shifts of which significant outliers such as Zappos, WL Gore, Morning Star, Semco, and a host of others have demonstrated the benefits.

Go take a look and gaze in awe at what is possible in the way of improvements. 

– Bob

Further Reading

Marshall, R.W. (2018). Hearts over Diamonds: Serving Business and Society Through Organisational Psychotherapy. Falling Blossoms (LeanPub).

Marshall, R.W. (2021). Memeology: Surfacing and Reflecting On the Organisation’s Collective Assumptions and Beliefs. Falling Blossoms (LeanPub).

Marshall, R.W. (2021). Quintessence: An Acme for Software Development Organisations. Falling Blossoms (LeanPub). 

Effectiveness

It’s long been observed that folks commissioning i.e. product developments have a natural tendency to believe that quality costs money. Which is to say that they tend to believe that a higher quality product costs more to develop and deliver into the market. Even though Phil Crosby put the lie to this fallacy decades ago with his observation, detailed in his book of the same name, that “Quality is Free”.

So it is with effectiveness. I’ve met many folks who unwittingly assume that having their organisations become more effective is going to raise costs, and involve increased time, attention and effort.

Again, nothing could be further from the truth. Highly effective organisations run more smoothly, more predictably and with higher productivity and significantly lower costs. This is, for me, the essence of effectiveness.

How about you? What comes to mind when you hear the term “increased effectiveness”?

– Bob

Product Development Success

What constitutes “success” in the product development arena, and how might we quantify it, or even measure it?

What is the ultimate unit of measure for success?

Some folks say it’s “life cycle profit impact”. But it really isn’t. Nobody gives a hoot about profit (cf. Deming’s First Theorem). Nor do all but a few take a long term (whole life cycle) view of the products in their product portfolio.

In my experience, the ultimate unit of measure for success in product development is the wellbeing of the folks involved. In particular, the personal wellbeing of executives and senior managers with skin in the game. And to a much lesser extent, the personal wellbeing of the middle managers, developers, and customers (most often in that order).

Of course, nobody wants to talk about this, least of all the beneficiaries. So the measures of success remain undiscussable, and spurious proxy measures such as profit are introduced to lull the unwary and naive.

– Bob

Further Reading

Think Different. (2019). Your REAL Job. [online] Available at: https://flowchainsensei.wordpress.com/2019/11/11/your-real-job/ [Accessed 21 Jan. 2022].

What If #10 – Somebody Discovered the Solution

What if somebody discovered the solution to the vexing question of “how to consistently deliver software products successfully – e.g. reliably, effectively, on-time, with quality, and with controlled costs”?

How would the software community react? I posit it would be just like the reaction of the medical profession to the discoveries of Semmelweis circa 1847. i.e. Ridicule, taking offence, and rejection.

How would the lay (business) people across various industries react? I posit they would remain ignorant, or rail against the suggestion that they examine their perspective.

How would the discoverer react? I posit he or she would becoming increasingly frustrated and eventually suffer a nervous breakdown and maybe die or kill themselves.

– Bob

Other Posts In This Occasional Series

What If #1 – No Management

What If #2 – No Process

What If #3 – No Telling

What If #4 – No Answers

What If #5 – Continuous Improvement Is Useless

What If #6 – Agile Nirvana

What If #7 – No Work

What If #8 – Agile Never Happened

What If #9 – What if we helped folks learn how to think, rather than teach them what to think? (Quickie)

Seems like NOBODY in management or product consulting has heard the old adage:

Q: How do you build a great product?

A: Build a great team and they’ll build the great product for you.

Win Organisational Psychotherapy Book Bundles!

In my most recent book, “Quintessence”, I draw a blueprint for the quintessential software development organisation. It builds on the previous two books: 

I’d be super delighted to hear about your take on the following topic: 

What  does a quintessential software development organisation (or product development organisation) look like, feel like and work like – from your point of view?

Or put another way, if you have a picture of the ideal organisation you’d desperately want to work for, how do you imagine it to be?

The best (in my assessment) three entries will each receive a full three book Organisational Psychotherapy bundle, free, gratis, and for no charge (a $99.99 value).

There are extensive free samples of each of the books on the Leanpub pages (see links, above), in case you’d appreciate a “starter for ten”.

Please submit your entries before the 31 January 2022. I’ll be announcing the winners shortly after that closing date. Submissions via the comment section on this post, or more privately if you wish via email to: bob.marshall@fallingblossoms.com, please.

Thanks, and good luck with your entry!

– 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.files.wordpress.com/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].

It’s the system (the way the work works) that determines circa 95% of an individual’s performance in their job.

Are you still “managing the 5%” (through training, coaching, motivation, appraisals, etc.)?

#Deming

Compassion Makes For A Better Developer. Period.

I’m loving the book “Compassionomics” by Steve Trzeciak, Cory Booker and Anthony Mazzarelli. I’m finding oodles of research-based data and information of immense relevance to software development organisations, and to businesses generally. 

Not that research, science, and evidence is going to sway folks much if at all. Yet, for those already swayed, the information in the book might be useful. 

There’s a bunch of terms – terms widely in use in the medical business field – explained in the book. Here’s a brief introduction to some of them: 

Burnout

“Decades of rigorous research have identified three hallmarks of burnout: emotional exhaustion (being emotionally depleted or overextended), a lack of personal accomplishment (the feeling that one can’t really make a difference), and depersonalisation. Depersonalisation is the inability to make that personal connection.”

~ Trzeciak & Mazzarelli

Depersonalisation also results in reduction in empathy for patients, and in treatment with compassion.

Compassion Fatigue

Literally, running our of compassion for patients.

Adherence

In the field of medicine, adherence is defined as the extent to which patients are able to follow treatment recommendations from health care providers. Non-adherence is, of course, the opposite: patients patients not following treatment recommendations.

The most common example of non-adherence is when a patient is supposed to be taking prescribed medication but is not taking his or her pills. But non-adherence can be about much more than just not taking medication. It’s also a factor with other treatments, like patients with kidney failure who do not show up for scheduled dialysis treatments. Or when a physician recommends that a patient modifies a certain behaviour – like quitting smoking, losing weight, or exercising regularly – but that patient doesn’t follow through.

Compassion Satisfaction

Compassion satisfaction is the degree to which a person feels pleasure or satisfaction from their efforts to relieve others’ suffering. Aside: It’s this idea that informs the Antimatter Principle.

Compassion Fatigue

Compassion fatigue (emotional exhaustion, depersonalisation, and, in this case, also taking on stress from taking care of those that are stressed from being sick)

“A lack of compassion leads to increased workforce issues”

“A new field of research is suggesting that when organizations promote an ethic of compassion rather than a culture of stress, they may not only see a happier workplace but also an improved bottom line. Consider the important—but often overlooked—issue of workplace culture…Employees in positive moods are more willing to help peers and to provide customer service on their own accord…In doing so, they boost coworkers’ productivity levels and increase coworkers’ feeling of social connection, as well as their commitment to the workplace and their levels of engagement with their job. Given the costs of health care, employee turnover, and poor customer service, we can understand how compassion might very well have a positive impact not only on employee health and well-being but also on the overall financial success of a workplace.”

~ Dr. Emma Seppälä, “Why Compassion in Business Makes Sense”

Emotional Labour

Emotional labour is the management of one’s emotions (both one’s experienced emotions as well as one’s displayed emotions) to present a certain image.

For decades, researchers in management and organisational behaviour have been studying emotional labour by service workers across all types of service industries. For health care providers, emotional labour includes the expectation of compassionate behaviours toward patients, even if those providers aren’t actually feeling an emotional connection with the patient in that particular moment. (A word of caution here: Please resist the temptation to trivialise emotional labour as “faking it.” It goes much deeper than that…)

Neuroplasticity

Recent advances in neuroscience have overturned the long-held belief that the brain’s structure and function was essentially fixed throughout adulthood, in favour of neuroplasticity. Neuroplasticity refers to the human brain’s ability to form, reorganise and grow new synaptic connections, even through adulthood. 

Summary

Are you really telling me the all this research has no relevance to the software industry? That developers, etc., have no need of compassion? That compassion won’t make for a better developer? Tcha!

– Bob

Further Reading

Trzeciak, S., Booker, C. and Mazzarelli, A. (2019). Compassionomics: The Revolutionary Scientific Evidence that Caring Makes a Difference. Studer Group.

Getting Along

When all is said and done, all our artifices, all our strivings, all our efforts to organise work… it’s simply about figuring our how to get along (with each other). 

If we’re getting paid but not being productive, the payers will rankle and cavil, and they and we won’t get along. If we’re producing stuff that doesn’t meed the needs of our customers, they will feel frustrated and they and we won’t get along.  If we treat some folks like pariahs or cogs in our machine, they won’t feel valued or respected, and they and we won’t get along.

There’s really no more to work, and organisations, than getting along. In Rightshifted organisations, for example, such as the quintessential ones, folks simple get along better.

What does it take for us all to get along?

– Bob

%d bloggers like this: