Abstract

Scrum provides a framework for managing agile development projects.  It encourages transparency at all times, which helps reinforce the cycle of trust that must exist between development teams, management and the customer.

Over the course of two years, our team had used Scrum to successfully deliver three revisions of our product with a degree of predictability that had been unattainable prior to adopting the agile method.

When the projected schedule of our next project didn’t align with the business needs of the organization, we found ourselves on the fast-track to conflict.  And we had given them all the ammunition they needed to turn our gesture of trust into a weapon of unimaginable destruction.

Introduction

I have been a professional software developer for twenty-two years and currently work for a large, multi-national mega-corporation.  Our division provides a full line of building control products including Hardware, Firmware, Tools, Workstation Software and Data Storage applications.  I am the technical lead for the Workstation product, which has been released in the field for more than a dozen years.

The other projects in the Product line tend to be feature-driven—they ship when they have satisfied a list of requirements, which could take anywhere from a couple months, to a couple years to deliver.  The Workstation projects are fixed at one-year cycles to accommodate customer service agreements.  In order to satisfy market needs or synchronize with the other projects in the Product line we occasionally release a second sub-revision in the same year.

Dysfunction

All of our engineering projects are monitored and controlled through our development process—which is our implementation of a gated waterfall model.  When a requirement list is received, the Process demands a schedule be established.

The developers, who are notoriously bad estimators, learned to fight their instincts and add some time to any estimates they gave.  The project managers, who are on the hook for the accuracy of the schedule learned to protect the development team by padding the schedule to provide a buffer for surprises.  The line managers, who were once developers and project managers themselves, know about the padding and the buffering.  They would prefer that the team found a way to give more realistic estimates, so they learned to treat any estimates that are given as negotiable.

The product marketing folk are aware of the padding/negotiation cycle as well.  They have a huge list of features from multiple sources.  If they don’t pay attention, some of those features will get negotiated right out of the schedule.  So they learned to guard against this by marking everything in the requirement list as a must-have so it cannot be easily removed.

Thus, the Workstation projects get slated based on a complex system of co-dependent mistrust, rather than anything resembling reality.  As the projects run, assumptions made about related projects prove false, the buffers are consumed and features start getting jettisoned.  The teams become disillusioned.  And quite predictably, the project ends in a death-march with long hours and high stress as we approach and then blow past our intended shipping date.

Agility Needed!

The needs of the Workstation project were not being served by the mechanics of the Process.  However, attempts to alter the Process were met with heavy resistance.  It wasn’t until the winter of 2005, after a particularly disastrous death-march project that we had a real opportunity to challenge the system.  The Workstation and Firmware groups had been working on a major joint release, and were taking turns blaming each other for the project running long – six months long!  When the dust settled, the Director made a simple statement, “Find a way to be more predictable.”

Despite the fact that the Process wanted us to treat requirements like they were carved in granite, the fact remained that those other projects were just as bad at meeting dates as we were, so predicting a long-term integration schedule was nearly impossible.  I suggested we try Scrum.

The line manager, PM and I mapped out a plan to get the team trained in Scrum.  We arranged for Scrum training of the team members and leads for both the Workstation and Data Storage projects.

In spring of 2006, two pilot projects began using Scrum.  The Workstation project had two local scrum teams and a fixed end date, so the final feature list would be allowed to change.   The Data Storage project had one local and one offshore scrum team, with a fixed feature list so the final date could shift.

Because we were circumventing the Process, we were required to give updates every three months to a management steering committee which included the Director and the head of our Process group.

The first Workstation Scrum project shipped on-time and on-budget for the first time in the history of the product.  The iterative model worked perfectly for adjusting course when other projects shifted dates.  The prioritized backlog kept us focusing on completing the most important functionality first.  We also learned that cross-functional teams got technical writers and testers involved earlier in the process, where they proved to be invaluable in working out user interface designs.

The second Workstation Scrum project was a minor sub-revision that added support for a delayed Firmware/Hardware project.  Cross training via pair-programming was given priority, eliminating silos of knowledge.  It also shipped on-time and on-budget.

The Data Storage project shipped with a completed feature list.  They credited the use of Scrum with giving them the tools to monitor the offshore team’s progress.

As each project progressed, we tracked all of the typical Scrum metrics and honed our agile skills – especially estimating.

It was just enough success to prove that Scrum could work in our organization.  It was just enough success to get us noticed.

The Grass Takes Root

Our evolution from pure waterfall had progressed past the initial try-it stage.  It had gone past the prove-it stage.  The next logical step was for us to start gathering some additional management support.

Four of us (the project managers and technical leads from the initial pilot projects) started referring to ourselves as the Scrum Evangelists.  We began spreading the word of what we were accomplishing to other groups and shared our experience using Scrum at best-practice sharing conferences.

The steering committee, now somewhat hopeful that we had stumbled upon something worthwhile, suggested that Scrum should be tried on some other projects—perhaps even on something larger.

The Scrum Evangelists were called upon to provide training for other teams within the organization both here, and abroad.  We shared the agile estimation techniques we had been using.  We shared our experiences, we told them what to watch out for, and we offered to help in any way we could.

The third Workstation Scrum project was another full revision, with a new project manager, a new product owner, and supplementing the two onshore teams with two offshore teams.  This project also came to another successful conclusion.

In two years, we had delivered three date-driven revisions of the Workstation and one feature-driven revision of the Data Storage tool.  All had been completed without the familiar death-march that had been the hallmark of the waterfall projects.

Things were going pretty well for Agile, and we even added another couple of members to our Evangelist ranks.

<nbsp;>

Next: Weaponized Scrum Part 2 – Weaponizing Scrum