Recently in Agile Methods Category

Three years ago I had the privilege and honor to recommend to Inovis executives to implement Scrum as their core software method. The “All In!” implementation style was chosen and successfully implemented by colleague and friend Erik Huddleston. To quote Erik:

The results speak for themselves.  In addition to compelling productivity and quality improvements, we also had profound unanticipated benefits.  Within a few sprints, we were using development as a competitive weapon, bringing development to bear to influence the outcome of individual (strategic) sales cycles.  We dramatically increased our innovation through market dialog.  With almost 25000 customers, Inovis struck up quite a market conversation!  Finally, we found that Agile started driving alignment between teams and sites, facilitating tremendous cross product synergy and value.

In a recent post entitled The Agile Flywheel, Inovis’ Ray Riescher describes the effect of the Agile implementation on IT Operations. Here is an excerpt from his post:

Scrum set the flywheel in motion and caused the rest of the IT process life cycle to respond. ITIL’s processes still form the solid core of service support and we’ve improved the processes’ capability to handle intense work velocity. The organization adapted by developing unprecedented speed in the ability to deliver production fixes and solve root cause problems with Agility.

What I think we are witnessing is a manifestation of Agile Business Service Management: a holistic agile methodology running across the IT process spectrum that’s delivering eye popping change and tremendous results.

Since 1994 the Standish Group “Chaos” reports have been regularly mentioned in various posts in software and IT blogs. The following figure from the 2002 study is quite representative of the data provided in the Standish annual surveys of the state of software projects:



The January/February 2010 issue of IEEE Software features an article entitled The Rise and Fall of the Chaos Report Figures. The authors - J. Laurenz Eveleens and Chris Verhoef of the VU University, Amsterdam - give the following summary of their findings:

In 1994, Standish published the Chaos report that showed a shocking 16 percent project success. This and renewed figures by Standish are often used to indicate that project management of application software development is in trouble. However, Standish’s definitions have four major problems. First, they’re misleading because they’re based solely on estimation accuracy of cost, time, and functionality. Second, their estimation accuracy measure is one-sided, leading to unrealistic success rates. Third, steering on their definitions perverts good estimation practice. Fourth, the resulting figures are meaningless because they average numbers with an unknown bias, numbers that are introduced by different underlying estimation processes. The authors of this article applied Standish’s definitions to their own extensive data consisting of 5,457 forecasts of 1,211 real-world projects, totaling hundreds of millions of Euros. The Standish figures didn’t reflect the reality of the case studies at all.

It we are ultimately to gain the full range of benefits of agile methods, if we are ultimately to grow truly agile, innovative organizations, then, as these stories show, we will have to alter our performance management systems…. We have to be as innovative with our measurement systems as we are with our development methodology.

The Standish data are NOT a good indicator of poor software development performance. However, they ARE an indicator of systemic failure of our planning and measurement processes.

Eric Ries has just published a post entitled Continuous deployment for mission-critical applications. In this post he takes a very clear stand on the suitability of continuous deployment to mission-critical applications, as follows:

"I want to directly challenge the belief that continuous deployment leads to lower quality software. I just don't believe it. Continuous deployment offers three significant advantages over large batch development systems. Some of these benefits are shared by agile systems which have continuous integration but large batch releases, but others are unique to continuous deployment.

1. Faster (and better) feedback... Engineers working in a continuous deployment environment are much more likely to get individually tailored feedback about their work.
2. More automation... Continuous deployment requires living the mantra: 'have every problem only once.'
3.  Monitoring of real-world metrics... There are huge classes of bugs that "work as designed" but cause catastrophic changes in customer behavior. My favorite: changing the checkout button in an e-commerce flow to appear white on a white background. No automated test is going to catch that, but it still will drive revenue to zero. Continuous deployment teams will get burned by that class of bug only once. 
4. Better handling of intermittent bugs... For example, consider a bug that happens only one-time-in-a-million uses. Traditional QA teams are never going to find a reproduction path for that bug. It will never show up in the lab. But for a product with millions of customers, it's happening (and being reported to customer service) multiple times a day! Continuous deployment teams are much better able to find and fix these bugs.
5. Smaller batches... Continuous deployment tends to drive the batch size of work down to an optimal level, whereas traditional deployment systems tend to drive it up."

