Start with Scrum

Primavera Looked for Something Better

Bob Schatz came to Primavera a few years ago as the new Vice President of Development. He brought with him experiences from his career at General Electric and then a software start-up. Steeped in the principles of leadership, Schatz made a number of changes to increase the developers’ productivity and teamwork; these included new office space, motivational meetings and programs, and realigning the organization. The incremental improvements that he achieved were all very positive, but still inadequate to meet the needs of the company, and its customers.

Best Practices in Scrum Project Management and XP Agile Software Development: Primavera Success Story. Object Mentor, Inc., and Certified ScrumMaster White Paper, 2004.

Bob started by training all of his managers as ScrumMasters, the Scrum equivalent of a project manager. It is the ScrumMaster’s role to facilitate collaboration between the marketing department and development teams to build increments of functionality in monthly iterations.

The first iteration, or “Sprint” in Scrum terminology, made significant progress on the primary risk of release 4.0 – integrating two separate software systems. Primavera had decided that a key feature of release 4.0 was the integration of a new workflow and collaboration system into their project management software. This integration was extensive and devilishly difficult.

A review was held at the end of the first Sprint. The team demonstrated some project management portal functionality to management and executives. Since one of the Scrum rules is that only increments of potentially shippable product functionality can be demonstrated at the end of each Sprint, this was solid, tested, documented functionality. Dick Faris, Joel Koppelman and most of the management team were present, along with the product marketing managers and team. As the functionality was demonstrated, everyone became ecstatic. The risk was probably removed, because the entire product worked seamlessly. Frankly, nobody could believe what they were seeing just one month into the development cycle.

This initial success gave Scrum the credibility within Primavera for it to proceed. A starting point had been established – in code – for extending the workflow and collaboration to all part’s of Primavera’s new release. The team had proven to themselves, and everyone else, that it could build functionality every month! And, most importantly, since everyone could see the functionality working, they could start brainstorming about the most important next steps to take. They could direct the team to build the next most valuable functionality during the next month’s Sprint. Primavera and Scrum were on their way.

The best and fastest way to understand the kind of environment that Scrum produced at Primavera is to witness one of their Sprint Reviews. At Primavera, it looks and feels like a science fair. A large room is packed with all ten development teams clustered around demonstration areas, stating their goals and results achieved in the last 30 days. Joining in the discussions and providing feedback, spending 15 minutes with each team are the product owners (marketing people), the stakeholders (project sponsors), and company executives. Every 15 minutes, a loud horn (actually a bicycle horn) signals that it’s time for them to move on to the next team. This is the empirical approach in full demonstration mode.

After one such review Joel Capperella, Product Manager at Primavera, said, “It’s amazing how much gets done in a month – every month."

Waterfall Method: A Colossal Blunder!

Larman, Craig. Agile and Iterative Development. Addison Wesley, 2003.

I have received many requests for documentation of project failures caused by the waterfall method and the history of the many disasters introduced by accident when the Department of Defense standardized on a method that was unproven on large projects and essentially, a blunder by a consultant who had little experience with real software development.

The DOD has long since abandoned the waterfall method, and the consultant has recanted, but the waterfall approach persists as an urban myth in many software development organizations. Craig Larman details and documents this historical tragedy in Chapter Six of his book which compares the two leading agile methods, SCRUM and XP, along with RUP and Evo, an early iterative method.

This five star book is certainly required reading for anyone interested in Scrum, particularly those who are Certified ScrumMasters.