Early Delivery Part 2 (from my old blog)

Early delivery has been considered the first commandment of agile.  In the principles behind the Afile Manifesto, the first paragraphs says:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Early and Continuous delivery of valuable software…  I take this to mean that we are going to structure a project (or delivery stream), such that usable software “features” are completed as frequently as possible.  The shortens the feedback loop and allows the customer to decide when sufficient value has been delivered to justify a deployment or distribution event.

Different software development situations, call for different decisions regarding deployment:

1) For a company whose primary presence is via software and/or the web, especially where the revenue is driven by the software (think yahoo or google), the frequent delivery of new or enhanced features is a way to drive customer satisfaction.  The product manager responsible for these decisions, strike a balance between new ideas, and enhancements or fixes to existing.  
2) For a more enterprise software application, used by employees of a company, the cost of deploying and retraining staff on new software features, and the criticality of correctness.  The business process change management around delivery of new software features may drive a very different roll-out cycle.
3) A software vendor, selling software to business units within an enterprise, or small businesses, may have yet another model for making decisions about deployment.  They may be driven by demands from new customers, and prospects, as well as a backlog of requests from existing customers.  
4) Software that is to be “embedded” in a physical device may have a completely different decisions cycle, and a much more rigid schedule.  The delivery of the rest of the device into which the software is to be embedded, and the revenue derived from the sales of the devices, completely determine the schedule.  In this model, partial delivery has little or minimal value.
5) Software that is deployed in industries that are heavily regulated (blood bank) or that have critical quality requirements (military/aerospace) may have much more rigid schedules that are driven by decisions made well before the development starts.  In this model, the ultra-high cost of quality assuranceand regulatory certification reduces the value of partial delivery to near zero.

It is easy to see why the value of agile principles is readily apparent to some, and a complete mystery to others.  It is the decision model that works in between need and deployment that determines the value of early or frequent delivery.  From a whole project perspective, this is clear.  But let’s look from a intraproject perspective.

Early Delivery (from my old blog)

Glen Alleman of the Herding Cats Blog in his post “Make Speed Not Haste” has once again taken an agile concept out of context.  In this case, it is about “early delivery”.  

“Instead if seeking to be early how about seeking to On Time. The planned need time. The date that the plan shows we need this item? Just having that date is not sufficient of course. The date needs to have cost and schedule margin. How much, that needs to thought through as well.
    Having worked on large complex projects with software, firmware, hardware and humans all interacting a critical question is always asked:

If we show up early can all the other elements of the project to the right of this date, be shifted to the left?

If not, it’s a waste of effort to show up early. And there is likely a downside to doing so.”

In Glen’s post, he sounds like he equates early delivery as equating to “ahead of schedule”.  This is not, in fact, what the agile community means or intends.  Agilists who talk about early delivery are describing the process of scheduling incremental delivery to expedite the most valuable, risky, or juicy features of a software product so that they can be deployed, tested, or sold, as early as possible.  The notion is that a – the shorter the timeline between business need and delivery, the less likelihood that the business will have changed out from under the requirements.  The faster we can deliver product, the faster we get paid.  The faster we get something working, the faster we can validate our design assumptions and incorporate feedback into the remaining features.

Most of all early delivery is about arranging the sequence in the schedule, not working out of sequence, or ahead of shedule. 

Not too long ago, I saw an e-book “Rocks into Gold” by Clark Ching that ties this notion of early delivery to creative solutions for the economic crisis.  

The perceived evils that the concept of early delivery is trying to address occur in projects with long timeframes between the identification if business need and the delivery of value.  The evils that can be pervasive in this context are:

1) Your product is obsolete before it is delivered – this occurs when the business need changes but your deliverable does not.  Risks around too little, too late.  

2) Your project is canceled before it is complete – market or economic conditions call for reduced spending, and the project’s doesn’t show return on investment meaningful ROI until the company is projected to be bankrupt.

