The Future Of Software-Intensive 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. Put another way: Autonomy, Mastery and Purpose.

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). Even better, eustress, where possible.
  • 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


  1. Daniel said:

    Just challenging but why do Developer type folks mention Developers, Stakeholders, Users, Customers but still leave off OPS (Support, infra, service desk of what they create)

    • Hi Daniel,

      Excellent question! I’d be delighted to include a section for OPS (and other technical, non-dev) folks. (And maybe one for non-technical, non-management folks, too). Would you be willing to enumerate the needs that I might list thereunder?

      – Bob

      • Paul Beckford said:

        My preferred definition for “developer” includes OPS (and testers, and BA’s and Architects, and …basically anyone who gets involved in a practical way, delivering and sustaining software). It would be interesting to see whether people felt the needs of any one of these groups where some how distinct and why?

        My suspicion is if indeed these different groups do end up with differing needs, it has to do with a prevailing management culture that chooses to utilise “divide and conquer” techniques as a means of exercising control, rather then anything intrinsic to the actual work being performed.

  2. Paul Beckford said:

    Excellent post. I like the way you characterise SIPD as a social system governed by the needs of the differing groups of people involved. Very different from the usual lens of a production system, where the focus is on structure and mechanics, and where there is perceived to be only one single need: the need to deliver (and sustain) working software systems.

    Looking at a SIPD as you have reveals that in fact there are several needs (some legitimate, and some not?); leading to the possibility of conflicting needs.

    As a social system; a SIPD finds itself sharing in the same space as a number of wider and overlapping social systems. All these systems are porous as they share the same raw ingredient: people. People choose to adopt different roles and personas in differing social contexts.

    Thus any analysis of a SIPD that views it as a closed social system is bound to be flawed. Social systems are open by definition.

    For example, an investor could choose to adopt the role of “predatory capitalist”; when organising their investment portfolio, addressing their need for financial returns; whilst adopting the role of “benevolent benefactor” at Church; gaining the approval of their peers and meeting their need to feel part of a community.

    Given this multifaceted nature of people; any true analysis of needs and the role they play within a SIPD, must also take into account the wider picture, and how people choose to meet their varying needs within society as a whole.

  3. zuebridvemuba said:

    Wonderful post will be linking this on a few sites of mine keep up the good work.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: