Posts Tagged with value

Agile practices claim to delivery greater value to the customer.  This claim is based on agile tendencies to deliver software capabilities more frequently, which in and of itself, means that the customer starts realizing value from our efforts sooner. OK – this one is obvious. Traditional phase gated life cycles effectively require you to do all the work through each phase – all the requirements, all the design, all the development, all the testing – before any value is actually delivered to the customer. Agile practices – actively proclaim (this is not a passive benefit, but an assertion of the philosophy) that it is better to finish the smallest increment of usable software capability and deliver it to the customer as early as possible.

While agile does not claim to have invented this concept, it does seem to have taken it to the extreme. Here is the “thing” – in a corporate culture where results are measured in quarters and not years, the faster we can implement even incremental improvements in work process, the faster we can show results (cost savings, risk mitigation, staff headroom, etc). The balancing factor is how frequently/rapidly can the organization assimilate change. Yet, even in an organization that is not particularly good at change management, the early delivery of value emanating from agile practices, puts the organizational management in the drivers seat. You can have a “pile” of completed, validated software changes ready to go, and you control the pace of change by scheduling releases. Whether the company wants two releases per year or twelve doesn’t matter to the team – because they just keep piling up the value and the customer controls when it is released into the enterprise. The customer controls the sequence of value that is being piled up, and the customer controls the timing of when the pile is rolled out.

Here is how it works pragmatically:

1) The customer constructs a list of valuable changes (scope).
2) The customer ensures that the list of changes are organized by sequence of delivery (converts scope to a backlog).
3) The team and the customer analyze (write requirements and estimate) these valuable changes in sequence and decide how many of them can be done in a measurement milestone (sprint).
4) The team delivers the changes (designed, coded, tested) for customer review.
5) The customer reviews the delivered changes, and adds any observed deficiencies to the backlog.
6) Repeat steps 2 – 5

One of the things that agile does, simply by sequencing by deliverable value, rather than by skill or life cycle phase, is that it makes it easy to decouple releases from life cycle phases. In a phase-gate lifecycle, I can’t release until all phases (analyze, design, code, test) are complete. Using an agile lifecycle decouples release from phase, because it assumes sequencing by deliverable, instead of sequencing by activity. Other than the “extra” activities required to release (regression testing, data conversion, code migration and deployment) the software itself is continually in a “releaseable” state.

This change in sequence assumption actually gives the “customer” more control over what order value will be delivered in, and allows them to alter the order of value delivery without loss of productivity. This is true, when the order is not altered during a measurement milestone, but for the next milestone, because very little work is done on deliverables before the milestone begins. In a phase-gate life cycle, all of the analysis is done for all deliverables before the design starts, all the design is done for all deliverables before the code starts, all the coding is done before the testing starts, etc – so the later you alter the scope (or change the sequence by swapping one scope item for another) the more completed work you are “throwing away”, which becomes lost productivity or waste. This is why everyone in phase-gate life cycle works so hard to avoid change in scope – we use change control because we recognize that change after analysis is complete means lost productivity.

Now of course WE ALL KNOW that it doesn’t really work like that in phase-gate life cycles – phases are allowed to overlap, and plans are optimized for dependencies, and we can carry risk of unknowns for later analysis or design on our projects – but because of the assumption in sequence by activity inherent in the life cycle model, these things add complexity to the planning process, and to the measurement process, and to the execution of the project because they are execptions, rather than the rule. This complexity itself has a cost in lost productivity and extra coordination or collaboration. The point being that because overlap and deferred analysis are inherent to the agile lifecycle, they do not increase the complexity of the project, plan, or execution, and the collaboration and coordination points are baked into the practices designed to implement the agile life cycle.

The key difference between agile and more traditional phase-gate life cycles is the key assumption around delivery sequence, and all of the implications emanating from that assumption, especially the greater control of delivery of value afforded to the customer. It is this greater control over the delivery of value that the term agile describes – agile life cycles respond to changes in strategy, direction, market conditions, available budget much more gracefully, and with much less drama than traditional phase-gate life cycles. This is a direct win for the customer, and as such, can be sold as an advantage for the provider.