Dr. Dobb's Journal - April 2008 - (Page 49)

d04ambler_p3ds 2/13/08 9:42 AM Page 49 by Scott W. Ambler The Agile Edge Anatomy of a Failed Agile Adoption Sometimes it works, sometimes…well, it doesn’t 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. 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. 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 Vmodel 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 Stealth Agile Adoption Winston realized that if there was any hope at all that it lay in the programmers—without responsible, disciplined programmers, all other aspects of Gorwell’s software development strategy were for naught. So, after a bit of research Winston discovered that a wealth of agile techniques existed that the Victory process didn’t include, and more importantly it appeared that these agile techniques worked significantly better in practice. Winston started sharing some of these agile concepts with his colleagues, whom he knew to be open minded and could be trusted not to report his subversive thoughts to senior management. April 2008 l www.ddj.com l Dr. Dobb’s Journal 49 http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - April 2008

Dr. Dobb's Journal - April 2008 Contents Hmmmm Alia Vox Developer Diaries Dr. Dobb's Excellence in Programming Award Conversations Fast String Search on Multicore Processors The Byzantine Generals Problem Optimizing Math-Intensive Applications with Fixed-Point Arithmetic Random Numbers in a Range Using Generic Programming The Agile Edge Effective Concurrency Swaine's Flames

Dr. Dobb's Journal - April 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.