|
|
AS OF 7/20/2008 5:32PM EST
|
Spreading the Agile Practice
Extending new processes beyond a single project team presents unique challenges
By David Rubinstein
October 15, 2007 —
Many organizations have begun to reap the benefits of agile development on their internal projects—shorter time-to-market, better quality software, more team productivity. Now, they want to know how to get those same advantages when doing agile development throughout a distributed team.
The answer? Get a Subversion code management system, a Webcam for whiteboard meetings and a speakerphone.
Of course, achieving agile success with a distributed team is quite a bit more complicated than that. But three principles—the ability to share plans, access the code from a single repository, and communicate effectively—form the cornerstones of spreading agile processes over disparate locations. Then, experts agree, the members of the team must be highly competent and working in an environment that fosters trust, provides a feedback structure, and gives visibility across business and development efforts.
One of the messages of agile is that it improves quality. Andrew Glover, president of the consulting firm Stelligent, said that’s the wrong message. “People don’t want to pay for quality. You say quality, people think QA, and QA has no money. Switch out ‘quality’ with ‘delivery speed,’ and people start buying it,” he said.
The core principles remain the same regardless of the specific agile process in use; although at the recent Agile 2007 conference, a number of consultants and developers mentioned that distributed agile development is most effective when Scrum is used in tandem with Extreme Programming, or XP. Scrum provides the overarching management structure, while XP is in place at the developer level where the coding is actually done.
Before any code can be written, though, it’s important to get everyone on the same page. Several experts suggested bringing the teams, or at least representatives of each team, together before the project begins in a sort of common architecture design meeting. “It’s important for teams to get familiar with each other before they are dispersed,” said Paul Hodgetts, CEO of agile consultant practice AgileLogic. “It’s costly, but the benefit offsets the cost and helps the project not drift off.”
Scott Ambler, a noted author and agile development practice leader at IBM, agreed, saying, “You have to be willing to fly people around. Penny-wise and pound-foolish leads to disaster.” It’s important to build bonds at the beginning of the work, and then use “ambassadors” to travel back and forth to overcome communication challenges and, in the case of teams located abroad, knock down cultural barriers as well, he said.
Getting Together
The creation of a collaborative work environment, and having people skilled in project management, are important first steps in taking agile into wide use. “If you’re not good at managing a single location, you’ve got no shot at a distributed agile project,” Ambler said. He also suggested there is a bias among American developers, who he said believe they can do a better job than overseas developers. But you might have a CMMI Level 3 U.S. team managing a Level 5 team from India, “and that’s backwards,” he explained.
However, Peter Harrison, CEO of outsourcing company GlobalLogic, said American developers actually do have more experience than teams abroad, and that no bias exists. “The average outsourcer today has two to three years’ experience, while in the U.S., the average [outsourcing] experience is eight to 10 years. You can’t have peer-to-peer relationships as effectively. You need true peers on each end.”
Doug Mow, senior vice president of Exigen Services, an outsourcing company, said, “You need an elite organization committed to its reputation.” Team members, he said, need to be teachable and willing to learn.
But communication, Mow said and several experts agreed, is the main hurdle to overcome. Some use conference calls. Some use Skype or set up wikis. But Harrison advised, “Get rid of e-mail. It’s a disaster.” Often, people who need to know about an aspect of a project are not copied on the e-mail, or a thread gets broken and the context of the message is lost, he explained.
Some organizations find that as they try to ramp up their agile efforts, the original agile team loses productivity when the team leader is moved to another team to get it going. “Training is essential, and having a good mentor on every project is crucial,” Harrison posited.
Serena vice president of ALM products John Scumniotales said, “Until agile behaviors get institutionalized, you’ll see productivity wane when a Scrum master moves from the first project” to another.
What Do They Want?
More traditional waterfall methods involve soliciting input from the business side, writing high-level requirements and themes, and performing technical analyses for implementing features—before any code gets written. In contrast, agile processes advocate less up-front planning, emphasizing flexibility in reacting to changes. But any development project starts with a set of requirements, no matter how simple.
“Most agile teams haven’t used classical requirements modeling and a big specifications document,” said Tom King, executive vice president at requirements modeling company Ravenflow. Instead, “they sketch models on whiteboards and do lightweight use cases.” However, King noted that a developer in Bangalore might make incorrect assumptions when filling in gaps in lightweight requirements.
It’s important, then, to be able to share whiteboard sketches electronically—a virtual standup meeting, if you will—so business analysts and other stakeholders can review the requirements diagrams. In fact, a recent survey completed by Ambler showed that lightweight use cases and informal stories rated high among agile developers, while formal specification documents scored low.
“When projects took six or eight months to complete, needing a month for requirements was OK,” King said. But with today’s eight-week completion times, four-week requirements phases are “out of proportion.”
Another approach is to do visual prototyping, according to Mike Evans, director of the customer enablement team at Skyway Software. “It’s actually visual requirements gathering. A solution architect sits in with the team during requirements gathering and builds out the framework for the application. In two to three days, he can create a running prototype of the application to prove the requirements.” Then, instead of a prototype of requirements, you have a prototype of the actual application, which can then be taken into development. “It’s a predictive model for building the application based on a prototype that maps back to the requirements. It gives a truer picture of the time and cost before you even start development.”
Compounding the problem of communicating requirements is the difficulty in writing tests that prove the requirement has been met. “Often, there’s miscommunication about the intent of the feature, or how to test it,” said Kingston Duffie, founder and CTO at device testing software company The Fanfare Group, which runs agile development teams in New Zealand, Russia, Vietnam and other locations overseas. “QA is the low-hanging fruit. They’re under the greatest stress, and business people don’t know how to communicate on their level. Also, they usually have the shortest time to do their work.” So creating a transparent document that defines what a test is and how to define success, instead of simply offering up more code, enhances communication, he said.
Is It Built Yet?
Agile processes call for frequent builds. But organizations must decide if that means every half-hour or four times a day. Further, some experts say a single, centralized repository that offers high visibility is essential to effective distributed agile development. But how does it all tie together?
Resource management is the answer, because even when the code is centralized, there still will be people trying to run their own things. “You want to provide multiple ‘lanes’ of builds to get them going simultaneously,” said Martin Van Ryswyk, vice president of engineering at build management software provider Electric Cloud. “Now there is no ‘overnight’ with a five- or six-hour build and then spending the morning solving problems of the night before. You’ve got to be able to do things fast, or you don’t get the benefit of few check-ins with each build. If you can [build] more often, it breaks big problems into small ones that are all in one place.”
Equal to the central repository is the need to get an accurate record of the builds. “Everyone needs to have access to the data so things can be kicked off [to developers] to see what happened,” Van Ryswyk said. This also enables teams to take advantage of the round-the-clock development opportunity that distributed teams can provide. “Folks in India can see how [code] was checked in and perhaps fix it. They don’t have to wait for a California development team to come in the next morning to fix it.” A centralized build farm, he pointed out, means an organization doesn’t have to support redundant hardware resources to do continuous integration.
Continuous integration also provides measurement and accountability, according to Stelligent’s Glover. “Continuous integration and build automation with reporting gives tremendous visibility.” That visibility, he noted, raises the level of accountability, as all can see where a problem was introduced into the code. “Is humiliation a good thing? Not necessarily, but it motivates developers to not break the build again,” he said.
Two open source projects—the automated Cruise Control build framework and the Hudson continuous integration engine—are getting more sophisticated, Glover said. “These poll the SCM system and wait for change. If they notice a change, they run a build,” he explained.
The automation framework, Van Ryswyk said, is critical to tie in scheduling and integrations. “You want to coordinate local builds but with an official procedure and hardware,” he said. “You want results, when it’s done, to end up in the central location.”
Other Considerations
Despite having communication and collaboration tools in place, Roger Nessier, vice president of product management at product engineering outsourcing firm Symphony Services, suggested that if one has 10 development teams, but two are in a different location than the other eight, the remote teams should work on different aspects of the project to maintain the integrity of the core group’s work. “You need clear delineation, so the two teams don’t break code being worked on by the other eight,” he said.
IBM’s Ambler agreed. “Teams need to do their own things and then negotiate the interfaces later.”
Serena’s Scumniotales even said agile might not be good for all projects. “In reality, most environments are heterogeneous from a process standpoint. If you have a project that’s mature, and perhaps you’re only doing maintenance, what’s the ROI of moving that project to agile? That’s the reality businesses are dealing with.”
So, if you need more communication with overseas teams than collocated ones, either via flying in or teleconferencing, and you have to have more whiteboard planning meetings, and you have to keep teams working on different projects, aren’t you losing the “agile” in the process you hoped to gain?
No, according to Dave McMunn of business consulting firm Command Information. Agile evangelists have to soften up the message. Many independent coaches and consultants “say that to be XP you must do this and this, and if you’re not, you’re not being true to agile.” Instead of calling it agile development, the term should be changed to “best practices development,” he said. “But I’m not sure we’re ready to do that...as a community. There’s not enough momentum and coalescence of thought to make that transition.”
Yet.
|