Bhushan Gupta, Nike
Agile software development methodology is transitioning from a fad to a practice. More and more software development practitioners are contemplating the switch from Waterfall to Agile; if not entirely, at least partially. Terms like scrum, sprint, stand up, story points, and velocity are becoming the Lingua Franca. While enough light has been shed on the mechanics of creating a release and iteration plan, managing story development, and sprint retrospectives, the team dynamics and behavior for success has not been given the mindshare it deserves.
Although the rules of the game, when moving from waterfall to agile development change substantially, the players and their goals do not. The player “product manager” now becomes “product owner” and needs to very actively pursue customer interest as a customer surrogate. Test engineers who took pride in breaking the code are now urged to work side by side with the developers and ensure that the defects are resolved immediately for a successful completion of a sprint. The project managers, who are supposed to drive the schedule, take on a role of facilitators making every effort to see that the sprint is complete and the velocity is adequate. Requirements that are frozen in the waterfall methodology rarely gel and the designs go through multiple refactoring cycles to make sure that the development progresses. The new product quality champions who were always looking for “the knee in the defect trends” now barely witness any fluctuations in the defect find trends from sprint to sprint. Refereeing the game, there is a new character in the theatre, “scrum master”, who manages the delivery of the stories.
Can this change be achieved by simply creating a backlog, a release plan, and a sequence of iterations? No, it takes changes in people’s perspectives, the way they think, and the way they achieve their goals. Would a Type A “product owner” who is used to taking a product to the market with all the bells and whistles be comfortable to do so with less than the planned functionality? Would a star developer forget about gold plating and would a test engineer who always took pride in finding errors in someone else’s work be able to stand by developers and work with them? Most of all, will the orchestra be able to perform without the precisely written music; the “requirements document”? This paper analyzes the transition of a waterfall team to an agile environment and how changing the perspectives of the players can make the transition a success when the switch from Agile to Waterfall is flipped.
Bhushan Gupta, 2012 Technical Paper, Abstract, Paper, Slides
