7 simple ways to fail at agile

“Success has many fathers, while failure is an orphan” is a saying frequently cited by contemplative business leaders. Yet when it comes to failed agile initiatives, the old bromide might be updated to state: “Success is a team effort, while failure is simply everybody’s fault.”

No new agile program aims for failure. Yet poor planning by an unprepared and ill-informed team that fixes its sights on unrealistic goals will usually doom a project from the very start.

Want to ensure that your agile initiative will collapse into a heap of twisted hopes and dreams? Well, here are seven simple steps to help you get started:

1. Plan loosely and chaotically

One of the great myths surrounding agile is that planning and structure aren’t essential. Yet that’s simply not true. “Agile is not an excuse for chaos or no management,” says Alan Zucker, founding principal of Project Management Essentials, a firm that provides project management and agile services.

“Planning is essentially your execution strategy,” notes Umair Aziz, chief innovation and technology officer at Creative Chaos, an agile adopter that provides media production, casting and event design services. “Too often, the strategy is vague — too high-level for engineers to execute — but using a framework that can be broken down into checklists ensures alignment and provides constant reminders that keep a given project on track.”

The agile release train (ART) is a basic planning tool that aligns individual teams to a common business and technology mission. “Senior management selects projects that will yield the highest cost/benefit to the company,” says Rod Cortez, a senior consultant and engagement manager with technology consulting firm PSC Group. These features are then estimated by the agile teams and planned in sprints (a set period of time during which specific work has to be completed and made ready for review). “Companies that use an agile development methodology efficiently can plan features and projects three to twelve months in advance with a high percentage of success,” Cortez says.

2. Form an unstable, poorly selected team

Team synergy is key to a successful agile program. “If you have people who have worked together — and understand each other’s strengths and weaknesses — you have a head start versus a team of strangers,” Aziz says. “If a brand-new team is being configured, bring in people who have clear interest and passion in what you are doing.”

HR and legacy team structures can be a tricky issue to navigate, but dependencies between teams are the ultimate agility killer, says Steve Elliott, CEO of AgileCraft, an agile management platform vendor. “There are dozens of ways to align teams and break down work to reduce dependencies, and it’s worth the effort up front to minimize team to team dependences,” he notes. “Strategic application lifecycle management (ALM) tools can help identify and suggest ways to optimize teams to reduce dependencies.”

Zucker believes that all agile teams should be self-sufficient. “In other words, they don’t need to rely on other specialty teams to complete their work,” he says. He recommends looking for team candidates who are generalists. “The new industry term is ‘T-shaped’ or ‘E-shaped’ resources,” Zucker says. “T-shaped resources have an area of expertise — or depth — but can work in other technical domains as well.” E-shaped resources, on the other hand, possess multiple specialties.

3. Communicate as cryptically and infrequently as possible

Agile teams with poor communication attributes are aren’t usually successful. “Agile prefers colocated teams where the flow of communication and information is continual,” Zucker says. “Agile wants regular communication with the product owner and within the team.”

Daily rituals like stand-ups and sprint retrospectives provide the best ways to course correct. “If there is no iterative course correction, the team will never get better,” Aziz says. “Make sure impediments are registered and vociferously resolved; make sure lessons learned are shared across the company.”

It’s also important to get all team members — and agile teams across the enterprise — communicating on the same wavelength. “When bringing together many groups, it’s common to have terminology used in many ways,” Elliott says. To position agile projects for success, terminology should be uniform across the enterprise. “Agile is acronym-rich and confusing for business people with limited agile training to begin with,” Elliott says. “If the groups do not use a common terminology, this challenge is accentuated.”

4. Don’t fully understand the project’s scope or focus

Unlike most traditional projects, an agile initiative’s scope is not set in stone. “For agile projects, the product owner sets the vision and roadmap,” Zucker says. “The vision and roadmap guide the development process.”

The roadmap, Zucker explains, will be disaggregated into a series of incremental builds, each providing value to the customer. The items to be developed by the agile team are maintained in a product backlog, a prioritized list of things to be delivered. With each increment, the team pulls items from the top of the list to deliver to the customer.

From its start, an agile project must link the enterprise’s overall strategy — mission, vision, values and goals — into the actual work being done. “This ensures that the work being delivered is tied to the strategic themes and, if it’s not, then you can pivot quickly,” Elliott says. “The use of predictability analytics and velocity will help program managers appropriately scope the program increment planning.”

5. Test poorly and haphazardly

Testing is absolutely critical, says software consultant Tom Brusehaver. “Having unit tests will make the developers more comfortable changing code,” he notes. “Functional tests will also help the developers know that when things change there are effects, and maybe the changes need to be adjusted or the tests will need changes.” Integration testing is also critical. “With the small, sprint-length increments everyone should be able to feel comfortable that the potentially shippable product will do what the product owner/customer wants it to do,” Brusehaver says.

Many agile teams use test-driven development practices, in which test cases are written before the code. “They also use automated tools to maximize the number of tests that can be run on the code,” Zucker days. “Agile also expects close collaboration with the product owner, enabling the team to deliver exactly what was expected.”

6. Fail to win management and staff support

Agile’s benefits are clear, yet it’s a mistake to assume that all parties, particularly enterprise leaders, will be on board from the very beginning. “Transformations are very expensive, which creates pressure for immediate results,” Elliott says. “It’s important that before you start a true agile transformation you make sure someone at the top of your organization supports it, can win the political battles and can repeat the ‘why’ over and over to the team.”

The best way to win support is to demonstrate that agile will actually increase the odds of a successful product delivery. “This has been empirically tested to be true under certain conditions, but should never be taken for granted,” says Areiel Wolanow, managing director of financial security consulting firm Finserv Experts. “To win support for agile, you need to convince your stakeholders that the critical success factors for agile hold true for your particular program.”

It’s also important to address the concerns of staff and managers who fear that agile may negatively affect their careers. “People want to be agile because they intuitively know that they are a relic if they don’t, but it has to be safe for them to make the move,” Elliott says.

Zucker concurs. “Employees need to know that management will ‘let go’ and allow them to be self-managing,” he says. “They also need to see that they can fail small and not be punished.”

7. Disregard customer feedback

Customer feedback is integral to the agile delivery process. “One of the key differentiators between agile disciplines and traditional delivery methodologies is that agile programs expect feedback to be available throughout the project, not just at mandated control gates,” Wolanow says.

Customer feedback is essential for ensuring that whatever the agile team is building will be useful. “In the absence of customer feedback, it’s exceedingly difficult to prioritize which areas to focus on and teams may end up treating everything as important — which is the same as treating nothing as important,” Aziz says.

“Agile builds customers into the process, and that is key to why it works,” Elliott says. “Involve customers in all aspects of planning and development and your likelihood of wining in your market go up exponentially.”

Another important point to remember is that the agile team will use — and rely on — customer feedback when it goes into its retrospective at the end of iteration. “In the retrospective, the team analyzes what went well in that build increment and what can be improved,” Zucker says. “Changes to the internal process are [then] implemented in the next build cycle.”