Agile Development Advice
Also, another lesson from agile development is to "build integrity in. Don't try to add it later," Shuttleworth said. "See the whole-cultivate a shared result. It is not done until it's completely done. This leads you to avoid handoffs, which is good because handoffs are one of the ways that things tend to pileup." For his part, Shuttleworth said that he and his developers "look at the agile world for some of the key values-but in the community environment, maybe we can go beyond that."Another instance where open source takes a different tack from agile is with the notion of having an in-house customer. "We value community collaboration over internal development," Shuttleworth said. "That's better than having a customer in-house." Meanwhile, the process of iteration-or iterative development-which is popular in the agile world, "requires a certain amount of planning," Shuttleworth said. "We value continuous integration over continuous iteration. That fits nicely into the free software world where you don't know what's coming in from the community." As for quality, "we want it for every build, not just every release," he said. As far as the pace of delivery, cadence is key," Shuttleworth said. "We need to go from ''release early and often" to "this cycle-we added X." Every month we roll out new code, and beta users get code every day." It is also important to know where you stand in terms of bugs, features and ideas, he said. "It's amazing how many projects don't have bug trackers." On the issue of branching and merging code, Shuttleworth said developers "must keep the trunk pristine, keep releases flowing and release on demand." He said branching and merging is the key practice that enables the team to create cadence. Meanwhile, Shuttleworth encourages code reviews, which accelerate learning, maintain quality and verify test coverage. He also said he is a stickler for automated testing, including unit testing, integration testing and utilization testing, as well as pre-commit testing. He joked that a pre-commit test is like the saying: I see you knocking but you can't come in. "If any code fails the pre-commit test, the commit can't happen," Shuttleworth said. "If you have pre-commit testing, you can't argue. It's a way to make sure the trunk is always releasable." Finally, he said the product is the platform, and "if it's hard to hack they won't come back," he said. Shuttleworth said Canonical continues to draw from the agile and open-source communities, which are not mutually exclusive, for ways to improve its development practices. Meanwhile, from the Agile 2008 conference, according to a report released by Rally Software Development Aug. 4, development teams utilizing agile practices were on average 37 percent faster delivering their software to market and increased their teams' productivity by 16 percent. The report, entitled "The Agile Impact Report: Proven Performance Metrics from the Agile Enterprise," also concluded that agile teams were able to maintain normal defect counts despite significant schedule compression. Commissioned by Rally Software Development in May and conducted through July by research firm QSM Associates, the study measured the real-life performance of 26 agile development projects against plan-based or waterfall industry averages in three key areas: productivity, time to market and defects. "Current market data on the agile industry often falls short of examining the true impact that agile practices have on teams throughout the entire lifecycle," said Tim Miller, Rally's CEO. "We wanted to go beyond adoption rates or estimating project improvements and provide software organizations with proven metrics-supported by actual project examples-that accurately demonstrate how agile development projects measure up against plan-based or waterfall projects." By adopting agile practices, the companies measured in the report were able to produce large-scale enterprise software in four to 12 months, compared to the one year to 13 months that it takes a typical organization to deliver comparable software.
For instance, pair programming is a core practice of agile development methods. However, in the open-source community, where developers are spread out all over the world, pair programming in the classic sense is difficult. "We value knowledge and interest over co-location or sitting together," Shuttleworth said.