Means and Ends
How often do we try to “improve” our product and services, and the revenue and profit therefrom (i.e. the ends), and how often do we try to improve the way the work works, the way we develop those products and services (i.e. the means)?
Folks have needs related to the way the work works, in many ways just as profound as the needs they have of the products and services (features) resulting from that work.
To illustrate what I’m talking about, here’s a short list of some of the needs folks can have related to the way the (product development) work works:
- Ongoing information (development schedules, quality levels, costs, plans, etc.)
- Confidence (e.g. that milestones and Due Dates will be hit)
- A sense of purpose (are we spending our time on stuff that matters?)
- Connection (e.g. human connections, relationships between people)
- Etc. (and lots more possibilities in e.g. this Needs Inventory)
This post is an invitation to apply the same considerations to the explicit and intentional design of the way the work works, as we do to the way our products or services under development work.
In my previous post, “Antimatter Evo”, I explored the twelve principles associated with the Agile Manifesto, and proposed a way to radically simplify those twelve principle down to, essentially, one (“Attend to folks’ needs”).
May I invite you to consider the impact on your development efforts of applying the same principle – the Antimatter Principle?
Does your current approach – to defining and improving the way the work works – attend to the needs of the people that matter?
In the typical product development situation, each new product (or service) that enters development is handled much like all those which have gone before. Outwith major revisions to the way the work works (say, adopting a revolutionary new approach such as Agile), incremental improvements to the means of development can occur, and occasionally do. Yet with both Kaikaku (revolutionary change) and Kaizen (incremental change), change is rarely connected to better serving the needs of the “folks that matter”. Put another way, change most often serves the product and its users, and rarely the folks impacted by the way the work works.
How blind is your organisation, presently, to the ability of its development efforts to meet the relevant needs of the people involved in those efforts?
What if we applied ourselves to understanding the needs of the people that matter, as they pertain to the way the work works? What effect might that have on the social dynamic, the relationships between different people and groups, on productivity, and on the general success of our development efforts?