Transitioning to Agile in the Middle of a Project

This article was previously published on stickyminds.com

“My company has decided to transition to agile after the team and I started this project,” Gina complained. “I know what agile is, but I still don’t understand how I’m supposed to transition my active, waterfall project to an agile project. I understand how to start a project in an agile way, but what can I do after a project has started? My managers don’t understand what’s going on. My team doesn’t understand either. I feel as if I barely understand. What am I going to do?”

Here’s a solution: Start by helping your team find a project rhythm and finish pieces of functionality. If you’re trying to transition in the middle of your project, follow these three simple steps to ease you into agile:

1. Establish timeboxes.
2. Finish partly done work.
3. Build a dedicated cross-functional team that includes developers, testers, writers, business analysts–anyone you need to create a product in its entirety.

Decide on the Length of the Timebox

The timebox helps the project team focus on the work they need to complete in a given time period, so they’ll need to estimate how much work they can finish in this time. Most people don’t have a lot of experience estimating, and estimating for the entire team can be tricky. A good rule of measure is the shorter your timebox, the less the team has to estimate, and the faster they get feedback on their estimates.

Make sure your timeboxes are no longer than four weeks. Any longer, and people can get stuck in “student syndrome” (putting off work until just before it’s due), or they overestimate what they think they can complete.

Start with a short timebox–no longer than four weeks. This short timeframe makes people feel the urgency of the timebox and teaches them to break work into smaller tasks. You’ll see tangible progress from day one. But be aware that for some teams, even a four-week timebox can be too long.

Gina started her team with four-week timeboxes. When the team couldn’t finish the features they estimated they could, she went to three-week timeboxes–but that was no better. When she shifted into her first two-week timebox, a tester confessed, “I really need you to tell my manager to stop assigning me to other projects because I can’t do those and finish what I need to do here.” Gina said it would be her pleasure.

When people work in timeboxes, they cannot work on two projects. As Gina’s team discovered, forcing people to work in short timeboxes exposes some of management’s misconceptions about how people need to work to be productive.

It wasn’t just the tester’s management who was unclear on how agile works; everyone was confused. Some developers thought they were done with their pieces as soon as the code compiled on their machines, without checking that the code worked across all platforms. One particular developer thought the idea of ensuring that his code worked on all platforms every time that he checked in a change was a “waste of time.” Gina asked him to track his time for an iteration and promised to discuss these concerns with him at the end of the timebox.

Gina had data on how long it took the other developers and testers to find and fix problems that arose from not checking the code against all platforms as the developers developed it–about twenty-five hours to find and fix problems. The developer spent about five hours during a two-week iteration to make sure his code worked on all platforms. Once the developer saw Gina’s data, he acknowledged that it made sense for him to make sure his code worked everywhere before checking it in.

Moving to two-week timeboxes also exposed the issues that prevented the team from completing its work. For example, the shorter timebox made it impossible for the testers to work on Gina’s project and other projects simultaneously. Gina knew she had to convince her management that she needed the testers on her project full time. The transparency of the issues allowed Gina, management, and the team members to resolve their problems.

Finish the Partly Done Work in Order of Value

If you’re in the middle of a project and you’re transitioning to agile, rank the partly done features by the value you expect them to provide when it’s complete. First, develop the most valuable feature to releasable quality. Then work down to the least valuable feature.

Gina tried to rank the features for her product manager, but she made the mistake of ranking the features based solely on the project team’s input. When she presented her product backlog of partially completed features, he told her she was wrong–he needed things in a different order.

Of course, it made more sense to finish some features first because of the way the team had started to implement them. Once the product manager understood this process, he agreed that some features–ones not that important to him–should be finished earlier than he wanted. As he explained his feature ranking, the project team gained insight into why it was important to finish some features earlier than others. This discussion about value was critical to the project team’s understanding of what it meant to finish a feature. In the past, the team had been successful with partially implemented features in the major release and would finish the features in a point release. But once the product manager explained what he needed from certain features, the team understood what it would take to complete the feature.

