Jim Highsmith proposed two simple strategies for successful software development: Build Less, Start Sooner.
Jim’s observation is genius, but I would add “Innovate Constantly”.
“Build Less, Start Sooner” is a catchy phrase but the thinking behind it isn’t new. In fact these strategies are an integral part of Lean-Agile. Lean-Agile promotes building less by prioritising requirements and limiting how many are worked on at any one time.
DSDM, XP, Scrum and Kanban all start with some kind of prioritised list of high level requirements. The thinking is that the high value items get built first so if the money dries up the maximum value has already been added. Or, put another way, the team might never get to the low value items.
But the methods also have ways to limit how much is worked on at any one time. In DSDM, XP, and Scrum timeboxes (Sprints or Iterations) are the constraint. The team takes on only as much work as will fit into a single timebox (supposedly). Typically velocity is used to predict what is achievable in that timeframe.
Kanban has a different approach. Rather than the rather artificial timeboxes Kanban limits the Work in Progress (WIP) explicitly. Roughly speaking a WIP Limit means the team can only pick up new work when they’ve finished something.
Starting sooner is also part of Lean-Agile, being embodied in the principle of delivering early and often:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
In practice the “early” bit of this means up front activities of a Lean-Agile project are shrunk to a minimum, just enough to get the development team working. And once the team are developing the software can begin to demonstrate its value to users (or not).
Jim suggests that organisations should stop debating whether to start a project and should instead invest in some development time to prove whether the project is worthwhile. He argues that the prototype will be cheaper than the analysis and provide a more definitive answer about the value of the project.
He doesn’t use the phrase but “Build Less, Start Sooner” is also a key part of Eric Ries’s approach to Lean Startups (2011). Eric adds an emphasis on testing, experimentation and measurement to ensure that the product being built is what the market wants.
I believe constant innovation is essential anywhere product development occurs, not just in a startup. In a software development context there is always an underlying product even if the product development is wrapped within a temporary organisation structure like a project or programme. One of the major problems with a waterfall approach to software delivery is the underlying assumption the team knows all the answers, both requirements and solution, at the start. In a Lean-Agile approach the team is actively seek to learn the answers over time.
“Innovate Constantly” is my catch phrase for that learning. Conscious product experimentation, constant fine tuning, and reinforcing success.
So whether launching a start up, running a project, or helping an organisation change via a programme, I recommend you Build Less, Start Sooner, Innovate Constantly.
Highsmith, J. (2012, 30 April). Build Less, Start Sooner.
Ries, E. (2011). The Lean Startup: How Constant Innovation Creates Radically Successful Businesses. Portfolio Penguin.