Archive

Software development

An Overabundance of Planning

“The minimum you can get away with is always far less than you think you need.”

~ @FlowchainSensei

A Common Objection

“We’d be inundated if we attended to even a fraction of all the needs of all the Folks that Matter” is one common objection I regularly hear to the Antimatter Principle.

And yet, in most software development projects, the team is inundated with things to do, based on “the Plan” – regardless of whether that’s a big up-front plan, or an incremental plan (running backlog) assembled by degrees over time. A mountain of work (features, tasks, etc.) stretching out to the misty blue horizon, and back to the dawn of (project) time.

Research (see, for example, Capers Jones’ book “Assessment and Control of Software Risks”) highlights that much of what gets planned, and thus gets done, is pointless and proves unnecessary when (finally) made available to users. This reality is also reflected in the now highly controversial series of CHAOS reports from the Standish Group.

Specious

So, I regard the aforementioned objection as specious. Not intentionally so, most often. But specious never the less.

For me, “Attending to Folks Needs” means doing the least (responsibly) possible, and then seeing if the need (or a need) of the folks in question has been met. Most often those need(s) will not have been entirely met – and maybe not even partially – but the team then has the option to have another go – based on some solid information.

This approach has at least two benefits:

  • The person (customer, user, etc.) in question will feel that they matter, that their opinion counts, and that the team is focussed on them as a human being.
  • The team will have solid information upon which to validate or invalidate their earlier guesses (and yes, they will always be guesses until so validated).

At some point, it’s likely all the critical needs of all the Folks That Matter will have been met. And that point will like have arrived much earlier that with more traditional approaches. And with reduced costs and effort.

– Bob

Afterword

Some readers may argue that the above approach looks a lot like Agile. In practice (sic) I see enough differences to reject that comparison. For a deeper insight into why, may I invite you to consider #NoSoftware.

Artefact Driven Delivery

My preference when approaching solution delivery (I use that term in preference to software delivery, because #NoSoftware) has for the past 25 years centred on artefacts as opposed to tasks. I’m not going to retread here the arguments in favour of the artefact as the unit of progress. This post covers the use of artefacts in incremental development environments, and lists the core artefacts we use in our approach to solution delivery.

Incremental Delivery

Delaying work on implementing and delivering a solution until we have fully defined the requirements, designs, etc., for that solution magnifies the Cost of Delay, defers feedback significantly, and inflates other risks too. Yet we don’t want to skip having clear requirements and designs, either.

The approach we adopted starting circa 1994 is to establish a set of standard artefacts, at the outset of work on each new solution. From Day One, these artefacts will be empty scaffolds, based on standard templates, each artefact being elaborated just-in-time, immediately in advance of their contents being needed for implementation and delivery purposes.

In this way, we avoid B*UF (e.g. Big Design Up Front, Big Requirements Up Front, etc.) and the delays and risks associated with a Big Bang approach.

Standard Artefacts

The following is a list of all the standard artefacts we create on Day One of the inception of each new solution on which we embark. Note that each artefact is based on a standard template, with, from the outset, little or no solution-specific content (i.e. empty).

  • 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 aka QQOs
  • Critical Success Factors
  • Feature Schedule
  • Quality Plan
  • Test Plan
  • Change Control
  • Cycle Plans
  • Cycle Reviews

Artefacts and Deliverables

We share some or all of the above artefacts with our clients (the folks on whose behalf we are developing solutions) continually, and at their request. These artefacts are available for sharing throughout the duration of the development. And serve as a running history of the endeavour, too. The deliverables of any solution (code, data, policies, documentation, configs, databases, etc.) augment these standard, evolving artefacts. Typically, a set of deliverables will fall out of the work according to some cadence or rhythm (for example, weekly or every two weeks).

Javelin

For a fuller (if rather dated) explanation of each particular artefact (some now carry slightly different names), see the Javelin white paper.

In a following post I’ll be showing how you might insinuate the Antimatter Principle into your existing approach to developing solutions, using the Artefact Driven Delivery approach.

– Bob

Management Monstrosities

Michele Sollecito (@sollecitom) kindly responded to a recent tweet of mine with the following question: 

“Why do so many well intentioned founders and companies end up creating management monstrosities?”

The “management monstrosities” referred-to are the (dysfunctional, ineffective) tech organisations we find just about everywhere these days. My work on #Rightshifting illustrates just how ineffective is the average tech company, compared with how effective they could be (and Rightshifted outliers are known to be).

But Michele’s question is: “Why?”

Over twenty years and more, I’ve seen dozens of organisations up close and personal.  In none of these organisations have the folks in charge appreciated the difference between collaborative knowledge work (Cf. Drucker) and other categories of work. We can call this a Category Error.

Category Error

Collaborative knowledge work is NOT like:

  • Factory Work
  • Manufacturing
  • Office work
  • Service work (e.g. Call centres, Help desks, etc.)
  • Individual knowledge work

Collaborative knowledge work is in a distinct category all its own, and demands a fundamentally different approach to the way the work works, if we’re to see effective working.

Attempting to manage collaborative knowledge work by means common to other categories of work will inevitably lead to ineffectiveness, and all the monstrous consequences that follow from that.

Assumptions and Beliefs

Put another way, organisations import or retread the assumptions and beliefs of the category of work they believe applies to software development. As the category they assign is (almost) never “collaborative knowledge work”, the prevailing assumptions and beliefs are never aligned to effective working.

You may now be asking “Why is the category they assign (almost) never ‘collaborative knowledge work’?”. I’ll leave that question for another post (if there’s any demand for such a post).

– Bob

Cost of Focus Revisited

[Recent conversations suggest that my post on Cost of Focus failed to explain the idea clearly enough for readers to grasp easily or quickly. As, for me at least, it’s a simple idea, I thought I’d summarise it in brief with a new post (this one).]

Cost of Focus

Let’s start with a definition in a nutshell:

Cost of Focus is the cost incurred when we fail to include key stakeholders* in our deliberations**.

* I generally refer to these folks, collectively, as The Folks That Matter™.
** By deliberations, I have in mind what old-school folks call “requirements capture” or “requirements analysis”, and what I, nowadays, refer to as “needs investigation”.

Put another way:

Cost of Focus is a way of communicating the impact – on the outcomes we hope to achieve – arising from excluding or including specific folks and their needs.

Note: I could have chosen the name “Cost of Flawed Focus” (the cost of focussing on less relevant stakeholders and less relevant requirements), but this seemed a little less snappy than “Cost of Focus”.

Typically, the costs in question accrue from rejection of part or all of the delivered project / system / product / software application by one or more key parties (such as users) whose needs have not been adequately addressed  – and these costs can be massive. In any number of cases, whole systems have had to be abandoned because one or more key stakeholder groups have refused to use the new system. And even when not totally abandoned, oftentimes major costs have accrued from the delays and extra work required to remediate the original errors of focus. (See also Cost of Focus’ kissing cousin – Cost of Delay).

The Folks That Matter™

[The following excerpt first appeared in my blog post The Folks That Matter™. I repeat it here for the convenience of the reader:]

Cost of Focus

Don Reinertsen states that the Cost of Delay – the financial or economic cost of delaying a given feature by prioritising another – is rarely considered in most organisations. Put another way, the way in which delivery priorities are selected and adjusted, the frequency and means of such adjustments, etc., are rarely discussed, and rarely even discussable.

I propose that Cost of Delay is a subset of the wider question stated above, i.e. the question of Cost of Focus.

By definition, we are failing to meet some folks’ needs when we choose to or otherwise exclude certain folks with their particular needs from the set of The Folks That Matter™.

Maybe those excluded folks and their needs are indeed irrelevant, or their exclusion has little impact – financial or otherwise – on the success of our endeavour. But maybe, contrariwise, some of those excluded needs are in fact critical to our “success”. How would we know? The arguments for Cost of Focus are much the same as for its golden child, Cost of Delay.

FWIW, I’ve seen countless projects stumble and “fail” because they inadvertently omitted, or chose to omit, some crucial folks and their needs from the their list of The Folks That Matter™. Get Cost of Delay wrong (prioritise less valuable features), and we lose some money. Sometime a little, sometime a lot. Get Cost of Focus wrong, and we more often lose big time. Cost of Focus often has a much more binary, black-and-white impact.

What is Cost of Focus?

Cost of Focus is a way of communicating the impact – on the outcomes we hope to achieve – arising from excluding or including specific folks and their needs. More formally, it is the partial derivative of the total expected value with respect to whose needs we focus on.

“Cost of Delay is the golden key that unlocks many doors. It has an astonishing power to totally transform the mind-set of a development organisation.”

– Donald G. Reinertsen

Similarly, I’d say that unless and until we have a handle on Cost of Focus, the golden key of Cost Of Delay remains firmly beyond our grasp.

Put another way, until we have a means for deciding to whose needs to attend, the particular order in which we attend to those needs (cf. priority, Cost of Delay) is moot.

– Bob

Further Reading

Cost of Focus ~ Think Different blog post
The Folks That Matter™ ~ Think Different blog post
Cost of Delay ~ Wikipedia entry

Some Familiar Experiences

[Note: I regard this post as unfinished – I’m publishing it now in the hope that some kind readers will help me in bringing it to something nearer completion. Also, you might like to check in now and again for possible updates.]

A Conversation

Here’s a transcript of a conversation that didn’t take place, but could have, in the vicinity of Reading, England, circa 1999.

Sam: Thanks for allowing me to get some insights into Familiar and what makes it different from other software houses.

Bob: Thanks for showing an interest. We feel the UK software industry would serve society better if more folks had some exposure to what we’re doing here, and maybe take on board some of the principles that have guided us so far.

Sam: I’d like to start with the one thing that intrigues me most. The way you set salaries here. I’ve heard you allow people to set their own salaries? Is that true? Can you explain why you do that?

Bob: Surely. When we set up Familiar, some three years ago now, we all decided we wanted a company that felt more like a family, both for the folks working in the company, and for all the other folks involved – our suppliers and customers, for example. That’s reflected in one aspect of the name “Familiar”, of course (I won’t go into the other aspects of the name, just now). At the time, I was reading the book “Families and How To Survive Them” by John Cleese and Robin Skynner. That book led me to Eric Berne’s work on Transactional Analysis. Berne’s work got me thinking about building a community where Adult-Adult interactions and relationships were the norm.

Sam: So how does having folks set their own salaries play into that idea?

Bob: Well, our approach to salaries – and the same with equipment, working times, locations and the nature of the relationship between the community and the individual – is to have people choose for themselves. If we want folks to behave more often like adults, it makes sense to us to treat them like adults. Folks capable of making their own decisions about the things that matter to them, and to the community as a whole. Moreover, who is at all equipped to decide what salary, etc., suits their needs – other than each individual?

Sam: That sounds really out there. How do people find it?

Bob: It’s true it’s not without its challenges. Firstly, people just starting with us often haven’t thought very much about their commercial value. In other words, at what level they might set their salaries. What might be “fair”. And if someone asks for any given salary, cap-in-hand like, I push back. As far as I’m concerned – and speaking on behalf of the community, too – it’s not a negotiation. Someone announces their intent to bill at a certain rate, or get paid a certain monthly stipend, and that’s what happens. I see it as a positive, all round – for them, others, and the community as a whole – for someone to think about what they charge. You might say “what they’re worth” – but that’s too crass a phrase for me. And then there are other challenges, too.

Sam: Such as?

Bob: Folks billing or getting paid too little. Strange as it seems, our overall staff costs are rather lower than we expected for a software house such as ours. Nobody’s complaining, really. But I’d like to see folks reap greater financial rewards, not just the – less tangible but no less important – rewards of community, fellowship and interesting projects. Americans call wages “compensation” – I guess folks here don’t have to receive as much compensating for the crap as in other companies.

Sam: So you don’t get anyone “trying it on”?

Bob: Not to date. We subscribe to McGregor’s Theory-Y, which invites us to believe that employees are internally – or ‘intrinsically’ – motivated, enjoy their job, and work to better themselves without a direct (financial) reward in return. We’ve found this to be a valid assumption in our case. We strive to make Familiar a place when folks love to get together and do interesting, meaningful things. As our Credo states: “Familiar exists for folks to come together and explore what ‘fulfilment’ means for each one, individually”.

Sam: And as for the other things folks can choose? You mentioned equipment, locations, working times, and the nature of the relationship with the community?

Bob: Again, we want folks to feel like we regard them as adults, with the capacity to choose what’s best and most suitable for them, and thus for the (extended) community too. So everyone gets to choose their development computer(s), monitors, keyboards, etc., and development platform (operating system, tools, languages and such). Some folks have their own kit, and for others Familiar buys some or all of the kit. Some interoperability considerations apply, of course, and the customer often has some requirements relating to the operational/production environment. Project teams organise themselves to factor all this into the mix as part of their development process.

Sam: And locations?

Bob: Everyone works where they feel most comfortable, convenient or productive. Different issues affect different people. And folks are invited to vary their location as they see fit – and as suggested by the nature of the task they’re involved with at a given hour or on a given day. We have our office here, of course, with the public cafeteria, bookable meeting rooms, and our private community office space divided into bullpen, library/lounge with couches, a number of personal offices and the kitchenette. But folks work from home – and each others’ homes – as often as not. We also make a point of getting out as a group, both for meals and drinks in local restaurants and pubs, and for longer weekends away at comfy hotels. One chap who would otherwise have a long commute has a satellite office nearer to his home location. Again, “everybody’s different” – and capable of making their own choices.

Sam: Working times and the relationship with the company/community?

Bob: Folks work the hours that suit them, with the only proviso that the clients’ schedules get consideration. We have some early birds, some late birds, and some bird-of-a-feather (folks who like to regularly pair or work in sub-groups). The latter means they coordinate (self-organise) their schedules and locations, to some extent. As for relationships with the community, I’m talking about what some other companies might describe as the “contractual relationship”. We have some hour- and day-rate “contractors”. Some weekly paid and monthly paid “employees”, and a couple of folks – like myself – whose relationship falls outside those categories. And while we’re talking about pay, I guess I could mention the bonuses. We don’t have any formal bonus scheme as such, but when a particular project goes well, folks get together to consider the costs and revenues and decide if a team bonus is appropriate and what level and split would suit.

Sam: Would you do anything different if you found yourself involved in a different community in the future?

Bob: Nothing significantly different. Excepting that circumstances prevailing when we started Familiar allowed us the opportunity to trial these “wacky” ideas in practice. Such circumstances may not present themselves next time around. Folks have to be open to the ideas of doing things differently, or I suspect a similar scenario might never even get off the ground.

Sam: Do you have any advice for others thinking about building this kind of environment for their businesses?

Bob: I hate giving advice – I find it rarely followed. But one thing I would say – don’t underestimate the time needed for, and the value of, supporting folks who might feel uneasy from time to time about the choices they’re enabled to make. I’ve put in much time supporting people here when the way forward has seems unclear for them personally. But I feel it’s never been enough support, and I always want us to do more. And one word of caution: Time. It’s taken us three years of daily practice to even begin to understand how these ideas all fit together. The benefits are definitely there, we’re demonstrated that, but few companies seem to have a longer-term view. Along the way, we have discovered some useful shortcuts.

Sam: Thanks, Bob, for sharing your experiences with me, and my readers.

Bob: My thanks to you also, Samantha. It’s been fun.

[End]

– Bob

Further Reading

The Starting of Familiar ~ Think Different blog post

#NoSoftware

I wrote a post some time ago about No Hashtags (hashtags on e.g. Twitter which use the #No… prefix). My tweets occasionally mention various #No… hashtags, including #NoEstimates, #NoTesting and #NoSoftware.

I’m thinking it’s about time I delved just a little into the #NoSoftware hashtag. Like most of my posts on Think Different, this one will be brief. #NoSoftware is a deep subject, upon which I could write a whole book, had I but the inclination (or demand).

To whet your appetite, and illustrate the possibilities of #NoSoftware, we need look no further than the story of Portsmouth City Council housing repairs, where an existing, expensive and inflexible IT system was switched off, replaced with manual controls, and only later some limited software support reintroduced, once the needs of all the Folks That Mattered had been fully understood and catered to.

Payback

Let’s start with the payback of #NoSoftware.

As Steve Jobs wrote:

“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

A pretty clear alignment with #NoSoftware (yes, I’m coming to that presently) wouldn’t you say?

Let’s just dissect that statement:

Eliminating lines of code we have to write

We’re not talking about writing denser code – cramming more functionality into fewer lines. Fewer lines of code means we’re done quicker, having spent less time, effort and money on the writing of code. That’s a saving in and of itself.

Never breaks

So the lines of code we don’t write means we don’t have to worry about their quality (no matter whether you use defect prevention or testing as your go-to strategy in that arena). More time, effort and money saved.

Doesn’t need maintenance

By maintenance here, I’m thinking about changes to the code occasioned by the changing needs over time of the Folks That Matter, or changes necessitated by changing technical environments. I’m not dwelling on remediation efforts (bug fixes to production code).

More Payback

But the payback of #NoSoftware doesn’t stop with the above aspects. In the bigger picture, it’s not just about writing fewer lines of code. It’s about eschewing software-based solutions more or less entirely in favour of considering the alternatives. More payback includes:

Happier customers

It’s an old saw that “folks don’t want an 8mm drill, they want an 8mm hole”. Similarly, folks almost universally don’t want software, they’re looking to have their needs met. And software for many of these folks has too many negative impacts to be their preferred option. Software is generally written to save (suppliers) costs, not to improve customers’ satisfaction. Most people hugely prefer to interact with other human beings, rather than a computer controlled by – generally lame and inflexible – software.

Opening the Door to Changing Thinking

Software systems as generally conceived, ordered and delivered institutionalise – or “lock-in” – the existing collective mindset. Once installed and paid for, the “sunk cost” fallacy undermines any possibility of changing the existing set of assumptions and beliefs about how the works works. In the vast majority of cases the software system locks the organisation even more tightly into its existing Command & Control (a.k.a. Analytic Mindset) ways of working.

#NoSoftware – Definition

When I use the #NoSoftware hashtag, I’m inviting folks to think again about what, often, are near-autonomic responses. In this case, the System One (cf Kahneman) response – “fast, instinctive, emotional, stereotypical, unconscious and automatic” – when faced with some needs of some Folks that Matter, to satisfy those needs with a software-based solution.

I guess some folks assume that I’m advocating zero software. A kind of Luddites’ heaven. This is not my position. In using the #NoSoftware hashtag, I’m basically saying

“Under some circumstances, maybe there are other, more effective means to meet folks’ needs than the default assumption/strategy that we have to do so via software”.

“How about we think about, talk about, and consider those various circumstances, and means?”

In this way, the #NoSoftware hashtag is a metaphor for

“Would you be willing to think again, and maybe join the search for more effective, relevant or alternative means of meeting the needs in question?”

Example

Some years past, I was working with a company that offered a software product to the corporate market. The product had been in the market for some years, and it was clear that one of the blockers to market penetration was the complexity of the problem and the challenges corporate customers faced in dealing with that complexity. The company chose to build more and more software into their product to help their customers handle the complexity. No one ever discussed the options of offering a consulting service and/or a managed service, using human expertise, to replace or augment their software product. Consequences were, customers remained challenged, and the company’s revenues suffered.

Blockers

As Upton Sinclair’s Dictum tells us:

“It is difficult to get a man to understand something when his salary depends on his not understanding it.”

~ Upton Sinclair

How much more difficult, then, when it’s the revenues of a whole industry we’re calling into question. If the software industry changed tack and stopped writing software, what then? Financial ruin? World collapse?

There’s a multitude of smart people who currently waste much of their time – and lives – writing and delivering solutions to folks’ needs in the form of software. I suggest that to have this multitude refocus and retrain themselves to consider, and deliver, other forms of solution – solutions with less or no software – would make the world a better place for all the Folks that Matter. And “better”, as far as customers are concerned, would mean increased demand and more revenues for savvy suppliers.

Uptake

Like many of my invitations, I find #NoSoftware has few people willing to consider it as an alternative strategy to the status quo of just getting on with writing (more and more) software. I guess this signifies the general learned helplessness, and lack of engagement, autonomy and mastery, we find in most workplaces and employees today. So be it.

– Bob

Further Reading

Why Doctors Hate Their Computers – Atul Gawande
Forget your people – real leaders act on the system ~ John Seddon
Dangerous Enthusiasms: E-government, Computer Failure and Information Systems Development ~ Robin Gauld, Shaun Goldfinch

Why Reason When Faith is So Much More Comfortable?

I’ve become very bored trying to explain why Agile – even when practised as the Snowbird Gods intended – is a dead-end and why we might choose to bark up a different tree for progress in improving the effectiveness of software development organisations.

Firstly. No one seems at all interested in “improving the effectiveness of software development organisations”. Yes, there does seem to be some interest in being seen to be doing something about improving the effectiveness of software development organisations. Hence SAFe, DAD, LeSS – and Agile itself. None of these approaches do anything about actually improving the effectiveness of software development organisations, of course. But that’s not the point. Improvement *theatre* wins the day in just about every case. Irrespective of practices done “right”, or more often, done “in name only” (Cf AINO).

To actually do anything about improving the effectiveness of software development organisations requires we remove some fundamental system constraints, including:

  • Optimising parts of the organisation in isolation
  • Pursuit of specialism (vs generalists)
  • Control (as in Command & Control)
  • Annual budgeting
  • Extrinsic motivation
  • Ignorance of the special needs/realities of collaborative knowledge work
  • Separation of decision-making from the work
  • Decision-makers’ ignorance of and indifference to customers’ needs
  • Seeing performance as consequent on the efforts of individuals and “talent”
  • Discounting the paramountcy of social interactions and inter-personal relationships

And that ain’t gonna happen.

Second, improving the effectiveness of software development organisations kinda misses the point. In that software development is part of the problem. Making it more effective is just – as Ackoff would say – doing more wrong things righter.

Instead, a focus on meeting folks’ needs, or at least, as a minimum, attending to their needs, would serve our search for effectives rather better. And that generally requires less software, and placing software development last in terms of priority, way before understanding customers’ needs ( (and more generally the needs of the Folks’ That Matter).

Given that the software industry’s revenues are contingent on producing software (see: Upton Sinclair’s Dictum) that ain’t gonna happen, either.

Third, if we regard improving the effectiveness of software development organisations as our aim, and limit our ambitions to that part of the organisation concerned directly with software development (i.e. the IT department or the Product Development department) then, at best, we’ll only ever see a local optimisation. Which as Ackoff tells us, only makes matters (i.e. the effectiveness of the whole organisation) *worse*. To improve organisational effectiveness (not to mention supply chain effectiveness, customers’ effectiveness) requires us to consider the organisation as a system, and focus on the systemic relationships between the parts, rather than on the parts taken separately. And given that systems thinking has failed to gain much traction in over fifty years of trying, THAT ain’t gonna happen either.

I’ll just leave this here:

“If you could reason with Agile people, there would be no Agile people.”

It all looks a bit bleak, doesn’t it? Another method isn’t going to help much, either. Unless it addresses the three points outline above. As a minimum.

That’s why I have been for some years inviting folks to consider Organisational Psychotherapy as a way forward.

But reason, rationality, and a cold hard look at reality and the shortcoming of the status quo ain’t gonna happen. Until organisations see a need for that to happen.

– Bob

Damn Outcomes!

It seems in vogue to extol the praises of “outcomes” when discussing e.g. software and product development. Setting aside the challenges of defining what we might mean by “outcomes” (I dislike getting into rabbit-hole discussions of semantics), there’s one key aspect of this debate that seems to escape folks’ attention. W Edwards Deming nailed it decades ago with his First Theorem:

“Nobody gives a hoot about profits.”

Even so, Deming said little about what folks (managers, in his frame) DO give a hoot about. We can turn to Russell L. Ackoff for an insight into that:

“Executives’ actions make sense [only] if you look at them as taken in order to maximise the executive’s well being.”

As Dr. Ackoff says, a secondary focus on profits is just the cost executives must pay in order to maximize their rewards. The actions taken would be different if the well being of the organization was primary and the well being of senior executives subservient to that aim.

Outcomes

So, to outcomes. The outcomes that delight will be those that maximise the executives’ (and other folks’) well being. When developing a piece of software, how often do the specifics of the well being of the Folks That Matter get discussed? Indeed, is the subject even discussable? Or is it taboo? In your organisation?

How unsurprising then, that software as delivered is so often lacklustre and uninspiring. That it fails to address the core issues of the well being of the Folks That Matter? That it’s the wrong software.

As a developer or team, do you ever afford your customers (a.k.a. the Folks That Matter) the opportunity to talk about their well being? And how what you’re doing for them might contribute to that well being?

So, might I invite you to stop talking about specious and illusory “outcomes”. And start asking the difficult questions of your customers (and yourselves)?

Here’s a possible opener:

“Would you be willing to discuss what it is you need for your own well being?”

– Bob

Further Reading

Nobody Gives a Hoot About Profit ~ The W. Edwards Deming Institute Blog post
Agile Competency Is A Crock ~ Think Different blog post

The Aspiration Gap

Some years ago I wrote a post entitled “Delivering Software is Easy“. As a postscript I included a chart illustrating where all the jobs are in the software / tech industries, compared to the organisations (and jobs) that folks would like to work in. It’s probably overdue to add a little more explanations to that chart.

Here’s the chart, repeated from that earlier post for ease of reference:

Chart illustrating the gap between available jobs and jobs folks would like to have.

The blue curve is the standard Rightshifting curve, explained in several of my posts over the years – for example “Rightshifting in a Nutshell“.

The green curve is the topic of this post.

The Green Curve

The green curve illustrates the distribution of jobs that e.g. developers, testers, coaches, managers, etc. would like to have. In other words, jobs that are most likely to best meet their needs (different folks have different needs, of course).

Down around the horizontal zero index position (way over to the left), some folks might like to work in these (Adhoc) organisations, for the freedom (and autonomy) they offer (some Adhoc organisations can be very laissez-faire). These jobs are no so desirable, though, for the raft of dysfunctions present in Adhoc organisations generally (lack of things like structure, discipline, focus, competence, and so on).

The green curve moves to a minimum around the 1.0 index position. Jobs here are the least desirable, coinciding as they do with the maximum number of Analytic organisations (median peak of the blue curve). Very few indeed are the folks that enjoy working for these kinds of organisations, with their extrinsic (imposed) discipline, Theory-X approach to staff relations and motivations, strict management hierarchies, disconnected silos, poor sense of purpose, institutionalised violence, and all the other trappings of the Analytic mindset. Note that this is where almost all the jobs are today, though. No wonder there’s a raging epidemic of disengagement across the vast swathe of such organisations.

The green curve then begins to rise from its minimum, to reach a maximum (peak) coinciding with jobs in those organisations having a “Mature Synergistic” mindset (circa horizontal index of 2.8 to 3). These are great places to work for most folks, although due to the very limited number of such organisations (and thus jobs), few people will ever get to experience the joys of autonomy, support for mastery, strong shared common purpose, intrinsic motivation, a predominantly Theory-Y approach to staff relations, minimal hierarchy, and so on.

Finally (past horizontal index 3.0) the green curve begins to fall again, mainly because working in Chaordic organisations can be disconcerting, scary (although in a good way), and is so far from most folks’ common work experiences and mental image of a “job” that despite the attractions, it’s definitely not everyone’s cup off tea.

Summary

The (vertical) gap at any point along the horizontal axis signifies the aspiration gap: the gap between the number of jobs available (blue curve) and the level of demand for those jobs (green curve) – i.e. the kind of jobs folks aspire to.

If you’re running an organisation, where would you need it to be (on the horizontal axis) to best attract the talent you want?

– Bob

Footnote

For explanations of Adhoc, Analytic, Synergistic and Chaordic mindsets, see e.g. the Marshall Model.

 

Obduracy

I tweeted recently:

“The things organisations have to do to make software development successful are well known. And equally well known is the fact that organisations will absolutely not do these things.”

Here’s a table comparing some of the things we know are necessary for success, alongside the things organisations do instead.

Necessary for Success What Organisations Do Instead
Teamwork Heroic individualism
Primacy of people skills Primacy of tech skills
Self-organisation, self-management Managers managing the work(ers)
Systems view of the organisation Partition the organisation into discrete silos
Manage the organisation/system as an integral whole Manage each silo separately
Use systemic measures to steer by Use silo-local measures to steer by 
Relationships matter most (quality of the social dynamic) The code’s the thing (e.g. velocity)
Effectiveness (do the right things) Efficiency (do things right)
Zero defects (quality is free) (defect prevention) Testing and inspections
The workers own the way the work works Mandated processes and methods (management owns the way the work works)
Workers are generalists Workers are specialists 
Trust Rules, policies
Theory Y Theory X
Intrinsic motivation, discipline Extrinsic (imposed) motivation, discipline 
Everyone’s needs matter (everyone’s a customer and a supplier) Only the bosses’ needs matter (your boss is your only customer)
Explicit requirements, negotiated and renegotiated with each customer, just in time No explicit requirements, or Big Requirements Up Front
Incremental delivery against the needs of all the Folks That Matter, short feedback loops  Big Bang delivery, some or all constituencies overlooked or ignored, long or no feedback loops
Kaikaku and kaizen, to serve business goals Kaizen only, by rote
No estimates, flexible schedules Estimates, fixed schedules
Smooth flow (a regular cadence of repeatably and predictably meeting folks’ needs) “Lumpy” or constipated flow 
Work is collaborative knowledge work Work is work
People bring their whole selves to work People limit themselves to their “work face”.

Do you have any more entries for this table? I’d love to hear from you.

– Bob

The Big Shift

Let’s get real for a moment. Why would ANYONE set about disrupting the fundamental beliefs and assumptions of their whole organisation just to make their software and product development more effective?

It’s not for the sake of increased profit – Deming’s First Theorem states:

“Nobody gives a hoot about profits”.

If we believe Russell Ackoff, executives’ motivation primarily stems from maximising their own personal well being a.k.a. their own quality of work life.

Is There a Connection?

Is there any connection between increased software and product development effectiveness, and increased quality of work life for executives? Between the needs of ALL the Folks That Matter and the smaller subset of those Folks That Matter that we label “executives”? Absent such a connection, it seems unrealistic (understatement!) to expect executives to diminish their own quality of work life for little or no gain (to them personally).

Note: Goldratt suggests that for the idea of effectiveness to gain traction, it’s necessary for the executives of an organisation to build a True Consensus – a jointly agreed and shared action plan for change (shift).

Is Disruption Avoidable?

So, the question becomes:

Can we see major improvements in the effectiveness (performance, cost, quality, predictability, etc.) of our organisation, without disrupting the fundamental beliefs and assumptions of our whole organisation?

My studies and experiences both suggest the answer is “No”. That collaborative knowledge work (as in software and product development) is sufficiently different from the forms of work for which (Analytic-minded) organisations have been built as to necessitate a fundamentally different set of beliefs and assumptions about how work must work (the Synergistic memeplex). If the work is to be effective, that is.

In support of this assertion I cite the widely reported failure rates in Agile adoptions (greater than 80%), Lean Manufacturing transformations (at least 90%) and in Digital Transformations (at least 95%).

I’d love to hear your viewpoint.

– Bob

Further Reading

Organisational Cognitive Dissonance ~ Think Different blog post

Something’s Gotta Give

 

“The things businesses have to do to make software development successful are well known. And equally well known is the fact that businesses will absolutely not do these things.”

This reality puts us in a bind. We find ourselves in a position where we have to trade off successful development against conforming to organisational norms. We can have one – or the other. It’s not a binary trade-off, we can for example relax some norms and gain some (small) improvements in success. But by and large it’s a zero sum game. At least from the perspective of those folks that find value in everyone conforming to preexisting norms.

I don’t think many business folks realise this trade-off exists. Almost all the business folks I have met over the years seem unaware that their norms are what’s holding back their success in software (and product) development. I put this down to the absence of any real understanding of the fundamentally different nature of collaborative knowledge work (different to their experiences and assumptions).

Some of the Things

By way of illustration, here’s just a few of the things that are necessary for successful software (and product) development, that businesses just won’t do:

De-stressing

Removing stressors (things that create distress) from the workplace. These things include: job insecurity; being directed and controlled; being told where, when and how to work; etc..

Stressors serve to negatively impact cognitive function (amongst other things).

Trusting

Placing trust in the folks actually doing the work. We might refer to this a a Theory-Y posture.

Experimenting

Finding out through disciplined and systematic experimentation what works and what doesn’t. See: the Toyota Improvement Kata.

Being Human

Embracing what it means to be human; seeing employees as infinitely different, fully-rounded human beings with a broad range emotions, needs and foibles (as opposed to e.g. interchangeable cogs in a machine).

Intrinsic Discipline

Relying on intrinsic motivation to encourage and support a disciplined approach to work.

Meaningful Dialogue

Talking about what’s happening, the common purpose, and what the problems are.

Eschewing Numbers

Realising the limitations with numbers, dashboards, KPIs and the like and finding other ways to know whether things are moving in the “right direction”.

Prioritising Interpersonal Relationships

In collaborative knowledge work (especially teamwork), it’s the quality of the interpersonal relationships that’s by far the greatest factor in success.

Summary

If your organisation needs to see more success in its software (and product) development efforts, then something’s gotta give. Specifically, some of its prevailing norms, assumption and beliefs have gotta give. And given that these norms come as a self-reinforcing memeplex (a.k.a. the Analytic Mindset), a piecemeal approach is highly unlikely to afford much in the way of progress.

– Bob

Red Lines

There’s been a lot of talk about Theresa May’s “Red Lines” in the media recently.

Every organisation I’ve ever known has had their own Red Lines – ideas, principles, practices and policies which are deemed unacceptable, beyond the pale. Many of these latter would make the organisation markedly more effective, efficient or profitable, yet are ruled out.

Here’s a list of such ideas, in roughly increasing order of benefit and unacceptability both:

Transparency of salaries
Attending to folks’ needs
Nonviolence
Restorative justice (vs Retributive justice)
Self-organising / self-managing teams
No estimates
No projects
No tools
No software
Defect prevention (ZeeDee) approach to Quality (vs Testing / Inspection)
Employees choosing their own tools, languages and development hardware
Employees designing / owning their own physical workspace(s)
(colour schemes, lighting, furniture, floor plans, drinks machines, games etc.) 
Employees choosing their own ways of working (methods, processes)
Organising to optimise Flow (vs costs)
Employees choosing their own working locations (office, cafe, remote, etc.)
Employees choosing their own working hours (incl. hours per day / week)
Employees forming their own teams
Employees guiding their own training and career, skills development
Employees hiring their own peers (and coaches)
Paramountcy of interpersonal relationships and social skills (vs tech skills)
Organisational Psychotherapy
Teams appointing their direct managers
Teams appointing their senior managers
“Open book” financials
Employees choosing their own salaries and terms of employment
Teams awarding themselves their own bonuses
No managers (alternatives to control hierarchies)
Fellowship (No positional leadership)
Do nothing that is not play

Where does your organisation draw its red lines – and how much more effective could it be if it redrew them?

– Bob

 

Standard Work and Collaboration

[Tl;Dr: Ad-hoc and impromptu collaboration is a signal – that our standard work is incomplete or insufficient, and that we don’t understand as much about what we’re doing and how, as we’d like to think.]

Standard Work

Standard work (also known as Standardized Work) is an operational definition of how the work works today. Best written and maintained (studied, updated) by the folks actually doing the work. Toyota defines Standard Work as ”the steps one needs to walk in order to complete a process”. Mike Rother defines Standard Work as the “Target Condition” in the Improvement Kata. This seems to me to make some sense.

“There is something called standard work, but standards should be changed constantly.”

~ Taiichi Ohno, Workplace Management

5W+1H

In slightly more detail: “Standardized work answers the 5W+1H of a process – the who, what, when, where, why, and how. Who operates the process, and how many people does it take? What does the final product look like, what are the quality check points, what are the tools required to complete the job? When is a part completed and ready for the next step (how long should the cycle time and takt time be)? Where is this process completed and what does this location look like (standardized work cell, point of use storage of tools, etc)? Why is this step necessary or value-adding, or why is this a quality check point?”

“When there is no standard [work], there is no Kaizen (continual improvement).”

~ Taiichi Ohno

In other words, when a process is performed unsystematically in different ways, then:

  1. There can be no basis for comparison (before/after)
  2. One cannot objectively tell if there was a difference or change
  3. No improvement is possible in regards to Time, Quality, Quantity, Cost, etc.

Collaboration is Waste

So, where does collaboration come into the picture? If the standard work specifies “collaborate here” (with 5W+1H or an operation definition for the collaboration) for a particular step, then all is fine and dandy.

But often, in software development particularly, there is no standard work, or the standard work lacks the detail which might suggest the 5W+1H of the collaboration. Exceptions which come to mind are: the daily standup (Scrum), sprint planning (Scrum) and sprint retrospectives (Scrum) (i.e. the various Scrum ceremonies – for which teams rapidly find their own work standards or de facto operational definitions).

Consequently, collaboration in software development is most often ad-hoc. Someone might run into a problem or challenge, and ask a colleague e.g. “Hey, can you help me with this?” or “Can we pair on this for half an hour?” or “Let’s get together and figure out what to do here”.

If we had clearly defined standard work, the specifics of what to do and who to call on when a problem arises would already be defined. Without such standard work, the coordination (set-up, figuring-out) of the necessary collaboration is waste, and interrupts the flow (both of value, and in the Mihaly Csikszentmihalyi sense of the word).

Do I hear you rail against this idea? Do you believe it’s impossible to foresee where and when collaboration might be necessary? Do you enjoy collaborating so much that you’re prepared to dismiss its negatives? May I put it to you that in such circumstances, you don’t actually know what y’all are doing? That you have little or no clear idea how to get from the start of sprint (or longer term) to the end, to the delivery of value? That you’re making much of it (“the way the work works”) up as y’all go along?

“…this model of ‘standards’ as something for compliance is a cancer that is holding us back in our quest to establish a new level of understanding around what ‘continuous improvement’ really means.”

~ Mark Rosenthal

The Bottom Line

This may all seem rather esoteric. How much can it matter whether collaboration costs us a few dollars or hours? For me, ad-hoc and impromptu collaboration is a signal – that our standard work is incomplete or insufficient, and that we don’t understand as much about what we’re doing and how, as we’d like to think.

Does it matter? I leave that to y’all to decide.

– Bob

Further Reading

What Is Standardized Work (And What Is It Not)? ~ LeanBlitz article
Mike Rother: Time to Retire the Wedge ~ Mark Rosenthal

 

Congruence

What if the last twenty years has been another classic example of software developers solving the wrong problem?♥

What if “agility” was never the issue as far as business was and is concerned? What if business agility is NOT the most useful response to, or strategy for, life in a VUCA world?

We hear so much about the need for agility. It’s now a given, an unchallenged assumption. Maybe even an undiscussable assumption? Well, I’m challenging it. And in the spirit of this blog – always having an alternative to offer – I propose congruence as a more useful response to the challenges of a VUCA business environment.

Agility: the power of moving quickly and easily; nimbleness.

Congruence: Similarity between self-image and actual experience.

Carl Rogers stated that the personality is like a triangle made up of the real [or actual] self, the perceived self, and ideal self. According to Rogers, when there is a good fit between all three components, the person has congruence. This is a healthy state of being and helps people continue to progress toward self-actualisation.

Applied to organisations, we can say that an organisation is made up of the real [or actual] organisation, the organisation as it perceives itself, and its ideal self. When there is a good fit between all three components, the organisation has congruence. This is a healthy state of being and helps the organisation progress toward being all it can be.

Without congruence, organisations won’t know what to do with agility, or how to get it. Without congruence, a VUCA environment presents challenges which incongruent organisations are poorly equipped to meet.

So, forget the past twenty years and the search for agility. Congruence is the thing.

– Bob

Footnote

♥ It was a bunch of software developers that invented and promoted the idea of agility (for software development) some twenty years ago now. Businesses everywhere have seized on this prior art in their attempts to cope with the upswing in perceived volatility, uncertainty, complexity and ambiguity in the business environment.

PS

The same argument also applies to the birthplace of the agility meme: the software development silo. Forget the past twenty years and the search for development agility. Congruence is the thing.

Management Must Manage

Years ago, when I was starting out in my study of management methods, I came across ITT and its then president, Harold S. Geneen. Setting aside his connection with Phil Crosby and the ZeeDee (Zero Defects) quality movement, Geneen was famous for many things, including one quote which has stuck with me ever since I first heard it:

“Management must manage.”

What a soundbite!

Taken at face value, it’s a homily. Management must manage. Those with management responsibilities must execute those responsibilities (rather than dicking around with other things). “Well, of course. What else would they do?”

But there’s another meaning I choose to also find within. Management must manage: when we have people appointed to management positions, those people are the ones that must manage, not some others.

The whole Agile shambles, most often labelled AINO (Agile In Name Only), stems largely from ignoring this second interpretation of Geneen’s admonition.

Early Agilists, wanting to escape from the oversight of managers who had different opinions about how to manage software development, created Agile to wrest de-facto management responsibility from those managers. Thus grew the lame-assed version of self-organisation and self-managed teams so widespread today. I say lame-assed because almost no Agile team is self-managed. How could they be, when managers still have the authority and positional power to manage?

So we have instead a festering conflict of responsibilities, causing confusion and resentment all around, and dragging down engagement and productivity. Agile can “work” when the split of management responsibilities are made crystal clear for all concerned. And when that split has the blessing of management. This is almost never the case.

So, management must manage. Not developers. Not dev teams.

That sucks. Until we realise that it can be no other way. And even then, it still sucks, unless dev teams themselves have the responsibility and authority to manage. Where the dev teams are the management. Then we have the best of both worlds. A world of autonomy, mastery and purpose. A world of engaged people aligned to a common purpose and a common approach.

– Bob

Random Walks

How well does the almost universal Agile practice of “build it and see if they come” serve us (as developers, as customers)?

I suggest it’s time to rethink our belief that customers (and developers, for the most part) “don’t know what they want until they see it”.

My late, great colleague and friend Grant Rule used to refer to the practice, common in the Agile domain, of building (a portion of) something to see if the customer likes it as “random walks through the problems-solution space”.

Quality Demands Requirements

Philip Crosby, a widely acclaimed “guru” of Quality Management, defined quality as “conformance to requirements”. As simple and blunt as that.

Recently, I’ve been reflecting on my experiences with software product development, especially the development of “quality” products that customers love. In Javelin, we place special emphasis on de-risking delivery through explicitly defining the customers and their respective requirements. Not big-bang, up-front stylee, but incrementally, just enough each couple of days to build a little more of the product and deliver it to the customer(s) for their delight, confidence, and feedback.

But in our approach, requirements (in the frame of the Antimatter Principle we call these needs) precedes building anything. Agile shops these days seems to major in building something before discussing requirements (if they ever get discussed at all). BDD offers an exception, but how many shops do BDD?

Aside: In Javelin, we identify all stakeholders (a.k.a. all the Folks That Matter), discuss their needs (“Stakeholders’ Needs”, in Javelin parlance) and quantify them (a la Gilb – see: Competitive Engineering) in the form of Quantified Quality Objectives. Although:

  • This all generally proceeds incrementally, rather than in a big batch up front.
  • The information is always to hand by the time someone gets around to building the relevant part of the thing in question.
  • The requirements come from dialogue(s) with the relevant Folks That Matter.
  • The requirements need not get written down (documented) unless there are some Folks That Matter that need them to be.

People work from the requirements. Always.

Random Walks are not Our Bag

Random walks are not our bag.

By cleaving to the belief that customers “don’t know what they want until they see it”, and structuring the whole approach to development around this belief, Agile shops have no incentive to improve the way they work with customers to understand their needs. No incentive to improve requirements elicitation and capture. No incentive – or means – to prevent defects and deliver zero-defects quality. Indeed, this belief and its associated practices blocks us from working to continually find better ways to create useful requirements (formal statements of folks’ needs) from which to drive quality (cf Crosby) and the improving of relationships with each other (developers, ops) and with customers.

Is this emphasis on working-from-clearly-stated-and-agreed-requirements better? Well, in my experience it makes for happier customers, happier developers, and more successful products. I’ll leave it to you to decide whether and how that’s “better”.

– Bob

The Relevance of Giants – 1. Deming

On most every occasion when I’m speaking in public – at conferences, workshops, and the like – I tend to mention one or more of my “Giants” of Rightshifting. Men and women who, through their lives and work have contributed significantly to my understanding of work, and in particular to my understanding of effective collaborative knowledge work.

Many folks express interest in these Giants, but I do wonder if they appreciate the relevance of the ideas and experiences of these Giants to their own daily lives at work.

I mean, what relevance does, say, Bill Deming have to developers, testers, operations staff and the like? Which aspects of any of these Giants’ work could be useful or helpful or simply comforting to these folks?

In this occasional series of posts I’ll be exploring some of the Giants’ relevance to folks other than theorists, managers, consultants and the like. I’ll be sharing some insights into their work, and specifically, the likely relevance.

With these posts I hope to pique your curiosity just a little. Let’s start with Bill Deming.

W. Edwards Deming

Bill Deming

(October 14, 1900 – December 20, 1993)  (See also: Wikipedia entry)

I’m not going to dwell on his work in SPC (Statistical Process Control) or SQC (Statistical Quality Control), his pivotal role in the Japanese post-war economic miracle, his 14 Point system of thought he called the “System of Profound Knowledge”, nor his Plan-Do-Study-Act (PDSA) cycle (the latter being the basis for most Agile approaches, btw).

Deming’s 95/5

I suggest the primary relevance of Deming to most folks working in the field of software development (and production operations) is primarily the idea known as “Deming’s 95/5” (although this originated in a quote from Peter Scholtes).

“The fact is that the system that people work in and the interaction with people may account for 90 or 95 percent of performance.”

From my studies of Deming, and from applying his ideas in my practice, I have come to believe that it’s the interactions between people that account for the lions share of “productivity”, “performance” and “success” in collaborative knowledge work. And the “system” a.k.a. the way the works works has a major (hidden) influence on the quality of those relationships, as well as on the work (output, results) of the individual workers.

“Dr. Deming taught me that 95% of the performance of an organization is attributable to the system (processes, technology, work design, regulations, etc.) and [only] 5% is attributable to the individual.”

~ Tripp Babbitt

Where’s the Relevance?

If, like most people, you’re looking for a better quality of life at work, Deming points the way to us improving our relationships with our colleagues, peers and managers. Maybe this perspective is something to consider on those occasions when you’re less than happy in your work, when you’re checked-out, or disengaged, or frustrated.

And Deming’s attribution of 90-95% of your performance to the system within which you’re obliged to work throws a new light on many typical organisational practices such as history-led recruitment, performance appraisals and reviews, stack ranking, criticisms (and praise) for your efforts, etc.. Your results (and self-esteem) may be taking a hit from the effects and constraints inherent in that system, not from anything you’re doing (or not doing) yourself.

Practical Investigation

Deming designed the Red Bead Experiment to illustrate these very points, in a way that most people can directly relate to.

– Bob

Further Reading

Four Days with Dr Deming ~ Latzko and Saunders
95% of performance is governed by the system ~ Vanguard web page

Cognitive Function

How often do you get pissed off by interruptions and distractions? You know, when you’re zoned in on something, in a state of flow, and something happens to break the flow? Personally, when I’m writing code, I have to be in a quiet place, by myself or with my pair or mob, else I can’t get anything done for the continual distractions.

This is but one example of how easily cognitive function can be impaired.

Common sources of cognitive impairment:

  • Distractions and interruptions
  • Stress (specifically, negative stress a.k.a. distress) Cf Amygdala Hijack
  • Tiredness, fatigue, lack of sleep.
  • Multitasking
  • Poverty
  • Diet
  • Shift patterns
  • Noise and other forms of environmental stressors (lighting, odours, vibrations, exposure to particulates, elevated carbon dioxide, etc.)
  • Physiological issues (such as colds and flu, hypoglycemia, aphasia, depression, dehydration, hypertension, obesity, trauma, diabetes, Parkinson’s, POTS, dementia, hypoxia, atrial fibrillation)
  • Substance abuse (drink, drugs, etc. – short and long term effects, chronic and acute)

Wow. That’s quite a list. Seems like almost anything can impair cognitive function.

Why Does this Matter?

So why does cognitive function matter. What’s the connection with knowledge work? I’ll spell it out in case it’s not clear:

Knowledge work – such as software development – by definition involves working with our brains. If our brains are performing well (i.e. effective or relatively high cognitive functioning) then we can expect our work to go well, things to get done quicker, with fewer errors, and so on.

Conversely, when our cognitive function is impaired, our brains will take longer to accomplish tasks, come up with less effective solutions, commit more errors, and generally perform more ineffectively.

It’s also likely that with impaired cognitive function we’ll be less reflective, with less energy or capacity to spend on thinking about our work, our relationships, our behaviours, our practices, our customers, possible innovations, our needs and the needs of others, etc..

Does it sound to you like non-impaired cognitive function is something worth having? Something worth paying attention to?

Paying Attention?

So how many folks – managers, workers, organisations – pay any attention AT ALL to folks’ cognitive functioning in the workplace or whilst working? I’d suggest the answer is none, or as near none as makes no difference.

Which seems strange to me, if we truly seek our collaborative knowledge work (and workers) to be as effective as possible. Of course, that objective may be a false assumption. Maybe blissful ignorance and indifference is preferable to paying attention and taking action? Given the reluctance I’ve encountered when broaching this subject, I suspect blissful ignorance and/or indifference holds sway.

How does it go in your organisation?

– Bob

Solutions Demand Problems

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

BenSImoTweets

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

%d bloggers like this: