Constraints

(July 2008) “There are some 146,000 U.S. soldiers in Iraq, down from a peak of 170,000 in 2007″ — Reuters

“Although no decision has been made, by the time President Bush leaves office on Jan. 20, at least one and as many as 3 of the 15 combat brigades now in Iraq could be withdrawn or at least scheduled for withdrawal, the officials said. The most optimistic course of events would still leave 120,000 to 130,000 American troops in Iraq.” — NYT

(July 2007) “More than 180,000 civilians — including Americans, foreigners and Iraqis — are working in Iraq under U.S. contracts… The numbers include at least 21,000 Americans, 43,000 foreign contractors and about 118,000 Iraqis — all employed in Iraq by U.S. tax dollars.” — LA Times

Goal

“(O)n my first day in office, I would give the military a new mission: ending this war… ensure that our troops were redeployed safely, and our interests protected.” — Barack Obama

Estimate

“Military experts believe we can safely redeploy combat brigades from Iraq at a pace of 1 to 2 brigades a month” — Barack Obama

Target

“…that would remove them in 16 months. That would be the summer of 2010″ — Barack Obama

A lot of attention has been placed on the target of sixteen months and whether Obama will stick to it. Obama has said, “I am going to do a thorough assessment when I’m there,” he said. “I’m sure I’ll have more information and continue to refine my policy.” This has been called a “flip flop” or “reversal”.

But this is a simplistic interpretation of both Obama’s position and the nature of a target. The target is informed by the estimate in an attempt to attain the goal. The target should change as new information provides better estimates and if the adjusted target better attains the goal.

It is not the target but the estimate and goal that need to be debated.

Who are the military experts? Does this estimate represent a consensus among these experts? What are the assumptions surrounding this estimate? Does a range of 1-2 brigades per month represent the full range of uncertainty? What are the set of risks that might scuttle this estimate?

What does safety mean in the context of a war? What does it mean to ensure our “interests” are “protected”? What kinds of events would threaten our interests and change the redeployment schedule?

As long as our public debate focuses on positional bargaining around targets we will continue to miss the point.

Posted: July 15th, 2008 under development.
Comments: 1

A product owner describes work. The team estimates it. The product owner sets a delivery target. The team commits to it.

Estimates

People are good at estimating their own ideal effort on well-defined work within their realm of experience.

People are poor at translating ideal effort into calendar days, estimating how long others will take to perform work, and estimating work that is either poorly understood.

Estimation is time consuming with diminishing returns so the effort should be managed to cost, i.e. time-boxed. That is why Agile practices invest more energy and place more value in estimating immediate work than on more speculative work farther out.

All estimates contain uncertainty. Industry research says an upfront estimate can be 25% to 400% of actual performance. The range of uncertainty is deeply dependent on context: how much work is involved, development lifecycle, experience with the particular work, shared experience within the development team and maturity of the management organization.

It is poor practice to “pad an estimate”. Padding doesn’t match the scatter that surrounds upfront estimation. For large scopes of work a developer should express an estimate as a range of uncertainty (i.e. “four to eight months skewing to between six and eight”).

Middle managers should not pad or trim a developer estimate. That is undermining the developer’s authority and making them un-accountable. The estimate is the estimate.

That doesn’t mean that the business doesn’t make planning decisions based on estimates. It means those decisions are separate from, though informed by, the estimate.

Targets

When a product owner or sponsor takes a developer estimate of 4-8 months and sets a release date six months out, they are moving beyond the estimate to set a business target. This is a judgment of what expense and time to market promise sufficient value to justify the work.

The product owner is using the developer’s estimate to inform themselves of the risk they are taking with their investment. An aggressive target within an estimate with high uncertainty is a larger risk than a conservative target on a more certain estimate.

Commitment

Setting an achievable target and owning that decision, communicating the rationale for your decision and having that rationale inform your priorities earns trust and rallies a team to deliver.

It’s the targets, stupid

Don’t set arbitrary targets. Don’t burden yourself with unnecessary risk, demotivate your developers and thoughtlessly constrain the value built into your software.

Do set meaningful targets. Take calculated risks, manage costs, partner with your developers and know what and when you need to deliver to your customers.

It’s not an estimate. The developer cannot assume your risk.

It’s not a commitment. You’ve got to earn that.

At the end of the day, the product owner is responsible for understanding the business climate, understanding the customer, describing and prioritizing the work, and managing the company’s investment to a successful outcome.

Posted: July 10th, 2008 under development, scrum.
Comments: none