When I say finish, I mean doing whatever is necessary within the timebox to reach a level of quality where a feature can actually be used by a customer. At a minimum, this means the feature has to be tested. You might need some documentation, such as help documentation. You might need some examples. Whatever you need, a feature isn’t done until it’s usable.

If you don’t have a product manager, check with your customer or product sponsor–someone who knows what features the eventual customers will want and in which order. If you have no one, ask yourself why you’re doing this project. This is where a lot of teams trip up in their transition to agile. Your team might be like Gina’s, where the testers weren’t originally full-time on this project, and they had no automated tests from previous releases. When the testers and developers worked together uninterrupted, they created a series of automated, system-level tests. In addition, the developers created unit tests so they would know if they were breaking the code as they finished each feature.

Gina’s team did not have 100 percent automated system tests, which made testing during the timebox quite difficult. The lack of test automation prevented the team from reaching a velocity they thought they could because they kept adding tests to the backlog. This issue arose during an iteration’s retrospective, and the team decided to tackle the problem so they could actually release the product. For the following iteration, some of the developers created a framework the testers could use to automate most of their tests.

By the time they finished all the in-process work, the product manager told them they could release–a surprise to the entire team. Gina was convinced it was luck because they had not ranked the entire product backlog, just the in-process work. Regardless, she was willing to take luck.

Make Sure You Have Everyone You Need on the Team

At first, Gina wasn’t aware that her testers and writers were attempting to multitask on several projects. The problem surfaced when the team moved to shorter timeboxes, and no one had time to postpone work.

Gina held a meeting with all of the managers and asked, “Do you care when we release this product?” Each person cared. “Do you care if we release it on time?” The unanimous answer was yes. Gina explained that their only choice was to keep everyone assigned to the project on it full time–no multitasking, no context switching, no quick interruptions.

One of the test managers asked, “But how do I staff all my projects?”

Gina said, “You don’t. If this project is more important than the others, you staff this one. You don’t staff all the projects.”

The test manager replied, “But I don’t have enough people for the other projects.”

Gina was tempted to say “tough” but realized that wasn’t a career-enhancing move. Instead, she said, “Look, you folks told me this project was critical to the company’s success. If it is, we staff this project. If we have too many projects critical to the company’s success, you folks have to decide which ones really are critical. But if you want me to run this project in an agile way, you can’t pull anyone off or ask them to work on more than one project at a time. They either work on this project or they don’t. This is a binary decision. The team can’t estimate what they can do nor can the project succeed if they have to work on more than one project at a time. Now, if you really think we have two critical projects and we need these people to work on both, we can alternate timeboxes to work first on this project and then the other. But I bet we don’t really have two critical projects.”

The managers discussed this loudly and long and finally agreed with Gina. If they assigned people to her project, they would not ask those people to work on other projects.

A Relatively Happy Ending

Gina and the team successfully delivered their release, just a month after the senior management’s requested date. They had never delivered anything that fast before and with as few defects. However, the team was tired. Instead of maintaining a sustainable pace, they tried to add overtime to their last three timeboxes. Not only was the intensity of the work in the timeboxes something they’d not encountered before, they also realized adding overtime was nuts because it came at a high cost.

Some people left the company to work where the intensity was lower. But a funny thing happened. Gina started receiving resumes. Since she wasn’t a hiring manager she forwarded the resumes to HR, so they were able to replace the people who left.

When Gina’s boss told her to take over another project in mid-stream and “convert” it to agile, she said, “I’ll restart it as an agile project. I won’t start in the middle again. And I want some outside help if I have to do this with a new team again. She got it.

Transitioning to agile in the middle of a project is difficult. As a project manager, you have to learn to work in timeboxes, help the team plan just enough for a timebox, and resolve obstacles quickly. Management may still ask for a Gantt chart even though you don’t need one.

If you’re a developer or tester, you need to collaborate closely with your team to accomplish “done” for each feature. If you’ve never worked feature-by-feature before, this can be quite difficult. And while the timebox helps you stay focused, the intensity of the timebox might be different from how you are accustomed to working.

Moving to agile and seeing how the whole product comes together before the end of the project is a reward in itself. Try it.

Acknowledgements:
I thank Esther Derby, Tobias Fors, and Don Gray for their review of this column.