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

The October 2002 National Intelligence Estimate, Iraq’s Weapons of Mass Destruction Programs, begins:

“Iraq has continued its weapons of mass destruction (WMD) programs in defiance of UN resolutions and restrictions. Baghdad has chemical and biological weapons as well as missiles with ranges in excess of UN restrictions; if left unchecked, it probably will have a nuclear weapon during this decade.”

The nonpartisan Council on Foreign Relations concluded:

“(M)ost of the key judgments have since been debunked as inaccurate, false, or misleading. ”

“According to the Senate committee’s July 2004 report, analysts who wrote the NIE relied more on an assumption that Iraq had weapons of mass destruction (WMD) than on an objective evaluation of the information they were reviewing. This group-think dynamic, the report states, led analysts, intelligence collectors, and managers to ‘interpret ambiguous evidence as conclusively indicative of a WMD program’ and led them to ‘ignore or minimize evidence that Iraq did not have an active and expanding program.’”

A vast majority of senators did not read the whole report but only the summary or how that summary was represented by the administration.

“It’s probably pretty hard to say with 100 percent certainty how many read it,” the senior staffer said. “You can say with 100 percent certainty that it’s less than 10.” — The Hill

The unlikely became possible, the possible became probable, the probable became fact and the “facts” rallied a country to war.

Posted: July 13th, 2008 under development.
Comments: none

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

Not to get super preachy on you all, but sometimes I think we’re full bore on the wrong mission.” — ‘Agile Shop’ by Dave Laribee

As people, we embrace change we can ourselves effect. Our conversations about value turn to story writing. Our conversations about competitiveness turn to scale.

But we risk engaging the surface of things and not the things themselves. Means to what end?

As brother bee preaches, I stand before you penitent of the sin of local optimization.

In my last job, I led a development team. We were an agile team in a non-agile company. We were engaged in the effort of years, championing organizational change bottom up.

In spite of everything we’d built — an excellent agile team, a direct relationship with our CEO, visible release backlogs and delivery — the business remained opaque. It was unable to rally to us and unwilling to provide the transparency and focus we needed to effectively rally to it.

As a result, our timeline didn’t match the life-cycle of the business. When it was acquired, our efforts were shelved and we all moved on.

An agile team in a non-agile organization is not agile enough.

Posted: July 6th, 2008 under development, scrum.
Comments: 1

I helped my in-laws with online NW Airlines check in. Turns out the resulting boarding passes don’t page break correctly when printed from a mac. I had to increase my viewing font-size in safari in order to avoid passes running off page one and continuing on page two.

How easy could it have been to do a print format that works? They must not have even tested on macs nor did they alert me my browser was invalid.

Something else - the url of their thank you page is “CheckInFailed”

Posted: June 1st, 2008 under development.
Comments: none

Construx has a white paper revisiting Stephen McConnell’s Software Development’s Classic Mistakes.

In it, they list ten mistakes most likely to produce catastrophic or serious consequences.

Half of them speak more to executive and product management than development:

• #1 unrealistic expectations
• #2 weak personnel
• #4 wishful thinking
• #7 lack of sponsorship
• #10 lack of user involvement

Given my experience of organizations that means projects are marked for failure well before agile methods are even applied.

Under these circumstances, we can hope frequent delivery will either morph the project into something more valuable or cause it to die a quick and merciful death.

A better answer disperses transparency, collaboration and continuous improvement from the team room out to sponsors, stakeholders, support units, suppliers, customers and end users — from development and project management to economies.

Posted: May 16th, 2008 under development.
Comments: none

Just posted a reply on the Scrum Developers Yahoo Group. Keeping up with that list would be more effort than becoming a certified scrum master.

What I am interested in is to find out how graphical and interaction designers can be eased into Scrum development.

In my previous team, our UX director, Bob Calvano, mixed in with the team: proposing UI elements in mockups but also pairing with developers to collaborate on implementations. The team and UX director shared decisions but the UX director retained authority over them.

The team and product owner learned to defer to him on thorny questions of emotion, aesthetic and interaction particularly where the product owner had no clear sense of how the decision impacted tangible customer value.

The team had to learn how to deliver constructive feedback on UX. They had to learn how to express personal opinion in that context.

The UX director needed incredible patience taking in well and poorly delivered feedback. He had to understand his own process well enough to use day to day input to enable his own creativity rather than shut it down.

We evolved this relationship in a small team in an environment of high trust and we took months getting there. He came from a more traditional agency approach but he did have a personality suited to collaboration.

He eventually left our team to become an Interaction Design Director at one of the top agencies. He did so because the high profile of the work and pay were irresistible, so this experience didn’t hurt his career progression or his ability to work other ways. Though I know for a fact he misses that team and is returning to a smaller environment where he can recapture that collaborative experience.

thoughts from people who have read Jeff Patton’s book and what they think about how his ideas fit with Scrum.

Haven’t read the book yet. Talked to Jeff about his ideas at Agile 2007 (He was my adviser on my presentation on product ownership) and at the Fall Scrum Gathering.

High praise for his thinking on user experience as a precursor in product development (why) not simply as part of execution (what).

We tend to focus on story writing as the first tangible step agile plays in product conception. There are whole worlds of collaboration in terms of understanding who the software is for and how it solves problems for human beings that should come first.

Jeff Sutherland says the vast majority of teams run Scrums without real backlogs. How many of those few product owners that have backlogs derive systems and features from a user-centered perspective?

Hoping Jeff Patton will give us practices to tackle that problem.

Posted: April 26th, 2008 under development, scrum.
Comments: none

Kallokain wrote a rebuttal to my post questioning the value of productivity metrics to justify agile.

In a recent article Ken Judy takes the stand that agile software development should not be adopted on the grounds of higher productivity. The reason for that, Judy claims, is that there are better ways to justify adopting agile than with hard numbers.

I can sympatize, because I have worked in my share of software development projects where the measurements did more harm than good. Nevertheless, I believe Judy is wrong in this instance. Most organizations measure the wrong thing. That does not imply that measuring is bad in itself. (read the post)

Just to be clear, my objection is not that agile should not be justified by hard numbers but that I haven’t seen a metric for productivity gain specifically that both stood systematic scrutiny and was economically feasible for the average business to collect.

In my experience, measures that are tied to some non-revenue related abstract concept of “productivity” such as lines of code, story points, etc. are more problematic than helpful.

My point about velocity is that it is a measure that should be a feedback system back to the teams and becomes problematic if it is considered some sort of intrinsically meaningful measure that can be reported to senior executives (as in “We completed 20 story points last iteration, 25 this iteration. We’re five story points more efficient!”)

I agree that the ultimate measure of success in business is profit. I understand that any business decision should somehow influence revenue gains or hard dollar cost savings.

The problem with justifying an agile adoption based on revenue gains is there are so many other considerations that attempts to credit any single factor become dubious.

Cost savings need to be real not theoretical. Who did you lay off? How much budget did you give back based on agile adoption? Jeff Sutherland has a paper that does show significant cost savings using Scrum. The subject company was a CMMI-5 organization and there commitment and rigor to measurement was higher than most companies would support and is cost justified based on the government regulations they perform under.

If someone can propose a relevant metric that is economical for a small to medium size business to collect, that can be measured over time in small enough units to show increased performance due to specific process changes, that has some relation to reality that can be meaningfully communicated to senior managers, and doesn’t create more problems than it solves, I will be happy to consider it.

Posted: February 19th, 2008 under development.
Comments: none