Tag Archives: product owner

Innovation and collective product ownership (Agile 2007 presentation)

Posted on by

Jeff Patton reminded me about the product work my old Oxygen team did in 2006-2007. I dug out this presentation and accompanying paper that Ilio Krumins-Beens and I prepared for Agile 2007.

Ript™ innovation and collective product ownership

View more presentations from kenjudy

Our work anticipated the change in the Scrum Guide to consider the product owner as part of the team.

We developed an original windows software application using Scrum/XP with an onsite product owner and UX designer.

We evolved the product experience validating our assumptions using user personas and both informal and formal usability testing.

We released the product as a free Beta by the time of this presentation in 2007 and were working to build a customer base.

The lifecycle of a company (and the larger economy) doesn’t play nice with hopes and intentions. Oxygen was acquired by NBC-Universal before we were able to validate our assumptions.

Judy, K.H.; Krumins-Beens, I.; , “Ript: Innovation and Collective Product Ownership,” AGILE 2007 , vol., no., pp.316, 13-17 Aug. 2007

doi: 10.1109/AGILE.2007.49

Oops… learning lessons over and over

Posted on by

Here are agile software development mistakes that kick my ass whenever I let them:

  • Know the assumptions in plans. Recognize when they change.
  • Don’t abuse time boxing. It is a toe hold for over-committing. When the time box ends, the work ends.
  • Doing Scrum means DOING SCRUM. Sloppy backlog. No Scrum. No Product Owner. No Scrum.
  • No iteration boundaries and no commitment doesn’t make me “lean”.

Owning uncertainty

Posted on by

At Agile 2008, I attended Jeff Patton’s talk on embracing uncertainty and Alan Cooper’s keynote on interaction design.

I am convinced it is the role of product owner or customer that needs the most work in our evolving agile practices.

Sponsors express their desires as feature requests. But, as Alan Cooper argues, there is no linear progression from what people need, what they perceive they need, and how they express that in language.

At the same time, supporting departments, customers and management want a commitment to a scope and schedule. And in response, the team wants methodical decomposition to estimatable stories.

And so product owners dive into story writing, decomposing software into smaller bits in order to grasp the whole from the details. But the resulting release backlog looks only slightly more nimble software requirements specification and only slightly better at describing what customer’s really want.

What if regardless of our initial input from customers, product owners took Jeff Patton’s advice and focused our initial backlogs on specific, desired and attainable end user goals — not on interactions but why they are valuable to users? What if themes were something other than a less granular stories?

Could we retain this focus through release planning by sizing these themes not by committing to a single path and simple decomposition but by a more complex matrix of possible implementations, classifying how effectively those implementations might meet the end user goal?

Stop calling it an estimate. Stop pretending it’s a commitment.

Posted on by

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.

wall target by janerc on flickrIt’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.

Fail fast

Posted on by

Panic Button by aperte on flickrFail 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.