Continued from "What it takes to scale agile development".
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
 |
|
|
|
| Damon Poole, founder, AccuRev | |
|
|
Both Ambler and Poole recommend practices to help better scale agile. Ambler said some upfront, lightweight modeling is key.
"Traditional development is based on the concept that you need to think through everything up front in detail, which is a wonderful theory, but practice shows that's not the case," Ambler said. "Detailed upfront modeling increases risk, and you end up implementing functionality [that] stakeholders don't want. With agile modeling, you get value from modeling, but you're not taking the hit of extraneous documentation and extraneous detail."
Ambler also said some extra coordination is required to scale agile. At the project level, "Scrum masters have to interact and make sure sub-teams are going in the same direction, and product owners of each team have to negotiate priorities to make sure teams are working in the right order."
There also has to be coordination at the architectural level as interfaces and requirements evolve, he said, to negotiate technical issues, "so architectural coordinators on each team have to interact."
One agile practice that Poole said doesn't scale well is continuous integration (CI), which is why he recommends multi-stage CI. With multiple teams all doing continuous integration, he explained, the impact on the teams and the mainline code grows exponentially. With multi-stage CI, "you as the individual developer don't get changes from everyone all the time and check in your changes all the time. You check in [code] when it's working and get other's changes when you're ready."
|
||||
|
|
|||
|
||||
The idea is to compartmentalize, he said. "It's implemented with branches. With multi-stage CI you have a branch for each team, and they check in code like that's their mainline. If it goes well, you move the change on immediately, so you're moving as fast as you can but no faster. But if your team has a problem, it doesn't affect other teams."
What about those 3x5 cards and standup meetings? If a large team is split into smaller, co-located subteams, those methods can still work, Poole said, but they are clearly more problematic for distributed teams.
Agile practices in traditional environments
Interestingly, Poole said organizations that do traditional development can incorporate some agile practices that will help scale a project, such as breaking the project into smaller teams, co-locating teams, and holding stand-up meetings.
"I'm a fan of agile, but to me it doesn't matter whether agile is successful," he said. "It only matters if software development in general is more successful, and agile brings more tools to the table."