I could not agree more - continuous deployment is very effective as a software quality improvement strategy. Whether you do BSM, ERP, transaction management or any other mission-critical application, thoughtful continuous deployment is an excellent way to go. The laws of software engineering apply to any kind of application you might be developing and deploying.

I believe, however, we might have a metrics problem on our hands. What often happens is that continuous deployment flies at the teeth of the 'Man in the Dock' theory. When a major disruption happens, we look for a single point of accountability instead of deciphering the complex pathways to the disruption. Such a theory in use, of course, leads to less frequent deployments which in the long run adversely affect software quality.

A major task for Agile Business Service Management is the development of metrics that take us away from 'The man in the Dock' mindset. These metrics need to satisfy two criteria:

1. Map software quality to customer value.
2. Help us realize that service disruptions are systemic. They are a matter of complicated pathways, not of the incompetence of one individual or another.

In Backing into the Future, Bernard Knox makes a fascinating observation:

"The early Greek imagination envisaged the past and the present as in front of us - we can see them. The future, invisible, is behind us... Paradoxical though it may sound to the modern ear, this image of our journey through time may be truer to reality than the medieval and modern feeling that we face the future as we make way forward into it."

How appropriate this mental model is in view of the recent and no so recent past. As pointed out by Perez, we should view the burst of the "dot-com bubble" in 2000 and the financial collapse in 2008 as a double bubble which is part of the fifth techno-economic cycle. Building on this premise. I made a bullish 2010 prediction for the Cutter Consortium. Here is the botton line from this prediction:

"I expect 2010 to be the first year of a prolonged golden age. Serious as the various problems we all are wrestling with after the 2008-2009 macro-economic crisis are, they should be viewed as systemic to the way a new generation of revolutionary infrastructure gets assimilated in economy and society." 

Likewise, my prediction for The Agile Executive is optimistic with respect to Agile Business Service Management:

"Agile breaks out of Development into IT (and beyond) in the form of Agile Infrastructure and Agile Business Service Management."

Click here for details of my techno-economic prediction for Cutter, here for my Agile-focused predictions for The Agile Executive. 

The premise of Agile Business Service Management is that software methods can be successfully applied to  domains like IT Operations and Service Management. An illustration of the power of applying Agile beyond programming is given in Anne Gentle's post Agile Across the Enterprise. Anne discusses the kind of hyper-productivity that transforms the econonics of various classes of books. The potential disruption to traditional publishing is mind boggling...

Colleagues Rico, Sayani and Sone recently published a book entitled The Business Value of Agile Software Methods: Maximizing ROI with with Just-in-Time Process and Documentation. Based on hundreds of systemic research studies, the authors cite some very impressive numbers. Even their least impressive numbers are awesome. For example:

• Agile methods ROA 1.6X more than traditional [software] methods
• Agile methods NPV 2.3X more than traditional [software] methods

We do not have anything like this rigorous study in the nascent field of Agile Business Service Management. I would, however, allow myself to suggest that the gains to be had through Agile  Business Service Management might be as impressive. The three main reasons for my suggesting so are as follows:

• Deja vu. Much of the gain in applying Agile methods to software engineering comes from breaking the metaphorical wall between development and test. Likewise, the application of Agile principles, technologies and practices to Business Service Management leads to breaking the metaphorical wall that seperates development and test from operations.
• Life cycle economics. As observed by Boehm, defects fixed during the Operations phase can be two orders of magnitude more expensive to fix than during the Requirements phase, one order of magnitude more expesive to fix than during the Code phase.
• Data-driven decision making. Agile deployment enables "real time" customer feedback. Hence, the quality and timeliness of business decisions are greatly improved.

