Most organizations use annual funding cycles and large projects to undertake work. These create planning cycles that are too long to adequately react to market changes.
Agile businesses budget at a higher level of abstraction. They budget around a desired business outcome instead of requirements or a highly detailed scope of work.
Agile businesses also use stable teams that stay together for extended periods of time. These teams become well-oiled machines that learn how to leverage each other’s strengths, how to communicate with each other, how to work together, and how to get things done.
Projects vs Product Lifecycles
Historically organizations used projects to fund and build products which they then handed over to sustainment groups for support. These days software is becoming more critical to the business operation of every organization. Banks are becoming IT companies with financial products, cable providers are IT companies who also offer infrastructure services along with their digital offerings. These software projects should never “finish” since they are core for customer engagement and revenue production. This is the new era of ongoing products instead of temporary projects.
The Old Way: Projects
Projects are typically estimated and funded upfront or based on a calendar year. For example, Project A may receive funding for $3M to cover its estimated 2-year development cycle, or $1.6M for this year and $1.4 for next year based on its project spend. Traditional project teams complete development and handover to a sustainment team. This team needs to complete knowledge transfer before they can successful sustain the application through minor upgrades for the remainder of its lifespan. If major changes are required a new team is spun up, they learn about the product, make the changes and then hand it back to sustainment. Each handover and knowledge transfer takes time, loses valuable information, and reduces accountability for success.
The New Way: Products
Adopting a longer persisting product view of applications and services better matches the reality of today’s digital business. By creating a single, multidisciplinary product team for its development and sustainment we avoid the knowledge transfer and accountability losses of handovers. We also create stable, high performing teams who are accountable for a products success.
Switching from projects to products involves several core changes.
By creating stable Value Stream teams we can achieve much higher levels of efficiency and productivity. This far outweighs the supposed flexibility coming from pulling people from work and moving them around to different projects. The ‘fungible resource’ model of moving people causes teams to be in a constant state of storming/forming/norming and makes it almost impossible for them to achieve the ‘high performing’ state.
In addition, fixed Value Stream teams are much easier to manage financially. A fixed Value Stream team has a fixed burn rate. This makes estimation and budgeting much simpler.
Venture Capital Funding Model and Real Options
Budgeting product based development broadly follows the model used by entrepreneurs and venture capitalists when starting and funding companies. At regular intervals, for example quarterly, the product governance board meets to review the performance of product teams. They use outcome based metrics such as profit/loss, customer engagement score, and market share to decide whether to continue funding the product team based on its current burn rate. They may also decide to increase or decrease funding based on its performance.
Minimally Viable Teams made up of an architect, a BA, a developer, a QA can be formed to vet new ideas. Many entrepreneurs start with minimally viable teams because they lack the money to have for any more. The constraints imposed by limiting resources force entrepreneurs and their teams to be innovative and move quickly, unencumbered by coordination drag. If the entrepreneurs’ efforts are successful then they will start seeking additional investment.
VCs don’t expect all their investments to pay off. Some investments will, most won’t. Most will go fail, but those that become profitable will more than offset the losses incurred by those who don’t. Fail fast, fail cheap. Filter out the ideas that don’t work. Learn and salvage what can be salvaged.
Product governance board faces options when reviewing an existing team to continue, expand, shrink or close. However they also fund minimally viable teams to explore candidate features which creates a future option.
If we do not explore an idea, then there will not be an option in future. Creating a team and letting it work on the idea for three months might only produce learning without anything of immediate commercial value. However at the end of the three months there is an option which would never have existed had the team not been formed.
Each feedback loop represents a point at which an option can be exercised, the feedback evaluated and the next decision made. Continuous product delivery aims to create many options and efficiently fund or discard them at the most efficient time. This equips Agile businesses with the processes and tools to evolve faster than their competitors.
Blog Article: Martin Fowler, Products Over Projects
White paper: Emergn, Moving From Projects to Products
Book: Allan Kelly, Continuous Digital: An Agile Alternative to Projects for Digital Business
Book: Shane Hastie, Evan Leybourn, #NoProjects: A Culture of Continuous Value
Scaled Agile Framework Lean Budgets