The sweet spot
Agile's moving beyond software development…but is it right for every project?
is proving downright contagious— quickly spreading into new and unexpected sectors.
“Agile practices are moving outside software development at a pretty fast rate,” says Alex Adamopoulos, CEO of Emergn, a London, England-based global consulting company specializing in agile and lean methodologies. “Financial services, insurance and telecommunications are the top three industries, and we are seeing pharmaceuticals, utilities and manufacturing coming along as the next three spaces.”
Mr. Adamopoulos says his larger clients rely on agile throughout their IT project stack, and he estimates about 30 percent are implementing it on the business side as well.
There are compelling reasons driving agile's invasion into new turf: At its core, agile is centered on adaptability— a solid selling point in a rapidly changing business environment.
“Agile development uses feedback to make constant adjustments in a highly collaborative environment—that's it,” says Andrew Hunt, a consultant, author and co-founder of The Pragmatic Programmers LLC, a technical book publisher in Raleigh, North Carolina, USA. “There's really nothing fundamental in agile methodologies that is unique to software development.”
One of the authors of the original agile manifesto, he and his business partner have applied agile principles garnered from their software development days to their publishing business.
“The company is as agile as we can make it,” Mr. Hunt says. “Certain activities, notably involving printed product and physical trucks, are not as agile as we'd like, but we do it and we preach it to our non-IT vendors as well.”
Their authors, for example, develop content using iterations. “They estimate their work and adjust milestones based on actual progress made,” Mr. Hunt says. When a manuscript is 50 to 70 percent complete, an electronic version is made available as a “beta book,” allowing instant feedback from readers.
Faced with shifting resources and scope, Heiko Peters applied his background in agile software development to a massive engineering integration project for his former employer, TransCanada. The energy infrastructure company had acquired American Natural Resources Co. and needed to integrate 21,000 miles (33,796 kilometers) of natural gas pipelines to its network over a two-year period beginning in 2007.
Mr. Peters led a team tasked with gathering data and processes to certify the integrity of the pipes and bring the maintenance plan in-house. In addition, he had to establish new governance procedures to ensure ongoing integrity across the network. Differing regulatory environments between Canada and the United States meant TransCanada had to build new operating procedures. To accomplish this, the project team analyzed the existing data from American Natural Resources.
“We had to get all the information out of them regarding operating procedures—it was reams and reams of data—so the engineers could feed the systems that TransCanada uses for pipe integrity,” Mr. Peters says.
The integration team consisted of 14 senior engineers and their teams, who took on the project in addition to their regular responsibilities, plus Mr. Peters' data integrity team.
“We started by creating an old-school, big Gantt chart for project scheduling,” Mr. Peters explains. “But because we didn't have a dedicated team, we didn't have full time from the engineers, which made it difficult to meet our dates. And meantime, the project parameters were changing, the scope was changing, and we couldn't predict who would give us what hours or what new thing we didn't know. Given the constant change, we started implementing bits of agile.”
Chief among his tactics were daily 15-minute stand-ups with his data team and weeklies with the entire project team.
“We didn't have sprints or iterations, but the weeklies gave us a rough idea of what we wanted to be doing, what chunks of the workweek we had access to from our team and what our product backlog was,” he says. “It helped us identify and solve roadblocks because people were there to deal with issues. It was great at promoting communications, keeping the project moving and helping us adapt to change.”
Agile, Meet Lean
Lean and agile may sound like a new exercise regimen rather than a set of business practices, but companies can find big results as the two converge.
“Agile shares a lot of similarities with lean,” says Heiko Peters, PricewaterhouseCoopers, Calgary, Alberta, Canada. “Agile is more project-based, and lean is more organizational or culture-based.”
Adam Adamopoulos, CEO, Emergn, London, England, often combines the two practices on his projects.
“If you peel back the layers of lean and agile, some terms are different, but some of the methods almost identical,” he says.
- n Value stream mapping (lean) and customer value analysis (agile). Both practices aim to identify and prioritize project tasks and goals.
- n Kanban board (lean) and scrum board (agile). Both rely heavily on Post-it notes and tend to outline project stages in four columns.
- n User stories (lean and agile). Both methodologies use a work package or requirement written as a simple sentence from a stakeholder's perspective.
- n Retrospectives (lean and agile). Both techniques rely on these lessons-learned meetings at the end of a project.
Rather than relying on more linear tactics, Mr. Peters applied techniques from scrum, a project management framework used in agile. He created a product backlog, a document with broad descriptions of all the project's required features as well as wish-list items prioritized by business value.
“Using an overall backlog that broke tasks into more high-level details, we could track hours weekly and get a real idea of how much progress we'd made,” he says. “As the team mostly consisted of senior engineers, I let them handle the specific tasks internally and I just reported the hours remaining to the high-level tasks. For my data integrity team, the tasks were broken down a little finer and we tracked the hours daily.”
The trick is to discover under which conditions agile methods are most likely to be successful—what's known as “the sweet spot.”
“Agile is just a way to deal with change and the unknown by shortening the feedback loop, increasing communication and collaboration,” says Mr. Peters, now advisory consulting manager of technology, PricewaterhouseCoopers, Calgary, Alberta, Canada. “Would you want to manage a pipeline construction project that way? No, because that's a very fixed and linear process. But agile really works where there's a high degree of change or unknown factors.”
The flexibility offered by agile can be a powerful antidote to the mass chaos found in certain sectors.
“The most receptive companies are those that work in dynamic and turbulent business environments, such as research institutes and small and medium technology-based companies,” says Edivandro Conforto, agile project management and innovation doctorate researcher at the São Carlos School of Engineering at the University of São Paulo, São Paulo, Brazil.
“Companies that face constant changes in projects—even if they don't have a high degree of innovation and are used to following a systematic approach and highly detailed process— have recognized benefits of adapting and implementing some practices of agile methodologies.”
IS IT THE RIGHT FIT?
Agile isn't the answer for everybody— even in those industries fraught with constant change. “Don't think that agile theory will solve all your problems by itself,” Mr. Conforto says.
A number of pitfalls can sabotage prospective agile projects, and project managers should consider the following issues before heading into that first scrum:
1. For starters, examine the status quo. Evaluate the team's skill level at certain agile necessities. The techniques require a high level of trust. Project managers must have faith in their team members' judgment, and that means a skilled workforce that can collaborate efficiently and effectively.
“It's not really suited to large numbers of inexperienced, novice workers, especially if there isn't a mentoring program in place,” Mr. Hunt says. “If your people are unskilled and don't work well together, agile is not going to fix that.”
Agile techniques must also be able to coexist with an industry and organization's pre-existing procedures.
“In some fields, such as construction, engineering and building products, aerospace, and defense, there's an extensive literature and a set of best practices—including, of course, international standards and regulations— that must be considered when the company decides to implement some agile practices,” Mr. Conforto points out.
2. Start small. Try out “some practices like a whiteboard and daily meetings to improve communications and interaction among team members,” Mr. Conforto suggests. “My advice is to combine best practices from both sides, traditional and agile.”
While agile methodologies are flexible, too much dilution will negate their value, Mr. Hunt warns.
“There is of course the danger that that sort of adoption will really be their current business practices in sheep's clothing,” he says. “Agile is fundamentally different from plan-based methodologies, and you have to grasp these differences clearly.”
3. Expect culture shock. Agile differs markedly from many traditional approaches, so secure stakeholder and executive buy-in. Show value with a small, successful pilot project before diving in wholesale, Mr. Hunt suggests. “People seem to be better convinced when they see the benefits in context,” he says.
Even with full backing, be prepared for an acclimatization period as project teams transition to a more fluid style.
Mr. Peters, for one, wrestled with the challenges involved in getting his team to move away from artificial time estimates. “An engineer would say, ‘Well, I estimated 80 hours, and I got 8 hours done, therefore 72 hours remain on this task.’ And I'd say, ‘No, I want to know how many hours are needed to complete the task—is it really 72 or is it 88?’”
4. Know when to ask for help. With particularly ambitious efforts, it may be time to turn to outside assistance. “There will be some important changes in the company's behavior and culture to consistently apply agile principles and practices and create its own methodology,” Mr. Conforto says. “Consultants and agile specialists can help identify what can be changed and what cannot.”
In the end, organizations and sectors new to agile may be in for some pleasant surprises.
“Companies that I've done research with became more self-managed and self-disciplined because the method is based on a shared planning and controlling responsibility,” Mr. Conforto says. “The fast tracking and reporting using iteration planning and daily meetings helped teams maintain the focus on results and recognize and absorb important changes during the project execution.”
Agile can also improve stakeholder management—even when things go wrong. Mr. Peters' project veered off schedule, chiefly due to third-party vendor delays, but his ability to alert stakeholders to changes far in advance paid big dividends.
“Management was happy even though we ran late, because they knew the issues way ahead of time, and they knew why they were happening,” he says.
As industries outside of software development continue to adopt agile techniques, many project managers are realizing just how sweet it is. PM
PM NETWORK AUGUST 2010 WWW.PMI.ORG
AUGUST 2010 PM NETWORK