Micro Focus is now part of OpenText. Learn more >

You are here

You are here

How to really screw up an agile development project

public://pictures/image2015-4-7 13-54-37.png
Paul Korzeniowski Blogger, Independent
 

In June 2008, the United States Department of Labor (DOL) awarded a solutions provider a 10-year, $50.4 million contract to deploy Oracle Financials. The low price seemed to be too good to be true—and it was. Seven years later, the contractor is out of business, and even though the government agency spent $83.7 million, the project is back to square one. The DOL project is a classic study in how not to manage agile application development. So, what leads to such catastrophes?

To some extent, problems are just the nature of the beast. "Software development, whether it is integration of packaged apps, mobile, maintenance, or new, is difficult," says Theresa Lanowitz, founder and analyst at voke Inc.

The demands of agile projects can also overwhelm managers. "In certain cases, the folks at the top—project managers and systems managers—aren't focused or don't have the skills needed to properly oversee the project," says Bart Perkins, managing partner at Leverage Partners Inc., a firm that helps organizations invest in IT.

Shortcomings arise for many reasons. For successful agile software delivery, project managers need to be able to tune out the corporate white noise, focus on the essentials, back slap when appropriate, and prod individuals when needed. The list of requirements is long and getting longer. At the same time, everyone is busy and overworked.

Technical advances carry pluses and minuses. For example, DevOps enables companies to test software more easily, but that change means more releases, longer requirements lists, and more system complexity. Development moves faster, so project managers have less time to troubleshoot.

Failure to communicate

Communication is key to success or failure, and often company communication is mediocre to poor. "The requirements-gathering process is fundamentally flawed," stated Curt Jacobsen, principal at consulting services provider PwC. IT asks the users for a list of every feature desired in the system. Since the customer hasn't yet seen the system, it's impossible for them to accurately outline their needs and desires.

Consequently, the agile requirements list is often vague and underdeveloped. Each requirement should come with any needed information and be able to stand alone, but that's not always the case. The DOL had glaring holes in its documentation: the contract lacked clear language about how the DOL could retrieve its data, and ownership of the system was unclear, Perkins says.

A dearth of appropriate experience is another problem. "Companies manage technologies like one is identical to another, but that is not the case," Perkins says. A development team may be accustomed to working with Microsoft's .Net environment, but the business unit wants the system written in Force.com. Businesses often underestimate the challenge of making the switch. "Companies are not eager to invest in training and internal skills development," says Perkins. Lacking a clear understanding of the development tools, the programming team dives blindly into the project and fumbles and bumbles its way to the finish line.

Fear of making waves

Culture also creates hurdles. These days, many people grow up receiving a trophy and a pat on the back, regardless of how well they perform. Corporations take on that idealistic culture, so every day, everyone must be happy, happy, happy. No one wants to be the bearer of bad news. "If a project is going off the rails, employees are often reluctant to bring the subject up because of how they will be perceived in the organization," Perkins says.

A Leverage Partners client found itself with six projects that were in serious trouble, and the CIO called in Perkins' team to identify the main reasons for the shortfalls. The problem was that the voices of reason were reluctant to speak up. Rather than fixing problems early in the development cycle, which is usually less expensive and more effective, the projects simply moved forward. The gaps between expectations and execution continued to grow, and the firm ended up with a handful of large-scale failures.

Compounding the management challenges, development oversight is shifting. Purchasing power—and sometimes project management—is moving from IT to line of business professionals. The latter are great at defining business needs, but they lack the expertise to recognize the reliability, durability, and stability needed in IT systems.

Poor change management

Change management and IT governance are two areas where these weaknesses become evident. The former brings a level of discipline to agile application development that helps reduce duplication, improve software quality, and keep projects on track. Without a strong understanding and support of change management, projects can flounder.

Governance has become a key issue as businesses rely more heavily on virtual communications. Government and industry regulations have been put in place to safeguard information and ensure honest, transparent reporting. However, while business people may see the need for compliance, they lack the expertise to translate that mandate into application code.

In agile software development, companies often start off with good intentions, but the software supply chain is fragile, explains voke's Lanowitz. The key is to address these shortcomings before the chain breaks.

Keep learning

Read more articles about: App Dev & TestingAgile