Every team transitions to agile in different ways, and this column is one of those stories. But what makes this one different is that the main character, a project manager, is transitioning her team to agile in the middle of a project. From this story, Johanna Rothman details a potential survival guide for any project manager and team embarking on the same journey.
"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:
- Establish timeboxes.
- Finish partly done work.
- 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