I don't really know whether colleague Dr. David F. Rico might have an interest in Agile Business Service Management. I will most certainly try to induce him....

I recommend the following acid test in The Agile Executive post entitled Prior to Sprint Zero: A Note on Jakob Nielsen's "Agile User Experience Projects":

If you consider this "prior to sprint zero" approach a bit heavy-handed, I would offer a simple test to assess its reasonableness. Play with a number of IT Service Management (ITSM) products that you picked in random. Once you did so, compare the numbers of those that clearly have services at their core, to the number of those that integrated services into their user interface as an afterthought.

Granted, the test was originally conceived to make a point with respect to the timing of user interface architecture tasks in the cycle of Agile software development. However, it is actually applicable to ITSM products in general. For example, the results of the test cited above are indicative of how far a system management vendor shifted his mindset, architecture, technology and practices from servers to services.

I would actually go one step further to suggest the user interface architecture test as a reliable "bullshit detector" for vendor hype. Whenever a fundamental application paradigm change takes place, the degree to which a vendor embraced the change can be tested by examining the orientation of the user interface. As a potential customer, it tells you how seriously the vendor walks the talk with respect to embracing paradigm changes and investing in so doing in earnest.

Colleague and friend Sebatian Hassinger sent me Jeff Dean's presentation Designs, Lessons and Advice from Building Large Distributed Systems. The presentation is fascinating in quite a few ways, not least of which is the (implied) statements it makes about requirements for business service management at large scale. For example, here is an excerpt from the slide entitled The Joys of Real Hardware:

The bullets listed above resonate with my Agile Business Service Management thinking. They can simply be thought of as the reality underlying BSM at scale. The scale and scope of operating on top of such envirnments necessitate new techniques in BSM. For example, Jeff discusses Protocol Buffers as one such technique used by Google to attain the requisite efficiencies. Likewise, treating infrastructure as code is - as we say in chess - a practically forced variant. In both cases, the traditional wall between development and operations is moot.

Involve your Service Managers in the software development work from the outset.

Malcolm Fry brings up an excellent question in his ITIL Lite article:

So why are there so many people seeing ITIL v3 more as a methodology than as a framework?

As summarized in The Tool is the Method, the phenomenon observed under similar circumstances in Agile initiatives is correlation with sure footedness (or lack thereof). The tendency is to follow the 'prescription' as is until one becomes sure footed enough to interpret it in an intelligent manner. 

Michael Cote, Andrew Shafer and I did a fun podcast on Agile Infrastructure a few months ago. Here is the key excerpt from the podcast:

Israel asks, is ITIL for the data-center like water-fall for development? Both Andrew and I weight in on how much water-fall you can buy into, making analogues to eat-the-whole-pie RUP. This also recalls a conversation I had on another podcast, the IT Management & Cloud podcast with Rob England, aka, The IT Skeptic, on the topic of CMDBs and ITIL.

Click http://theagileexecutive.com/2009/07/17/agileexec004/ for the full podcast. You would not be disappointed...

You do not need to be an expert in Value Stream Mapping to appreciate the power of speeding up deployment to match the pace of Agile development. By aligning development with deployment, you streamline "production" with "consumption." The rationale for so doing is aptly captured in the first bullet of the Declaration of Interdependence:

We increase return on investment by making continuous flow of value our focus.

Flickr and IMVU seem to be doing an exceptionally fine job streamlining the flow of value: every thirty minutes and every nine minutes respectively. A recent presentation in Velocity 2009 by John Allpsaw and John Hammond adds color how development and operations at Flickr cooperate to accomplish "10+ deploys per day."

What does such fast pace mean to the business? In a nutshell, much of the guess work as to what features are really needed is eliminated when you develop, deploy and collect customer feedback in ultra fast manner. Consequently, the company's business design is likely to be transformed. Click here, here, and here for more detailed discussions how the business design gets transformed.