What do you do when the fundamental assumptions behind a software project change mid-stream?<\/p>\n
My experience before adopting agile practices was people often plugged away at the original plan drifting farther and farther off course. <\/p>\n
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<\/em>? How many of us have had a project declared failure as a result? How many have seen work shelved? Me. Me. Me.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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. <\/p>\n I’ve found that once a team becomes used to satisfying the customer with early and continuous delivery of valuable software<\/a>. They fight like hell rather than get caught in a familiar pattern of failure.<\/p>\n","protected":false},"excerpt":{"rendered":" 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 … Continue reading