Transitioning to Agile in the Middle of a Project

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