Archive

Software development

Holistic Solutions for Product Development Businesses

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

Which is a fair question.

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

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

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

Flow•gnosis?

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

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

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

What’s the Problem?

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

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

Understanding the Problem

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

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

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

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

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

UDE: Continual contention for in-demand specialists

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

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

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

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

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

A Bird’s Eye View of Flow•gnosis

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

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

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

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

Out With the Old Rules, In with the New

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

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

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

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

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

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

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

Summary

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

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

– Bob

Further Reading

Meeting Folks’ Needs At Scale – Think Different blog post

Innovation ALWAYS Demands We Change the Rules

How do you feel about the proposition:

“Innovation can bring benefits if and ONLY if it diminishes a limitation”

Let’s examine this proposition. Do you agree with it? Don’t be too hasty in coming to agree with it. Once we agree, you’re hooked! So, let me explain a little more, starting with some definitions:

Innovations

We’re talking here about all kinds of innovations. Not just tech innovations (new materials, new languages and tools, new industrial processes, new scientific discoveries) but other innovations too (new ways of doing things, new ways of structuring and managing organisations, new ways of developing products and software, plus many others).

Limitations

What do we mean by “limitation”? A limitation here is anything that restricts us from getting our needs met to the maximum possible extent. (And btw that maximum is, itself, a limitation).

Limitations can be “recognised” (for example, a speed limit on a motorway) or unrecognised (for example the physical speed limit for a given curve, with a given vehicle, in specific road conditions).

Examining the Proposition

So, back to the proposition: “Innovation can bring benefits if and ONLY if it diminishes a limitation.”

Do you agree?

We were alive and functioning even before the innovation became available. Correct? It must be, then, that long before the new innovation, we developed modes of operation, modes of behaviour, policies, rules, to accommodate the limitation. I’ll refer to all these as simply “rules”.

We were able to operate. Rather than run smack into the limitation and die. That’s obvious.

Before the innovation, we created certain rules to cope with the limitation (recognised or unrecognised, known to us or unknown).

Suppose, then that we make a very good job of implementing an innovation, and thereby diminish the associated limitation totally. Still, the question is:

What benefits will any innovation bring, if we neglect to change the rules? The rules that helped us to accommodate the limitation, before the innovation was available? What benefits will we see if we neglect to change the rules?

Do you start to see the answer?

The Old Rules Block Any Benefits

What benefits will we see if we neglect to change the rules? Basically, no benefits. None. Why? Because as long as we obey the old rules – the rules that were there to bypass the limitation – for as long as we obey these rules, for all practical purposes we will continue to behave as if the limitation is still there.

Can it be that we’re so stupid that we continue to adhere to our old rules, the rules we originally invented to bypass or cope with the limitation? You know the answer.

This is what is happening every day, for the vast majority of organisations, and for the vast majority of innovations they adopt. For a long time after adopting the innovation we still obey the old rules. And because of this, for a long time we don’t get any of the real benefits from our investment in the innovation.

Four Not So Frequently Asked Question

So, how might we proceed if we need to ensure that innovations really do bring us the promised bottom-line benefits? We might choose to ask ourselves the following sequence of four questions:

Q1: What is the POWER of the innovation? (Just ask the inventors, they’ll be more than glad to explain, and explain, and explain…).

Q2: What limitation does this innovation diminish? (We must find a specific and precise answer, here).

Q3: What existing rules served to help us accommodate that limitation (i.e. what obsoleted rules we must get rid of)? Here we can for the first time evaluate the tangible bottom-line benefits from removing those old rules). (Note: As long as the old rules remain in force, we will never see the promised benefits from the innovation). Ch1 11:10

Q4: What (new) rules must we use now (in place of the old rules which the innovation has obsoleted)?

Let me give you an example. Let’s take Agile Software Development as our innovation.

Q1: What is the POWER of Agile Software Development?
A1: Agile Software Development increases the likelihood that we’re developing software that meets our customers’ real needs.

Q2: What limitation does Agile Software Development diminish?
A2:  Risk of misunderstanding customers’ real needs, both now and as they evolve.

Q3: What existing rules served to help us accommodate that limitation?
A3: Contractual terms. Big up-front specifications. Rigorous plan-driven project management. Change control. Specific duration projects. Formal V&V.  One-off or infrequent release into production.

Q4: What (new) rules must we use now?
A4: Development and delivery as experiments. Short, tight feedback loops. Constant collaboration between customers and developers. Constantly evolving specifications and solutions. Multiple “stop/continue” checkpoints. Incremental and frequent release into production.

Try It For Yourself

