Design

Anatomy of a Failed Agile Adoption

By Scott W. Ambler, March 10, 2008

Most articles focus on the success stories and few on the failures, a wrong that Scott hopes to right this month.

There is mounting evidence that, in many cases, agile software development approaches work better than traditional ones. However, some organizations are still struggling to successfully adopt agile techniques and philosophies. Sometimes it's simply because an agile approach isn't a good strategy for a project team or even the entire organization, but usually it's because cultural barriers within the organization are too difficult to overcome or because the organization doesn't invest sufficiently in agile training and mentoring. Sadly, most articles focus on the success stories and few on the failures, a wrong that I hope to right this month.

Last year, I was brought in to UK-based Gorwell Financial Group to assess a failed software process improvement effort. A gentleman whom I'll refer to as Winston Smith (not his real name) had attempted a grass roots, stealth agile adoption effort within his project team. Winston was an up-and-coming senior technical lead with over 10 years experience in IT. He was well connected with Gorwell because his big brother, whom I'll refer to by his nickname of "BB," ran the IT department. This proved to be both an advantage and disadvantage because although it gave Winston a bit more leeway than most, it also meant middle management was watching him closely. Be that as it may, in the end Winston proved to seriously misjudge Gorwell's organizational inertia.

The Victory Process

It's critical to understand the context. Gorwell had developed the Victory Software Process in the early-1990s, based on the serial V-model process that was becoming popular at the time within the U.S. government. The basic idea was that up-front activities such as requirements analysis, architecture, and design would be validated through back-end activities such as user-acceptance testing (UAT), system-integration testing (SIT), and functional testing (FT), respectively. It definitely wasn't the fastest way to work, but at the time it was believed to be low risk and result in high quality. BB, who leaned towards the melodramatic, came up with the slogan "Victory produces glorious results every time," which appeared on posters throughout Gorwell's IT department.

In parallel, Gorwell developed an IT governance program that provided rewards for conforming to the Victory process. Being the early 1990s, they were just beginning to adopt C++ for new development, and as a result of their OO fervor they created the ++GOOD (GOOD stood for Gorwell Object-Oriented Design) point system. You were rewarded ++GOOD points each time you attended a meeting, wrote a document, reviewed a document, or met a major Victory milestone. Every Friday morning BB would publicly congratulate the top three ++GOOD point earners that week over the PA system and take them out for lunch that day.

The key to the Victory process and governance program was Gorwell's project-management office (PMO). The PMO adopted both the UK's PRINCE (now PRINCE2) project-management guidelines and the U.S.-based Project Management Institute's book of knowledge (PMBoK) to ensure a comprehensive approach to project management. Its slogan was "Create the plan, work to the plan, and measure against the plan," a philosophy that drove all Victory project teams. To educate junior staff, they had a mentoring program called the "Youth League" where senior project managers indoctrinated new hires in the Victory process for their first two weeks at Gorwell, followed up by one-day refresher training courses once a quarter for their first five years.

After a decade of Victory, and after reading about agile software development, Winston realized that the results really weren't as "glorious" as BB was claiming. Projects were routinely late and over budget, although because they took so long and because the PMO kept updating the original estimates few others seemed to notice. Quality was slowly eroding away, but because Gorwell management kept reorganizing the reporting structure, everyone quickly forgot that things had worked better in previous years.

Compounding the problem was the political infighting amongst their business stakeholders, making it virtually impossible to set system requirements in stone at the beginning of projects as the Victory process insisted on. Gorwell had three business divisions based on geographyOceania, Eurasia, and East Asiawhich were always changing their priorities, waging internal political power struggles, and worse yet changing allegiances on a regular basis. The environment was chaotic, and when applying more paperwork into the process didn't help, BB simply decided to start claiming success via internal propaganda. That was the turning point for Winston.

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task.
However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Video

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!