Taking a short break from my customer series to ask a silly question…

What are you good at?

This Thanksgiving week, I want to think about things we can be thankful for.  So lets start with those things that help us be valuable to those around us.Continue Reading

Smaller Bets (Story Elaboration Pushback)

It is always better to spend the least amount of (time, effort, money) to get what you want, right?  If I can get a tasty meal for $10 why

McD's Dollar Menu Combo - Buffalo Ranch McChicken + McDouble with Coke = $3.64
McD’s Dollar Menu Combo – Buffalo Ranch McChicken + McDouble with Coke = $3.64

would I pay $30 or $200 – for the experience of eating – that isn’t about taste.  That is a different thing, isn’t it.  We have different priorities for eating – being full, healthy, tasty, being served, fast service, being able to relax, a pleasant experience, being able to brag about my meal/experience.  Each of these is a different reason for selecting a dining experience. Each of them is valuable to some people some times, but not all people all the time.  The way we choose to spend our money to eat is not that different than the way we choose to spend our money on software capabilities; there are different reasons why we prefer one capability or a means of delivering a capability over others.

These are the principles that I use to guide my story elaboration – and thus my ability to challenge those who would ask me to do more than the minimum…Continue Reading

Packing The Box

Do you remember the last time you moved?  Do you remember packing some boxes so full, that they were too heavy to lift after you were done?  It happens.  Especially books and vinyl records.  When you are packing “regularly shaped” high density items, the volume of the box may be too large to contain the weight of the items.  Or it may be that the lifters (I mean you) may not have enough momentary work capacity (strength) to carry the box.Continue Reading

Agile Value Delivery

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.

Running Agile

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.

Units of Value

Planning a software development project is difficult. There are the typical issues: the changing face of technology, abstractions and generalizations, process maturity and resource competency. But none of this gets to the heart of why planning a software development project is difficult: because all of these things assume that the customer actually knows what they need and can articulate that need in a meaningful and comprehensible way; that the customer can describe the value that they want to get from the project when it is complete.

Depending on the methodology, analysts have constructed numerous abstractions to "organize" and "articulate" the value demanded by the customer. We call these "requirements". "features", "stories" – It really doesn't matter what you call them, as long as you recognize that they are the unit of value delivery around which you build your plan.

Your planning methodology (in conjunction with your software development methodology) must describe a way to turn these units of value into units of work. There are rules and assumptions that must be established about the content and structure of units of value that allow them to be converted into units of work. These assumptions and rule must be understood by analysts and customers who are defining the units of value, and by the technicians that are converting them into units of work. It is these rules and assumptions that allow your plan to accurately describe how you will deliver something of value to your customer, and allow you to communicate your progress towards the goal of that value delivery.

If you want to start somewhere to improve your software projects, start with defining the units of value, and the rules and assumptions necessary to convert them into units of work.