Here’s some other innovations we see introduced in e.g. software development organisations. Try running through the above four questions for one or more items on this list:

  • Teams / team-based development.
  • Obeya (big-room).
  • TPDS (Toyota Product Development System).
  • Lean Product Development.
  • Cost of Delay.
  • Flow.
  • Pyton, ELM, or some other new language or tool you may be considering adopting.
  • Self-organisation / self-management.
  • Servant Leadership.
  • Holacracy.
  • Serious Play.
  • Continuous Improvement.
  • [Your own favourite innovation].

We Must Change the Rules

“Human beings cannot progress unless somehow they do things differently today from the way they did them yesterday.”

~ Shigeo Shingo

So now we can see that the real effort we must make is NOT in adopting new innovations, but in changing the rules. And these rules are manifest in the assumptions-in-action, the collective mindset, the culture, of an organisation. This, btw, is the central message of Rightshifting and the Marshall Model.

– Bob

Further Reading

Beyond the Goal ~ Eliyahu M. Goldratt (Audiobook only)

Coaching, Scrum Mastering, and Expertise

[Tl;Dr: Is it more, or less, effective for coaches, etc. to have technical (non-coaching) abilities?]

Over the years I’ve heard every kind of opinion on whether technical expertise is an asset or liability for coaches, Scrum Masters, and the like. Some folks, mainly executives, have sworn they would never hire a Coach or Scrum Master with technical expertise. Others, mainly coaches and Scrum Masters, have held much the opposite opinion. Those being coached have rarely expressed an opinion (although I suspect that’s because they don’t get asked, or think it won’t count, and not because they’re indifferent on the subject).

Personally, I tend to the opinion that, if it were down to me, I’d look for folks with excellent and demonstrable coaching skills, and not worry about the presence or absence of technical abilities unless they seemed intrusive and likely to interfere with the coaching dynamic. I recognise the argument that technical people lend more credibility to like-minded (i.e. technically capable) coaches because they find it easier to respect and identify with such folks. I also believe this argument to be a red herring, at least in the case where the coach or Scrum Master is effective and capable in the Coaching or Scrum Mastering skill-sets.

This is probably a good place to mention the Inner Game, and the suggestion by one of its founders, Sir John Whitmore, that “technical” knowledge and experience is a decided handicap for coaches and the coached, alike. In his book “Coaching For Performance” he tells several stories about this phenomenon, in particular that of the tennis group who, deprived of their regular tennis coach (and tennis expert) improved much more quickly under a substitute coach (with much coaching and skiing experience but no tennis experience).

Given that opinions on this topic seem all over the map, and many (mainly fruitless) discussions continue, I wonder if you have any experiences you’d be willing to share here?

– Bob

Further Reading

Coaching For Performance ~ Sir John Whitmore

The One Perfect Way to Develop Software

[Tl;Dr: Being a Master of the perfect way to develop software is more of a handicap than an asset.]

Let’s imagine you’ve received a Matrix-style download of all the knowledge and skills necessary for Mastery of the perfect way to develop software. And you’ve applied this knowledge, and honed the skills, in several or many software development endeavours. And have the results to prove it.

Then you join a new-to-you organisation, and a new-to-you team, where of course you want to share your profound, highly valuable insights, capabilities, knowledge and skills with your peers, with a view to you all basking in the sweet success of the One Perfect Way.

Setting aside secondary issues such as the probability that there is no ONE perfect way, and that software development per se is maybe not what our customers are really interested in, what could possibly go wrong?

I’ll leave this question hanging. If I receive some expressions of interest, I propose to return to it in a future post.

– Bob

Further Reading

Characterizing people as non-linear, first-order components in software development ~ Alistair Cockburn

 

No Hashtags