3) Your product is delivered, and is not well received in the market or user community, you are then required to make many modifications that delay the delivery of additional value, and reduce the return on investment.  (Think windows vista).


In his excellent management skills blog, Tom Foster posts a brief series on Procrastination. Brad, a middle manager, procrastinates and brings the organization to a state where they are months behind on a major project. Tom spends a lot of time talking about time-span, as a predictor of management qualification. I appreciate this, as it has made me more aware of my limitations.

I can’t help but ask what is someone to do, to help an employee (or manager, supervisor, or executive) to improve their time span. There are many symptoms of a person who is expected to work beyond his time span. In my experience, most people, get used to working within a certain time span. The longer they are in a role, without specific challenges to increase that time span, the harder it will become for them to improve this capability.

Here are two tools that can be coached into a person, to help them become more effective at longer time span tasks:

1) Progressive Plan Elaboration – Start with a plan that is at a very high level, where the plan deliverables are each about the size of the person’s normal time span without worrying about smaller details. Order these deliverables in a reasonable sequence without worrying about smaller details. Agree on a schedule for starting work on each of these deliverables, and make sure that the plan includes a task to plan the smaller details of each deliverable, before the work on that deliverable is scheduled to begin. This technique works because most of us get hung up around the many details, rather than the basic work structure. We worry about things that we won’t know until we have done some of the work, and so we can’t always plan in detail in advance. For some people who think from the details up, this can be paralyzing, and the top down approach, ignoring the details until we are close up can really help.

2) Iterative Measurement – There are some times when the work cannot be broken up into discrete deliverables, other times, when there are many deliverables being worked on in parallel. Project Plans with these features can be difficult to organize, so we can break things into discrete time boxes or iterations. This specific work (list of tasks) will get done in this time frame (use a iteration time span that is within your graps). Make sure that you are planning each time box in advance, enough to make work assignments and manage schedules.

How could Brad, in Tom Foster’s post, use these two approaches to reduce the impact of procrastination? It sounds like Brad has a team of supervisors who can get the work done. He could probably work with them to set up a deliverable based plan, and have them work the schedule, and report the details of the plan for each deliverable before the work on that deliverable is stared. Alternatively, he could break the work into time boxes that he can manage (2 months) and set goals that are 2 months out and work toward those, re-establishing the goals, every months for a 2 month period. This approach could be called “rolling-wave” planning because there are overlaps between the iterations or time-boxes. If every month, I plan two months out, then I can respond to problems in the now, and adjust the plan, before a crisis becomes intense. By measuring my progress each month, I can feel myself starting to get behind, and I can adjust, rather than simply waiting for time to run out and making a mad dash to the goal.

Why “Velocity” Is Not As Bad As They Say

Glen Alleman of the Herding Cats blog is one of the most experienced project managers I have ever read.  His background is amazing.  He is bright, and has practical knowledge of projects that I will never have.  However, he is missing the point on agile and velocity.
I recently read his post “Simple Never Is” and have this response to offer.
I have been working on software projects for some 20 years, and while I am not a practitioner of any formal agile methodology either project management or software development, I have been exposed to incredibly ad hoc practices in managing software projects.  I agree with Glen when he says that agile (spokesmen) railing against traditional project management have never been exposed to good traditional software management practices.  Most project managers that I have worked with, take a couple classes, manage a couple projects, and maybe get a PMP cert and then do the same thing over and over, with varying results, because they personally suck, not because their methodology is fundamentally flawed.  I have been this project manager, and I sucked as well.  I think that most of this is because the organizations that I have worked for did not sponsor, fund, or require good project management practices.

