Software development is creative work.
Outside of physical and metaphorical Silicon Valley, it is regarded as build work, focused on replicating discovered value. Doing yearly budgeting cycles, gathering extensive requirements before project starts, working in big batches and delivering in infrequent releases are telltale signs of build work.
This build metaphor fails when software is a vector for new value. Like when health enterprises have to create software to improve real world health outcomes.
To create, teams should develop in small batches aligned with discovery and design iterations.
The industrial age left an indelible imprint on the age of digital and software. The whole conceptual underpinning of software development management for build metaphor comes from time and motion studies to promote efficiency on factory floor — first published by Frederick W. Taylor in 1911. Taylor also emphasized documenting best practices and standardizing operations for scientific management of industrial work. Related to that, just imagine how many practices and methods (and cottage industries for coaching) exist around software development.
One of Taylor’s associates, Henry Gantt, invented Gantt Chart. Gantt chart, or more generally, a linear depiction of how a software initiative will go, is still a heavily used framework for planning and reporting. Everyone knows software development is anything but linear. Interestingly, Gantt also defined the concept of performance bonuses — an effective business management tool for incentivizing productivity.
These practices work great when you are just replicating discovered value. Take the example of a traditional ERP as an IT system. Depending upon how well you execute, it reduces cost and promotes efficiency. ERP best practices are well codified by now. You can create an elaborate scope, and just build on a deterministic timeline.
However, in the digital age, if you just replicate value, and just implement best practices, as I have explained before, there is no alpha. To differentiate, you have to discover and create new value. True for even enabling systems like ERP, and definitely true for direct sources of new value like Digital Health. Improving health is more than finding cost savings or creating efficiency. Creating better context for personal health requires discovery of constraints faced by patients, physicians and researchers as a constant process. You have to acknowledge that your model of understanding will be incomplete. Because real world human decision making is a complex system. Therefore, your solution design has to adapt as the problem understanding evolves in cycles.
If the understanding and solution evolve in cycles, it follows that software is also created in those cycles. This discovery-design-create cycle has to be in small batches, as each cycle is an attempt to find new and undiscovered value. Call it a Value Attempt. Some or more of these value attempts will fail since creative process is inherently inefficient. Within the physical and metaphorical Silicon Valley, this process is called as finding product-market fit. The words product and market mask the actual meaning though — which has to be iterative discovery of value for users. The real essence of creative software development is embedded in that user value, not just economic value. Economic value is an outcome of the process of discovering real user value.
For creative work, the planning has to be for value attempts, not estimating labor and projecting deadlines. Which is what the good folks who wrote Agile Manifesto had in mind. They were defining principles for “better ways of developing software”. Agile principles are entirely about creative software development.
But SCRUM won the methodology wars. And we are left fretting over sprints, ceremonies and retrospectives instead. Or sometimes left explaining our inability to be Agile, as being Hybrid-Agile. Despite widespread use of Agile (allegedly!!), it is conspicuous how separated development still is from enabling creative value.
So, below is a simpler prescription.
Before you worry about Agile, empower your teams to perform value attempts in small batch iterations.
And, don’t just build. Look to create value, for users, always.