The whys of transitioning to an agile methodology are often the same: slipped release dates, scope creep, time to market. It's the hows of moving to agile that can vary among development organizations.
Providing agile training is a first step for some organizations. For Vignette Corp.,
Vignette then proceeded to do what Subu Subramanian, senior director of engineering, called "just-in-time training." Initially, as teams were ready to begin a new project, Valtech would conduct a two-day training session in Scrum, covering the principles and practices, release planning and sprint planning. Vignette also had Sheth attend Scrum coaching sessions, and he eventually trained the rest of the Vignette teams.
"I definitely think teams should get trained before they start," Subramanian said. "Having a good coach to introduce the principles and walk you through the early sprint and release training is useful."
Basab Dattaray with Mountain View, Calif.-based Intuit Inc. said his group also brought in an external Scrum instructor. "I think training helps, but training alone is not sufficient -- it has to be training with practice," said Dattaray, engineering manager for new business initiatives within the TurboTax group at Intuit.
AMS Services, a provider of insurance agency automation products based in Bothell, Wash., also brought in an outside trainer, but their move to agile started with the formation of a steering committee made up of people from every role in the software development lifecycle (SDLC). The committee was tasked with developing a plan to adopt Scrum. "We gave them a three-month deadline," said Chris Kinsman, vice president and chief architect. "They had to figure out how to eliminate the roadblocks."
They then took "10 natural leaders from a 50-person team" and sent them to a Scrum master course, Kinsman said. AMS Services also brought in Redmond, Wash.-based Solutions IQ to conduct on-site training that covered agile philosophy and the mechanics of Scrum.
Not every organization starts with formal training, though -- take Ajira Technologies Inc. CEO Nari Kannan had followed Extreme Programming (XP) practices in a previous job, and he trained his development group in a mix of XP and Scrum practices that fit their needs. "New employees join one of the groups; it's more on-the-job training," he explained. "It's the best training we've found. With short development cycles, we can't afford to sit in a classroom."
New projects or midstream?
Where in a development cycle to transition to agile practices is another consideration. Vignette, for example, decided to roll out agile as each team started a new project. "We didn't do a full switchover," Subramanian said. "We phased [agile] in over the course of a year or so."
AMS Services, in contrast, kicked off its switchover "right in the middle of a development cycle," Kinsman said. "There was a little bit of 'Oh my god the sky's falling,' but most grasped it."
"In retrospect, we didn't have a lot of up-front planning," he added. "It was rocky, but folks caught on quickly. We did three-month-long sprints, and when we got to the end of the development we realized we had not been working this way through the entire release, so there was still some work overhanging for QA." The whole team helped with regression work. "It opened [the developers'] eyes." After that initial foray, he said, AMS Services fully transitioned to agile methods for the next development cycle.
Setting up agile teams
Organizations also need to determine the size and makeup of the teams. Intuit's Dattaray said they set up cross-functional teams that included some remote members. The teams used ScrumWorks -- an agile project management tool from Portland, Ore.-based Danube Technologies Inc. -- as "a common watering hole," Dattaray said.
Dattaray's group started with what he called a big sprint of six weeks, then moved to four weeks and eventually two. "Things changed in the market, and it's important to move quickly," he said. "It required QA to be more engaged right from the beginning."
Last year, Dattaray said his teams delivered six different products. "The smallest ones had two developers for two months, and the biggest took a year with 15 people on board, but even there the big teams divided to smaller teams."
Kinsman said AMS Services also set up cross-functional teams. "Before, the groups were very siloed," he said. AMS Services built four Scrum teams with an average of eight people. The goal was to deliver fully functional software at the end of every sprint. "It was a pretty big change for them. They were all loners prior to this."
The biggest challenge for the teams, Kinsman said, was getting members to break down stories very small. "We still struggle with it," he said. "And we struggle with the concept of delivering an actual usable value at the end of each sprint."
For Vignette, having distributed teams was the biggest challenge, Subramanian said. "I think teams are more effective, obviously, if they're in same room, so we had to sacrifice a little." For example, he said, teams are not always able to have a dedicated member for performance analysis or user experience, but instead share a person across teams. To keep shared team members engaged and up to date with the artifacts, they use informal tools such as wikis, he said.
"If you have a large team that is distributed, you have to adapt to something that works," Subramanian said. "Different products need different size teams. How they organize themselves and coordinate across teams, we leave up to them."
Self-management leads to ownership
At Vignette, one of the initial goals of transitioning to agile development was to empower teams with a sense of ownership, and Subramanian said they continue to survey teams on how they're feeling about the process.
Vignette's Sheth said the company's teams are sharing knowledge about what works best, which then becomes a preferred tool.
Kinsman said AMS Services has had similar results. "The fact that we were going to move to agile was certainly mandated from the top, but at the individual team level, how they executed was largely determined by them." He said the scrum of scrums meeting is often where the Scrum masters detect a problem with a certain team, and they work together to self-correct it.
Intuit team members have found the same thing. "With Scrum, team members take responsibility and ownership," Dattaray said. "We don't have anyone hounding people."