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.

Tag(s): estimation
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.

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.

Tag(s): agile, estimation, product ownership
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.

Tag(s): agile
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”

Tag(s): usability
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.

Tag(s): agile, failure, management, mistakes, product ownership, scrum
Comments: none

Fail fast is a technique for improving the quality of software:

“failing immediately and visibly” sounds like it would make your software more fragile, but it actually makes it more robust. Bugs are easier to find and fix, so fewer go into production. – Jim Shore

Scrum aspires to a fail fast approach to building software.

It describes practices that surface problems:

• a backlog prioritized by the product owner and estimated by the team (accountability)
• short iterations
• frequent retrospection
• a role dedicated to removing impediments

It champions values that motivate individuals to address problems:

• delivering business value
• collaborating with customers
• empowering teams
• building quality in
• continuous improvement
• courage and honesty (a refusal to hide risk)

Possessing these values and practices, an organization is less likely to overlook or tolerate dysfunction when it materially affects the setting and achieving of project goals.

1. risks are identified before they become problems
2. simple problems are detected and resolved quickly
3. thorny problems are mitigated
4. catastrophic problems are aired to all concerned parties (informed consent)

Cases #1-3 increase a project’s chance of creating value.

Case #4 compels an organization to cancel a doomed project.

All four cases represent a better outcome for the business. Assuming that business offers value to the world, that’s better for our end users, our reputation, and our society.

Immediate and visible failure. Much preferable to hidden, prolonged and inevitable failure.

Tag(s): agile, failure, quality, risk, scrum
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.

Tag(s): agile usability, design, 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.

Tag(s): agile, metrics
Comments: none

To help some peers advocate for agile adoption, I prepared an experience report to demonstrate how my old team benefited from XP and Scrum practices. This is an extension and refinement of an earlier post on the benefits of XP.

Team Cohesion

Before and during our agile adoption, I informally administered the Gallup Q12 employee engagement survey. It is composed of twelve simple questions. Agreement correlates to retention, customer loyalty, safety records, productivity, and profitability.

From the beginning to the mid-point of our adoption, staff went from a response rate of 70% agreement 30% disagreement to 80% agreement, 15% neutral and 4% disagreement.

The most improvement was in daily opportunities “to do my best” and daily feedback on performance and expectations.

I’m convinced if I had administered the Q12 late in our adoption, we would have had even better results. The key un-addressed concerns were about having a best friend at work and feeling connected to the mission of the company. By 2007 our team grew to include people brought in by personal recommendation of other members of the team and our portfolio included consumer facing work directly for our CEO.

Rather than re-take the Q12, we undertook a 360° performance review. That we did this on our own initiative shows just how much trust we had built with each other.

Test Coverage/Code Quality

XP practices enforced methodical unit test coverage, mutually arrived at coding conventions, and real-time code inspection by multiple members of the team. The team went from no unit test practice to comprehensive coverage over the business logic and controller layers. (Unit tests against data access and gui were less comprehensive. I don’t intend to get in the middle of that debate here.)

A user story, test-driven approach to development has been shown to reduce defects in final testing by 40%.

XP and Scrum force conversations between the development team and product owner that incentivize all to build quality into the software rather than allowing technical debt to accumulate and relying on downstream QA process to fix the application.

In 2006-2007 there were no business impacting failures of our internally authored software. We were able to function as a project team with no dedicated developer maintenance staff. Change requests were minimal enough that we were able to prioritize them into our project sprints as overhead.

Reduced Risk

While any team has experts, “Agile” practices reduced our reliance on “specialists”. The entire team was capable of working on and maintaining any aspect of the code base. We passed the “bus test”; despite our small size, no project was at risk if any given member of the team became unavailable.

Leadership

Our team raised our skills and began contributing to our field. We write, present and teach at conferences on topics of scrum, XP and platform as well as contributing to open source projects and developer knowledge bases.

Recruiting and Retention

After establishing “Agile” practices we recruited skilled candidates from higher paying positions who desired to work in our culture and with our practices. We received inquiries from as far away as South America and Europe. Despite the reputation of our team and market demand we retained staff.

An additional benefit is that pairing provided an efficient on-boarding process for new hires. Developers joining the team provided immediate contribution. A metrics-based way to demonstrate this is to show that sprint commitments weren’t affected new hires first weeks. I observed that but mainly base this on comments from the team lead and existing members of the team.

Workplace Diversity

A 2006 paper by McDowell, Werner, Bullock and Fernald found that pair programming practice, “may help increase female representation in the field.”

Agile values and practices support a collaborative, empowering and sustainable work place. Such environments support diversity and take advantage of the breadth of experience each worker represents.

Client Satisfaction

We asked for quotes from our clients, vendors and even competitors which we included in our budget presentations (I’ve pretty aggressively scrubbed them):

“Working with the agile Software Development team has been rewarding on many levels…it’s a team that celebrates creativity, organization, listening, feedback, openness, honesty…and is proof positive that a great process results in great product. I look forward to our very regular meetings (I even readjust my travel schedule as much as possible to not miss anything) and am never disappointed. They are an engaging and engaged group of individuals.” - CEO

“[____ saved] half a head in [another team] and a full head in my team.” - VP

“The _______ written by our development team are the guiding-light to our decisions. [third party solution] has a vast wealth of information but no good reporting and our in-house [solution] enables us to divine meaning from the mountain of data.” - VP Traffic Operations

“We also use [third party solution] for all of our broadcast networks but I have heard about your software technology for ____. We currently do that through manual operators but I’d like to understand how you do that more sometime and how it works…” - Senior Executive, Competitor

“Given the complexities of ____ that includes the combined limitations of automation, graphic and traffic systems I believe [the team] has created a solution that has proven to be much more capable than most systems than I’ve worked with.” - Vendor

Frequent Delivery, Adaptability

Throughout 2006-2007 our team of 3-8 developers balanced two simultaneous lines of work on diverse projects built in Microsoft Windows Forms, ASP.NET to SQL Data Analysis Services Data Warehouses, Vista compatible Windows Presentation Foundation and XAML, open source .NET MVC frameworks and Ruby on Rails including a rich windows application built on beta Microsoft Technology.

The team completed eight IT and three consumer projects while doubling head count from 5 to 10 (+2 contractors). We initiated our consumer product initiative and achieved our first release of a rich windows application with a six month allocation of effectively 1.5 - 2.5 developers.

Invention/Innovation

Agile practices evolved from Lean management and associated knowledge creation theory. In this, it shares ancestry with Six Sigma.

Agile is based on empirical not plan-driven process control. It is closer to lean product development than lean industrial manufacturing.

Lean product development models sustained innovation as a process of knowledge creation and conversion within an organization that acquires and shares learning in an cycles within and across teams and up and down from leadership.

Agile fosters true joint work which is the only form of workplace collegiality that advances organizational change and innovation.

Our consumer product was recognized for its design and implementation by Microsoft’s platform and developer evangelist team as well as by the WPF team. It achieved high ratings in usability testing with end users (avg rating 8 of 10) and showed potential to deliver on its revenue targets.

Tag(s): agile, metrics, scrum, xp
Comments: none