Product Owner Change – Stop the Line!
February 18th, 2007 | 3 comments
What do you do when the fundamental assumptions behind a software project change mid-stream?
My experience before adopting agile practices was people often plugged away at the original plan drifting farther and farther off course.
I’ve been on projects that failed simply because no one had an honest conversation about who had authority to drive changes. How many of us have built something only to have the launch postponed because a senior executive got their first look and over-ruled their under-powered product manager? How many of us have had a project declared failure as a result? How many have seen work shelved? Me. Me. Me.
I’ve found Scrum does a great job of surfacing these issues and forcing the team to deal with them. Product owner is being over-ruled? Sprint integrity not being honored because interruptions and changes? Believe me, a performing scrum team will raise the alarm as quickly as this occurs and force a conversation about who is the product owner and what are the criteria for success.
One possible result? “Stop the line” interrupting the current sprint. Meet with the relevant managers and make the person setting feature priorities accountable for the backlog and the business outcome of the project. Plan a new sprint and re-commence work. The cost of mid-sprint changes is made explicit and responsibility is aligned with authority.
This can benefit everyone. First, the hidden product owner now has the regular feedback and control that reduces the urge for mid-sprint intervention. Second, the team knows who to rally around and why. Third, difficult conversations about what is driving changes and what defines success for the project happen earlier rather than later.
I’m not saying that these changes ensure success. Honestly, a project with mushy business ownership and vision is troubled. What I am saying is that with frequent inspections and a culture of honesty these seeds of failure become very clear to everyone much earlier.
I’ve found that once a team becomes used to satisfying the customer with early and continuous delivery of valuable software. They fight like hell rather than get caught in a familiar pattern of failure.
Short link: http://jkat.me/gNXFFx
Comments
Pingback from trackback from deployJava » Product Owner Change – Stop the Line!
Time: February 20, 2007, 8:26 am
trackback from deployJava.com
Pingback from >Just do it! | Ken H. Judy
Time: September 16, 2007, 12:26 pm
[...] opportunities. There are times to inject work into a sprint backlog. There are even times to “stop the line” and reset a [...]
Pingback from >When Should a Chicken Dive in with the Pigs? | Ken H. Judy
Time: September 6, 2010, 6:26 am
[...] All of this assumes the project in question is healthy. Intervention into a troubled project is a different animal [see my earlier post on stopping the line]. [...]



Write a comment