Agile, and specifically scrum, are a reaction to the suckage.  It is the project team reacting to the fact that project managers don’t use practices that help.  What scrum and other agilish methods and practices around project management do is help the team remove two specific smells from project management:

  • plan fiction – the two most prevalent fictions I have experienced in project plans are a) plans that don’t reflect how the work is really done b) capture of partial task completion in percent based on the developers opinion.  Neither of these conditions necessitate a deliberate deception, but can be the simple result of laziness or communication issues.  
  • inconsistent plan maintenance – when at the outset of a project, there is no establishment of team values and rules around how estimates will be performed, adjusted and maintained in the plan, how the plan will be elaborated, what acceptable task effort is.  When there is no enforced measurement frequency, or commitment around reflecting the current work breakdown and task sequence in the plan, even though it changes from week to week, then the plan itself becomes useless.

The thing that Glen is missing is that velocity is not a project completion measure, but a team productivity measure.  Agile project management is more about team than project.  Thus it makes sense that the most visible measure is team productivity, not project progress.  From a project progress perspective, velocity is exactly what Glen says – predicting the future by evaluating the past.  He calls this driving by rear view mirror.  Velocity, however, is good for the team.  It tells them whether their current pace is likely to match the published/committed schedule, and when measured frequently enough (like every week), it tells them early enough, that they can decide to adjust something to stay on schedule.  

Velocity is a factor that is involved in the measurement of current projected duration.  Current projected duration is a simple measure – remaining work / average velocity = projected duration.  This measure has a bunch of assumptions:

  1. productivity is the primary predictor of duration – this is a big leap, but I think that this is what Glen reacts to, because there are not many large projects where this is true of the project overall.  However for many software projects during the development milestone, the team is focused on this, and are held accountable for this and this alone.
  2. there is enough parallelism in the plan that sequencing of task execution is not rigid – that is the team can reassign tasks and resequence tasks to mitigate the impact of delays on one task or deliverable.
  3. the plan is updated at least as frequently as it is measured –  As the work goes on, the plan is updated – newly discovered work is added into the plan, and work that is determined to be less, or not necessary is removed from the plan.  that is, remaining work is not only adjusted by the work complete, but by periodic adjustments to task estimates, and by addition of tasks when new work or re-work is required.

I think that Glen’s characterization of velocity as a “rear view mirror” and “yesterday’s weather” metric is largely because of his believe that past performance is not always a good indicator of future results.  While this is true, velocity and current projected duration are useful metrics that can be applied in many ways to measure productivity and schedule.  Glen says that velocity is a level of effort measure, and I disagree.  Here’s why:

Remaining work is always an estimate.  Properly calculated, velocity is the sum of the effort estimates for the completed tasks for a period, and requires that the task estimates not be adjusted during the measurement period when the tasks are completed.  Velocity is meaningless if not used to project duration, therefore velocity must be in the same units as remaining work.  

If calculated this way it is not, as Glen suggests, a LOE measure, but much closer to EV, because it approximates the budgeted effort.  The thing about velocity that many project managers struggle with is that it is not precise, and it doesn’t contemplate many aspects of the project timeline, only team productivity.  I believe this is because agile disciplines are mostly focused on the behaviors of the team, and increasing/maximizing team productivity, and as a result, the delivery of value by the team.

Here are some things that I have done with velocity (in combination with other measures):

  1. Working backward from an published end date and remaining work, assuming resource allocation is constant, we can calculate required periodic velocity – or the amount of work that must be completed per period (week?) on average to acheive completion by the end date.  I use this to ensure that we are planning (committing) to complete enough work each period (week) to stay on schedule.
  2. We can capture personal velocity metric to capture each team members average productivity, versus their own estimates.  I have measured velocity vs. committment to help team members plan more effectively, and to help the team re-allocate work to stay on target.  This is a great help to managers who want to coach developers into higher performance, on both development and estimation.  

In my experience, velocity alone is insufficient for many projects, as it doesn’t really contemplate the complexity of external dependencies, interactions between teams, etc. When these factors are in play additional measures can be devised or adopted to present conditions where the project is at risk.  When my team is largely in control of the project and there are fewer connections and dependencies, I have experienced the benefit of this simple measure (velocity) because it is easy to understand, and difficult to fake out.  These two factors allow a development of trust between project manager and team and a focus on solutions (adjusting the plan).