A New Frame
A New Frame
For more than half a century, the software industry has been trying to find methods to increase the likelihood of successful software development. From Flowcharting in the 1960s, through to Agile methods today, the industry has gone through dozens of different approaches. And found them all wanting.
Chart: David F Rico
All of these methods, diverse as they may seem, have at least two things in common:
- They all focus on various technical (aka mechanistic) aspects of software development.
- None of them have made much difference to the general level of successful software development aka “the software crisis”. Cf The bi-annual Standish Group “Chaos” reports (below).
I am convinced that the focus on technical aspects is a core reason – I’d go so far as to say the core reason – for the lack of progress in increasing our industry’s rates of success.
Having been in the industry more than thirty years, and having seen – and used – most if not all of the methods listed in the Rico chart (above), I suggest that we might do well to fundamentally change our frame.
Old Frame
The predominating frame for the past fifty years has been that of:
- processes and a process-orientation.
- technical practices (cf. CMMI, XP, Kanban, Scrum, etc.).
- generic (one-size-fits-all) solutions – typically, imposed on those doing the work.
Hardly a surprising frame for an industry long dominated by engineers and scientists. Even though engineers and scientists are people, too (ironically).
And also less than surprising considering this frame has been ubiquitous in business – and much of wider society – for at least the past hundred years and more.
New Frame
Times are, however, a-changing.
Given that software development is perhaps the epitome of collaborative knowledge-work involving groups of people, I propose that we as an industry reorient ourselves and adopt a more useful frame.
The frame I have in mind (sic) is one embracing e.g.:
- Sociology.
- Psychology.
- Anthropology.
- Complex adaptive systems.
- Group dynamics.
- Personalised solutions.
In other words, a frame placing people, not practices, centre-stage. A frame focused on people – and their emergent individual and collective needs.
“You can’t really know what you need until you get it. Only then will you know whether you need it or not.”
~ Marshall Rosenberg
You may appreciate that this frame is about as far as we might possibly imagine from the prevailing (old) frame that we all know and suffer.
Hence my recent posts introducing The Antimatter Principle:
“Attend to folks’ needs.”
~ The Antimatter Principle
A Challenging Request
Would you be willing to take a fresh look at your deepest foundational beliefs regarding how to approach software and product development?
Maybe by doing so we can move away from the mechanical, inhumane, violent and coercive frame within which we’ve all laboured so miserably and so ineffectively for so long.
Maybe we have to fundamentally change our frame before we can begin to build and work in effective organisations – organisations aligned to human nature, and celebrating humanity, joyful society and freedom of choice?
– Bob
Further Reading
Short History of Software Methods ~ David F. Rico
“If you don’t understand people, you don’t understand business” ~ Simon Sinek (video)
Think Different
Thanks for the interesting post. My own thoughts on the failing software problem – http://wolandscat.net/2013/09/29/the-real-reason-most-software-fails/
A short summary of this would be: we are completely failing at understanding requirements, because our whole mentality of understanding the problem domain, the deployment context and the new system function is completely wrong.
Reblogged this on Diary of a ScrumMaster and commented:
Bob has come up with a fantastic single guiding principle: “Attend to folks’ needs”. I can think of nothing better to focus on, whether those people are inside or outside the organisation. Product development seems to boil down to finding ways of meeting peoples needs more effectively, yet we spend more of our time ignoring them. We are discovering it’s a lot harder than it sounds.
Sometimes the world becomes very confusing. One thought is that open source is often free as in free beer as well and certainly the power structure is not terribly top down and controlling. Yet a vast number of web pages seem to depend on Apache servers. And the Apache bottom line is service not revenue.
Google seems to take some interest in what their people wish for, want, and need. It amuses me that it took them a while to find and implement a way to make money, but they did and do make gobs of it. Without offensive banner ads, mostly.
On the other hand, Apple got to be the richest company in the world when it was run again by an often offensively demanding control freak who made lots of mistakes and drove away many of his most talented workers. Still, he must have done some things right, very right.
What do we know of organizations that make great stuff? Are business school studies of any great value? Why so?
We do know that learning from failure is productive and useful. What if we focus on failing often, early, cheaply, and learning as much as possible from the failures? That seems to be much of what Tom Gilb teaches after starting with clear numerically measured goals and a considered understanding of who the stakeholders really are inside and outside the company walls. He almost makes a fetish of facing reality as quickly as possible and reacting promptly.
Deming had some very productive ideas, but did “five whys” come from him or from Mr. Ohno? Toyota held about half of the stock value of car companies for a while and they seemed to have a lot of focus on the people, on listening to the staff while still focusing on getting good product out the door but only to meet customer demand, not to warehouse. Indeed, the breadth of what was deemed relevant was astonishing to other companies. Including a long term view.
Confusing, I say. Ah so, I have noticed that I learn more by willing to be confused longer. Now I am always confused.
I’m willing.
Read with interest and mostly agree. A couple of comments:
a) Agile is not technical nor mechanistic. “People and interactions over processes and tools” is the first part of the Manifesto, remember? That this great movement has somewhat degenerated – mainly because of money and ego wars that corrupted the minds (as well as infatuation with the corporations) – doesn’t mean it isn’t human-centered in its values and key practices. BTW – that those values were to some extent abandoned in pursuit of money and status is in a sense ironic, because this is also very human.
b) Judging the state of the profession based on just Standish Chaos report is dubious. Apart from the usual problem of the sources of this research it judges the project outcomes using the traditional PM success criteria – “on time, within budget, all scope”. Agile rejects this way of judging results as stupid and quite rightly so, because what matters once you have your software is not how well the process of building it adhered to the predictions made in the past but rather how well the end product fits your needs now, in the present.
c) What you call “a new frame” is not something that can happen solely in the realm of software development. Many problems you point out are a product of the contemporary socio-economic system. It is this system that is fundamentally inhumane, based on false perception of value and resulting in degradation of the human being to the level of “resource”. Any local change inside companies that have to operate within this system will be superficial and non durable until that system is retired and replaced.
I think this shift, this change of the system is near. It will be pretty much destroyed by its own wastefulness and idiocy – it will crumble just as the soviet communism crumbled. The difference is that socialist-capitalist hybrid now operating in the West is slightly more efficient than communism and therefore able to limp ahead a bit longer. The open question is how much longer it will.