[Tl;Dr: #No… hashtags are aspirational, not didactic.]

I seem to have been labouring under the misapprehension that most folks in the Twitter software and product development communities have come to understand the mode of use of the various #No… hashtags we see regularly these days. Particular with the widespread exposure of the mother of them all: #NoEstimates.

(Note: I use the #NoTesting hashtag in a couple of the examples, below, mainly because recent discussions thereon have suggested to me a need for this post.

Invitational

For me, #No… hashtags are a short invitation to interested folks to think again about what, often, are near-autonomic responses. For example, I regard each occurrence of the #NoEstimates hashtag as an invitation to ponder whether, in each case, estimates are giving us value and meeting folks’ needs (in a relatively effective way). An invitation to checkpoint ourselves, and to discuss whether we are just us going-through-the motions without thinking too much about the role of estimates – and estimating – in any particular situation.

Aspirational

Also, I see #No… hashtags as being intended as aspirational: Articulating or labelling a future state where things could be different. Aspiring to change.

For example, I use #NoTesting to advertise my aspirations for a world of development where testing is no longer the chosen path to quality, replaced by other means for more economically delivering products, etc., with agreed levels of quality. So, in that case, #NoTesting really does advertise my aspiration for an end to testing – which I see as hugely expensive and wasteful compared to other, less well-known means – but NOT at the expense of product quality. It also implies – easy to miss, I guess – a responsible, calm, controlled transition from todays’ approaches to that aspirational future state.

“Ask not ‘how are we going to test this?'”
“Ask rather ‘how are we going to ensure this goes out with the agreed levels of quality?'”
“And when you’ve got a handle on that, ask then ‘how are we going to ensure that everything we do henceforth goes out at the agreed levels of quality?'”

Confrontational

And yes, too, #No… hashtags are confrontational. They invite us to challenge ourselves and our entrenched beliefs. To consider change, and it’s implications. And that’s often uncomfortable, at least. Particularly when the topic challenges folks’ self-image, or seems to threaten their accumulated wisdom, reputation and experience, or their livelihoods. I hope we can all see these things in the spirit of mutual exploration, rather than as an opportunity for reiterating entrenched positions and protecting the status quo.

“[#No… Hashtags are] the social media equivalent of poking people with a stick.”

Metaphorical

When I use #No… hashtags, I’m being metaphorical rather than literal. Some folks may not understand this and get upset, by taking them literally. For my part, I believe that’s on them.

For example, with the #NoTesting hashtag, I have had some folks assume that I’m advocating abandoning any concern for the quality of e.g. a product under development. This is not my position. Although denying it seems only to inflame the situation once folks have got their teeth clamped on that particular bone. I guess their assumptions stem from not having knowledge of other means to quality.

In using the #NoTesting hashtag, I’m basically saying “under some circumstances, maybe there are other, more effective means to meet folks needs re: product quality than the default strategy most use today (i.e. testing)”. “How about we talk about those various circumstances, and means?” In this way, #No… hashtags are a metaphor for “would you be willing to think again, and maybe join the search for more effective means, and the contexts in which they might bring benefits?”

Summary

Would you be willing to join me in embracing the #No… hashtag modality, and take each occurrence as an opportunity for a productive and relationship-building mutual exploration of a topic?

– Bob

Further Reading

The Germ Theory of Management ~ Myron Tribus

The Structure of Scientific Revolutions ~ Thomas S. Kuhn

 

Learn Through Delivering

In my previous post I talked a little about the role of language and vocabulary in shifting focus – from being busy, to attending to folks’ needs. The word ‘deliverable’ emphasises, unsurprisingly, delivery. But what does it mean to “deliver” in the context of i.e. software development?

Inspect and Adapt

For me, delivery is the opportunity to close the feedback loop. To gain some insight into whether what we’ve been working on has been useful to our stakeholders. And to adjust our sights – and ways of doing things – in the light of that information.  So the defining aspect of any and all “deliverables” is that deliverables, by this definition, must be delivered to stakeholders and they must be able to try them out in as near as possible to real-world situations so as to provide meaningful feedback.

Cadence

Just how often might we deliver something for our stakeholders to provide feedback on? That depends on how short we want our feedback loops to be. Myself, I prefer a maximum feedback loop length of two to three days. Whether your teams are in a position to dance to this rhythm, or something slower, kind of depends on your stakeholders and how quickly they can look at, and respond to, each delivery. Keeping deliveries small can help here, by keeping what they have to look at, and their responses, small too.

Artefacts

Of course, there will be things we create, produce – things for our own consumption, like documents, design artefacts, intermediate transformations leading to deliverables, and so on. I choose to call these non-deliverables “artefacts” (or even “non-deliverables”) – to distinguish them from the deliverables on which we intend to seek feedback.

May I invite you to trial a change of perspective – from learning through doing, to learning through delivering – as soon as you have the opportunity?

– Bob

 

Tasks – or Deliverables

In most every development shop I’ve seen, folks’ planning vocabulary has been founded on the task as the unit of work. Long ago, at Familiar, we discovered that a different vocabulary offers some key advantages. Ever since then I’ve found that a planning vocabulary when deliverables are the default unit of work suit me much better.

Some Key Advantages

  • Planning in tasks encourages (subconsciously for the most part) busywork (a focus on activity).
  • Planning in deliverables encourages a focus on outputs (ands thus, closer to outcomes).
  • Deliverables are closer to what stakeholders seek (i.e. having their needs attend-to, or even met).
  • Tasks are generally one stage further removed from needs than are deliverables.
  • Deliverables are, to a degree, ends in themselves – tasks are means to ends (and hence more disconnected from outcomes).
  • I find it easier and more useful to quantify aspects of deliverables than aspects of tasks. YMMV.

Mayhap a focus on outcomes directly would be a further step in the right direction, but for most of the development groups I’ve seen, a single leap from tasks to outcomes might have proven infeasible.

May I invite you to trial a change of vocabulary, and of focus, next time you have the opportunity?

– Bob

 

%d bloggers like this: