product owner

Innovation and collective product ownership (Agile 2007 presentation)

Sample Ript Page

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 … Read More

Oops… learning lessons over and over

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

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 … Read More

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

13164176_db4a95d09d_m

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 … Read More

Fail fast

948080386_67d0d1c261_m

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 … Read More