Definition of legacy code: Old, onerous, and orphaned code base that is an obstacle to workflow and has octopus-like tentacles reaching into other systems.

The team was working with a legacy system. The batch jobs required to test the system typically took a day or three to run, depending on resource demands. We were moving from four-week sprints to one-week sprints, following Jeff Sutherland’s “Shock Therapy” guidelines. Our project goal was to modernize and expand the capabilities of our legacy system to support an under-construction online system for internal and external customers. I was stepping in as interim ScrumMaster for the first few weeks of the project.

The team members were adamant that one-week sprints couldn’t be done—not with their legacy code. The sticking point, obviously, was the testing turnaround on the batch jobs. “It is what it is” was the team motto. After a few discussions, in which the team members repeatedly explained to me why the dozen of testing mechanisms typically used in similar situations would not work here, I asked two of them to join me in the chief architect’s cubicle.

I sat down next to the chief architect’s desk while the others remained standing. Again, the chief architect (CA) explained how there was no way around this barrier. I smiled and stayed in my seat; I was not leaving. Eventually, the CA suggested using a “materialized view.” I should note that the team had rejected the concept of “snapshots” previously. The word “snapshot” is synonymous with a materialized view. Snapshots are just a subset or summary of the database at a specific point in time that can be used locally. Not only do snapshots have the advantage of being totally within the team’s control (no queuing), snapshots can omit vast pieces of the database that are irrelevant to the work at hand.

One of the concerns the team members had was that the database administrator (DBA) wouldn’t be able to create snapshots for them; they couldn’t expect that of him. The CA told the team “no problem” and suggested we all go talk to the DBA right then. We worked out the schedule for requesting the materialized views, and voila—the team could test the first couple of versions of their queries in a matter of minutes, instead of days. We still had to allow for a test using the entire database, and snapshots were only an intermediate step to solving the real problem in the system. However, we had taken the first step in proving “it could be done” and that we could change the ways things were—we had power.

Still, the amount of work in the product backlog was daunting. Even with a faster testing cycle this was going to take some time. However, the team members were optimistic that they could deliver on time. After a few sprints, we were able to project a velocity range. With our experience in mind, we estimated the entire product backlog of user stories using the White Elephant-sizing method.

Also known as the Yankee Swap, the White Elephant method is a structured process where team members individually read a user story and using structured speech announce, “I think this story is (either) ‘small,’ ‘medium,’ ‘large,’ or ‘extra large’ because...” They then place the story on the wall in the appropriate size bucket. No one is allowed to comment. However, if someone disagrees with a placement, then when it is that person’s turn, that team member is allowed to move the story—again using structured speech to justify the new placement. The game is over when every user story is placed and there is a round where all team members affirm that they are content with the placement of each and every story. Each bucket size is assigned a story point number value. Using team velocity, we forecast how long it will take to complete all the stories in the product backlog.

In our case, it was going to take a very long time. The agile project manager was happy we completed our sizing and presented it to the business managers, who were alarmed at the forecast. I’ll never forget the hang-dog faces of my team members. They were concerned they’d be regarded as bad workers; didn’t want to disappoint management; were worried their jobs might be at risk; and insisted they could complete the work on schedule—they’d work overtime. I told them it was okay. In this case, “it is what it is” and it was better to be up front about the effort required. I told them that in agile you have to “get comfortable with being uncomfortable” because agile isn’t about being easy, it’s about being honest. Two or three days later, the product management folks came to us and said, “We’ve been thinking about it. We really don’t need everything we put in the product backlog. If we could just have this subset of stories by this date it would be enough.” Not only were the team members able to commit to completing the smaller backlog, but they were heroes for alerting management of the risk. I was delighted that the agile process forced the product folks to really examine what it was they needed. The team was amazed, relieved, and happy.

I wish I could say it was smooth sailing after that; it wasn’t. New stories crept into the backlog. The project changed direction. Dealing with the root causes of the problems in legacy code was challenging. However, the team members had become more empowered. They shared leadership with management. They stopped ending all difficult conversations with the fatalistic statement “it is what it is.” They learned that they could change things into something more like what “it” should be.