Archive

Product development

The Future Of Software-Intensive Product Development

A little while ago I wrote a post posing some questions about what ways of working we might look to, After Agile. Fewer folks engaged with this post compared to some others I have written. So I’m assuming that few are thinking about what we might see as the natural – or even unnatural – successor to Agile.

It is, however, a topic that occupies me regularly. Not least because of the intrinsic flaws in the whole Agile idea. We can, and eventually must, do much better.

Recently, some folks have been asking me about what I see as the future for software- and software-intensive product development (SIPD). Of course, I’ve been answering this question, on and off, for at least the past few years.

In a Nutshell

To sum up my take: In a nutshell, the issues that plague SIPD seem obvious. They’re mostly the same issues that plague all forms of collaborative knowledge work. Issues compounded by the gulf between conventional or traditional work and the new world of work (i.e. the world of collaborative knowledge work) – a new world distinctly unfamiliar to most in the world of work today.

We are faced with various collections of pathogenic beliefs (management, traditional business, Agile, etc.), none of which provide us with a context for EFFECTIVELY tackling the challenges we face in the new world of work – i.e. the world of collaborative knowledge work.

I’m choosing here to list these challenges in terms of needs, and in terms of the strategies – conventional and unconventional – for meeting those needs.

Developers’ Needs

Agile came into being driven by developers attempting to see their needs better met. These include:

  • Less working time “wasted” on mindless bureaucracy and distractions, such as meetings, reports, documentation, etc..
  • More time to focus on making great software, and stuff that delights customers.
  • Improved relationships with co-workers, business folks, customers, and the like.
  • More flexibility to adapt to emerging information, to changing needs, and to things learned along the way.
  • More say in what they work on, the tools they work with, and how they do their work.
  • Approval of one’s peers (including a sense of belonging and community re: the “technical” tribe)
  • And simply, the leeway to just “do a better job” and make a positive difference in the world.

Bottom line: Many developers need to feel valued, purposeful, that they’re making progress (learning) and are recognised for their abilities.

Business Folks’ Needs

Secondarily, but still important in the Agile approach, is better outcomes for “the business”. Agilists have come to recognise the following needs (even though common forms of Agile do not address them).

  • Approval of one’s peers (including a sense of belonging and community re: the “management” tribe).
  • Empathy (meaningful connection with other human beings).
  • A positive self-image.
  • Stability (folks have families to support).
  • Acclaim/fame (folks have careers to pursue).
  • Warmth (of human relationships) – Most business folks are just normal people, too.
  • Peace (i.e. an absence of distress).
  • Purpose.

Users’ / Customers’ Needs

Businesses ultimately stand or fall on revenues. Revenues which depend on their products and services meeting the needs of their customers. These needs include:

  • Approval of one’s peers (including a sense of belonging and community re: the “brand” or “XYZ customer” tribe).
  • A positive self-image (what being a user or owner of a certain product says about you, in your own mind).
  • Stability (folks don’t like to think too hard, or continually learn new stuff for no good reason).
  • Warmth (of human relationships) – Most customers, being humans, value interactions with other human beings.
  • Low fuss (i.e. being able to get their jobs done with minimal distress).

Shareholders’ Needs

Shareholders also have needs which they seek to get met. These include:

  • Approval of one’s peers (including a sense of belonging and community re: the “investor” tribe).
  • Contribution to society (e.g. ethical investments) and communities.
  • Financial returns (investors have families and/or lifestyles to support).

In a future post I’ll be looking at the strategies that people use to get these needs met, including those strategies implicit in Agile methods – and some alternative strategies that might prove

– Bob

 

We’re All In This Together

Creating, sustaining and continually improving effective ways of New Product Development requires the efforts, commitment and active participation of everyone in the organisation. It’s not something that can be delegated, offloaded or left to just one department, function or silo.

In my previous post, I mention a number of constraints which typically prevent an organisation from having an effective product development approach. If you take a look at that post, you may begin to see how these particular constraints are organisation-wide. And how reducing or eliminating them requires the active participation of everyone, from the CEO, through function heads, to the front-line workers:

Whole Products means specialists (sales people, marketeers, finance, operations and customer service specialists, etc.) from across the organisation are needed for each and every new product development.

SBCE means changes to accounting practices, personnel recruitment, allocation and training (HR), as well as the understanding and involvement of senior executives in investment and strategy decisions for the longer term.

Flow means reorganising and smoothing the internal operations (explicit or implicit value streams, customer journeys, etc.) which run through the daily business as usual of the whole organisation.

Transitioning from a projects-based approach to New Product Development to something more effective (such as FlowChain) requires the overhaul and replacement of many policies, procedures and expectations across the organisation.

Cognitive Function asks us to learn about topics – psychology, neuroscience, sociology, anthropology – with which we may have had little experience before. And to prevent just one group (NPD) getting wildly out of step with the rest of the organisation, most people coming into contact with these new ideas and ways of relating to each other will need to at least understand what’s going on.

A clearly-articulated and jointly-created product development doctrine offers a means to encourage debate, and understanding, across the whole organisation.

Summary

