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.
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).
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 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
- More effective
- Easier to adopt
- Less counter-productive