Agile thinkers focus on the product – and how we are intentionally adding value to a “software asset” and potentially how we manage our “portfolio” of software assets. Phase-Gated Delivery (some people call it waterfall) patterns allow us to “optimize” the work against the constraints – but do not allow us to optimize the value delivery in time. In fact, they push ALL the value delivery to the very end of the cycle. But in theory, because we can optimize the projects by minimizing the schedule and cost against a constant value output – the value can be had for less investment. Problems arise when – the actual value is realized over time (meaning the sooner the customer has access to a software capability, the sooner his actual costs go down or his profits go up).
The Phase-Gated pattern derives from manufacturing and construction, where there IS actually no value that can be realized until ALL the work is complete (e.g. the customer cannot inhabit the home, until the building inspector issues a certificate of occupancy or in the auto industry, the vehicle cannot be licensed and driven until manufacturing is complete). “Waterfall” is a response to the question, asked of early software development project – “Why can’t software projects be more predictable like civil engineering projects, like building a bridge?”
The truth is, software doesn’t often work like that. On a brand new application, there is certainly a “Minimum Viable Product”, concept that until there is a certain amount of value that the customer can realize there is no point in delivering “work in progress”, but the counterpoint is also true – that AS SOON AS the customer can get a certain amount of value from the product we should deliver it, because they can be getting value while we are delivering the next increment of value.
If you think of Phase-Gated as an assembly line where the work goes through each station and must be inspected before it proceeds to the next station it makes sense – but the way project management see this is not like an assembly line, because the assembly line works on more than one car at a time – it works on one car per station. And that is only final assembly – it can work on sub-assemblies in parallel for many cars. Agile works much more like an assembly line of “software capabilities” – rather than batching capabilities into a scope statement – and working the whole scope through each station on the line, having the inventory of work in progress sub-assemblies batching up at the end of each station – with the next station mostly idle until the batch is ready for them to process – It can form sub-teams and work on multiple capabilities if the capabilities are smaller, or assign the whole team to one larger capability as needed. And the order of deliver is not dictated by the efficiency of build, but by the value assessment of the customer. Of course there are negotiations and conversations – IT informs that one sequence will reduce cost – or reduce risk for some reason and the customer has the right to say I accept the additional cost or risk because the value is more important. (This whole line of thought came from my recent re-reading of “The Goal” by Eliyahu Goldratt).
The problem with batching
Since the Phase-Gated mindset is all about batching, there is a thought that “if a little batching is good, than a lot of batching is better” – This leads us to a project with fewer releases, because releases themselves are expensive so we better have enough value to justify the cost of a release. There is also batching anxiety – the fear that if my favorite capability doesn’t make it into the current batch, that funding may be cut and it will never be delivered. So the customer, in Phase Gated is not incented to prioritize what value he gets from the project, he is actually incented to cram so much in the batch, that it either breaks the budget and delays the project while we re-prioritize (gated estimates do this frequently) or it elongates the schedule so that before the release of capabilities into production, business change has already reduced the value of those capabilities.
Differences between Design, Build, and Deployment
There is another truth that is important. The design phase of a construction project, and the design phase of a manufacturing endeavor tend to be very iterative, and conversational, with a lot of trial and error and “experimentation” or hypothesis. But the “build” phase in both is highly repetitive and automated, and measurable. The “build” phase of software development is neither repetitive or measurable, and infrequently automated. That is because what our methodology calls “build” is more analogous the final stage of design from these other two industry examples. That is, once all of the big design decision are made, and the floor plan is drawn and the exterior perspectives are accepted by the customer, all of the utilities must be added to the plan, the plumbing, the electrical, the HVAC, etc. Software development is like this utility design – it is locating the boxes for electrical and the pipes and the vents and expressing how the structure will be supported, and the roof joints will be constructed and what style of windows will be installed, what type and quantity of building materials will be required. In software, the phase analogous to the construction/manufacturing build is actually a combination of humans pushing buttons on tools (compilers, make utilities, deployment scripts, etc.) This build process may occur frequently or infrequently, depending on how much human effort is required, but it is not the software development, programming, coding that the Phase-Gated life cycle thinks.
More thoughts on the Building Construction Analogy
In the building analogy the floor plan of the building is very much like the set of capabilities that the software must deliver – each room being a capability or a group of capabilities and the arrangement of the rooms is like the work flow or navigation of the software – understanding how capabilities relate to each other. That is not requirements. That is really product scope, the beginning of the product road map. That product road map in agile ultimately turns into the product backlog which is the catalog of ideas we have for how this product can add value to the customer. Requirements actually come much later – when we decide how each capability will deliver the value it was expressing. We don’t really need that until we are ready to design it.
The idea that we are building a complete product, one that will have value when it is complete is foreign to the project mindset. The project life cycle mindset is focused on the completion of the project. Much like the project manager on a building doesn’t necessarily care how much the building will be sold for, when it is finished, only that he was directed to ensure that it is built on schedule and within 10% of the estimated cost, and maybe receive a extra incentive if the building is completed early or under estimate. He is concerned with building material delays, work crew availability, re-work, building inspection schedule – in short anything that can idle a crew, drive up cost, or elongate the schedule.
Product orientation produces a completely different view of software development – a portfolio analogy
The project perspective (in my opinion) unnecessarily diminishes the importance of valuation of assets in the product portfolio – and focuses instead on optimizing “transaction costs” against portfolio. I think that the reason for this is primarily that costs are “hard” and valuations are “soft”. This is the same reason that customers tend focus on the schedule in any software project – because all of the other deliverables out of the project are much less “tangible” from their perspective.
As a portfolio manager – I am looking to increase/maintain the value of the portfolio through investing. Inevitably some investments grow the value of the portfolio over time, and some not so much. The trick is to measure the value growth of the assets – and to stop investing in those whose value is “naturally declining” because of technology movement (legacy platform) or because of market movement (business change). By thinking in simple terms like buy sell hold on each software asset – I recognize that I need to make decisions across the portfolio. Like a portfolio, I have multiple taxonomies that I need to make decisions against: Maturity/duration(depreciation, platform life cycle), Sector/Industry (Business Driver), Quality/Rating (Availability, Vendor Responsiveness, Fit for Purpose), Investment Class (technology platform, or insource/outsource).
Each asset has a cost (depreciating) and an expense ratio (annual expense to support), and a value (what would it cost the business to run without it – which could be calculated as business savings over the anticipated life of the application). As we invest, we should be looking to reduce expense ratio (cost to support) and increase the value either by extending the life or by further reducing the cost of running the business)
No Comments