Each of the above changes requires new understandings and new behaviours – including e.g. cooperation, collaboration, trust, and support – from every department in the organisation. Existing incentives, goals and rewards schemes tailored to individual performance and local (function-specific) results will directly oppose these new behaviours, so must be replaced with schemes designed to foster the new behaviours. Old assumptions and power structures, again supporting of traditional ways of doing things, must be overhauled to become more relevant to our new, more effective ways of New Product Development.

Ultimately, we will find ourselves asking the question “Is it worth it? Does an amazing uplift in our organisation’s ability to release new products and product updates with:

  • fewer delays and overruns
  • higher quality
  • lower cost
  • better product-market fit

warrant the root-and-branch changes necessary for success? Are we in business for the long-haul? And do we each want to be proud to have played our part in creating something truly awesome?

– Bob

 

Constraints On Effective Product Development

Bottlenecks

What company wouldn’t love to have its product development efforts be more effective? Be able to release new products and product updates with fewer delays and overruns, with higher quality and at lower cost? And be sure of the product-market fit, too?

Many companies spend inordinate amounts of time, effort and management attention on just this. And yet reap little in the way of benefits from that investment.

Why is this? What are the blockers (constraints) frustrating these ambitions?

I see the same patterns time after time. Patterns that stymie effective practices and lock in ineffective approaches and poor results. Here’s some of the more common ones:

Whole Products

Few companies are able to reap the benefits of a Whole Product approach to New Product Development. The constraint here is the ability of people and teams from different functional areas across the business to come together (literally and figuratively) for the duration of a product’s development. Toyota have long eliminated this constraint through their Obeya concept, and unique matrix structure.

Set-Based Concurrent Engineering

Most companies suffer unpredicted (yet predictable) overruns and delays in the development of many (most) of their products. One key constraint in play here is the lack of options when a particular component or subsystem – on the product’s critical path – proves problematic. SBCE eliminates this constraint by purposely providing options at every stage of the product’s development. At each “integration point” during a development, the most promising (and always 100% viable) option is selected. SBCE as a solution is predicated on the organisation’s ability to save its learning on and investment in the “pruned” options, for future products or upgrades.

Flow

Organising around flow offers a number of benefits, not least reduced costs and delays. Many companies attempt to organise traditionally – around skills and functional silos. The traditional approach chokes flow and reduces the effectiveness of product development.

NoProjects

The almost universal use of projects as the containers for product development work again constrains our efforts to the relatively ineffective end of the spectrum. The many drawbacks of the “projects” concept are well-known. Yet the constraint here is no so much projects themselves, but the way in which an organisation’s policies, procedures and assumptions lock in the idea of projects. Moving to a non-project approach, such as FlowChain, is a political and social challenge of the first order.

Cognitive Function

Many companies understand the issues of engagement and the need for innovation. Fewer understand the nature of collaborative knowledge work, its fundamentally differences from more traditional forms of work, and the need to approach it with a fundamentally different set of assumptions. Assumptions absent which, effective product development – as the archetype of collaborative knowledge work – is impossible. The traditional assumptions at the heart of traditional management of traditional organisations are the key constraint here. These assumptions prevent us realising the high levels of employee engagement, the innovation culture and the high levels of cognitive function so necessary for effective product development.

Doctrine

Few organisations have a clearly articulated and debated doctrine describing their approach to product development. This absence of clarity constrains the whole organisation, with folks constantly wondering what they should be doing, why they’re doing it, and how everyone’s efforts fit together.

Summary

The above are just a few of the key constraints condemning product development efforts in most organisations to the ghetto of high costs, poor quality and interminable delays. None of these constrains are simple or easy to tackle. But identifying them is the first step to dealing with them. What constraints are limiting your product development effectiveness?

– Bob

Further Reading

Product Development for the Lean Enterprise ~ Michael N. Kennedy
It’s Not Luck ~ Eliyahu M. Goldratt
The Principles of Product Development Flow ~ Donald G. Reinertsen

The Simplest Thing That Could Possibly Work

TinCup

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

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

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

– Bob

Further Reading

The Twelfth Principle

There are four values and twelve principles connected with the Agile Manifesto. As the folks at 12thPrinciple say,

“the four values and eleven of the twelve Agile principles do not address the wider organization at all.”

This is one of the key reasons why so many Agile adoptions (circa 80%) fail to deliver on the Agile promise.

I have this weeks added my name to the list of signatories at 12thprinciple.org.  Not because I totally and wholeheartedly embrace the “Twelfth Principle” in its current form. But because I wish to lend support to the idea that it’s the wider organisational context that utterly determines whether any kind of progressive change effort or initiative succeeds or fails.

The Twelfth Principle (n.b. actually appearing fifth in the list of Principles behind the Agile Manifesto) reads:

“Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.”

I see some basic flaws in this, but it does serve to highlight (at least, implicitly) the role of the wider organisation.

Here’s my take on these “flaws”:

  • Projects. I see little point in using projects to frame development efforts. Personally, I subscribe to #NoProjects, and FlowChain as a practical means to replace the whole idea of projects, in favour of product development flow.
  • Individuals. Yes, teams consist of individuals. But Man is a social animal, and collaborative knowledge work – such as software and product development requires society, not individuals. I get the idea that we’re really taking about a focus on people, here. As opposed to say structure, hierarchy, process, or what have you.
  • Give. Not so much give as in charity or largesse, but give as in make available, enable.
  • Them. Shades of them and us? Unfortunate choice of pronoun.

With a free hand, and the awesome benefit of hindsight, I might represent this principle thusly:

“We accept that collaborative knowledge-work proceeds best when we place people at the core of our focus.
We recognise that people do best within a supportive environment,
where needs are shared and attended to by all.”

How might you rephrase this principle?

– Bob

 

 

A Second Open Letter to the Project Management Community

Since my first open letter to the Project Management community, some three years ago now, not much has changed. Not that I expected a single blog post to have much impact.

After Agile. What now?

The rising dissatisfaction with the Agile approach – even amongst the Agile community – and the rumblings around the question “After Agile. What now?”, leads me to update my earlier letter, and broaden its scope to address the Agile Community, too.

Dear All

Dear Project Managers and Agilists everywhere,

I hear you continue to have mixed views about the ongoing, er, “developments”, in the field of Software Development. I won’t call them “advances” as we may not be able to agree that they are, in fact, advancing anything. Incidentally, I share some of your likely skepticism on that front.

I am writing to you today to share some opinions and observations about the changes in train in the software development field, globally. Whilst patchy in their uptake, with many a mis-step, changes are afoot. I can relate to your professional concerns that we retain the best of what we have learned from decades of successful project management (this also, we have to admit, being very patchy, too).

Many who look to advance the field of software development also have concerns. Concerns that some of the received wisdom of project management professionals has been rendered redundant or even dysfunctional by recent advances in fields such as psychology, neuroscience, sociology and evidence-based management.

These bilateral concerns have lead to understandable, yet vexing, tensions and misunderstandings between the various communities. Nowhere have these been more evident, perhaps, than between ‘traditional’ project managers and the Agile crowd.

And now, a third faction has also entered the debate. I’ll call these the After Agilists.

I find it helpful to characterise this conflict as a clash of world-views. In a nutshell, a clash between what McGregor has called “Theory X” and “Theory Y”, compounded by the clash between those who believe Agile is all we need for success, and those who recognise the flaws in both “traditional” project management and “conventional Agile” and wish to move on, correcting them as we go

I hope I’m right in thinking that we all share a common objective – a desire to see better outcomes for everyone involved, to see the needs of all stakeholders much better met than has been the case to date. Oh, and maybe improving the levels effectiveness of the organisations within which we work, too (another need, for many).

Whilst it may appear the arguments and contentions arise from our different ways and means for achieving this objective, I’d like to suggest that the conflict – as a product of conflicting world-views – is more deep-seated, and all the more pernicious for that. We can hardly expect folks, of any persuasion, to change their world-views overnight, if at all. Nor blame them for that aspect of their humanity.

And given the fundamental differences between these various world-views, it seems overly optimistic to expect these world-views ever to coexist peacefully and productively.

All we might hope for is a little more understanding, a little less fractiousness, and a future where we can all at least agree to disagree.

More optimistically, we might also realise that everyone has much to learn – and unlearn – from each other. That, perhaps, is something we can all work on together.

Thanks for listening,

– Bob

Further Reading

Power And Love ~ Adam Kahane
Power and Love – RSA video

The Cold Wet Nose Of Reality

bloodhound

If you’re in the business of supplying IT services, especially software and product development, to your clients, you may be getting uneasy (again). Agile software development, and its close cousin, DevOps, are the latest in a long line of approaches promising to solve the “software crisis”. And like the many approaches that have gone before, their faults are beginning to show, and the chickens are coming home to roost.

As they say:

“…you can’t fool all of the people all of the time.”

I don’t doubt that many solutions providers and consultancies have the best interests of both their clients and their own staff at heart, and are not just focused on their revenues. And just like their antecedents, Agile and DevOps did look promising. But just as with those antecedents, time has shown the core ideas wanting. Or, more accurately, insufficient in the majority of cases.

Why Early Adopters Have Good News

Whatever the approach, its early adopters generally have good stories to tell, about good outcomes. And why not? These folks had the enthusiasm, the curiosity, the drive, and the grasp of the principles to make the approach work. Later adopters, absent some or all of these advantages, have struggled to see useful benefits. No matter what the approach.

That Nose

Truly, the cold wet nose of reality has been sniffing out the latent flaws implicit in Agile and DevOps from the outset.

Smarter Now

I’d like to hope that we’re collectively smarter now. That having seen so many promising approaches come and go, we might be on the verge of seeing beyond the superficial attractions of each new approach. That we may be, finally, developing the deeper lore that will show us why all our approaches to date have sooner or later failed us. I’d like to hope that, But in general, I see precious little evidence of it happening.

“A new type of thinking is essential if mankind is to survive and move toward higher levels.”
~ Albert Einstein

– Bob

%d bloggers like this: