By Lisa Morgan
Reposted from SD Times
Being agile is more critical than ever as businesses compete for customers. The true level of agility can vary greatly from company to company, team to team, department to department and person to person. As organizations scale agile out from pilots and small groups to critical projects involving hundreds of developers, the dynamics can change in ways that may not be anticipated.
When a pilot has gone well, people may assume it’s a recipe for success, but later on they discover it isn’t a panacea after all. For one thing, agile practices require changes in mindset and behavior, especially among those who have been deeply entrenched in traditional methods. It may also be that agile pilots are treated differently than other projects.
“Quite often a pilot project gets a lot of attention: You have access to more resources in terms of external coaching, training and attention from senior management because everyone is watching and wants to make the project successful,” said Flowmotion business productivity coach Collin Lyons. (Flowmotion is a consultancy that helps companies manage change.) “When you expand agile [out], you can underestimate how much those things contributed to the pilot project’s success.”
What’s more, the type of people who worked on the pilot may differ from the people assigned to larger projects.
“One thing that happens when agile adoption starts is smaller teams become very collaborative, and they also have a lot of champion resources,” said Charlie Li, vice president of global quality and testing services at Capgemini. (A champion resource is a highly skilled person.) “Agile [initiatives] tend to have people who are well-rounded: QA people who can often code and developers who can work on architecture or design, [whereas] offshored and outsourced skill sets are very specific. When you have 20 people, it’s easy to say you’re going to hire 20 champions. But if you’re rolling out to 50,000 IT individuals, they can’t all be champions because the cost structure won’t work.”
Capgemini publishes an annual World Quality Report that has indicated that the need for multi-skilled talent is growing. In the first year, 2008, respondents considered testing skills important to QA. The next year, they said QA engineers should also have software development skills. Last year, the ideal skill set extended to domain expertise.
“This year, people want a left-handed Japanese ballerina that can do all of the above,” said Li. “Well-rounded people have been considered champions, but in the future they may be considered the norm.”
Pilots may also be populated with people who elected to work on the project. “The people who choose to work on a pilot are the kind of people that want to try new techniques and are willing to step out of their comfort zone,” said Thomas Stiehm, an agile consultant and CTO at Coveros, a product and service provider that helps build secure software applications using agile methods.
“[When you move] agile out to large groups, some people won’t want to change and they don’t want to be agile. The resistance to change can manifest in a number of ways that can lead to poor adoption results that doom enterprise-wide adoption.”
Some may view agile practices as too informal. Some may have seen agile projects fail in the past, or they may view agile as an excuse to do less documentation. Meanwhile, managers or executives may assume that existing resources and skill sets can adapt to agile more easily than they can in reality.
“Certain technologies and tools can be used effectively in a small team, but when you try to roll that out to a large organization, there are politics, issues, cultural changes and skill changes that become very challenging,” said Li.
Shinetech, a China-based software development outsourced service provider, seeds members of the initial smaller groups into larger groups to ease transitions, according to John Vanderpool, VP of Global Operations.
Scaling agile isn’t such a stretch – SD Times_ Software Development News
