Loading ...
Sorry, an error occurred while loading the content.

158849RE: ROI of "Engineering Practices"

Expand Messages
  • xyphrnld0x
    Dec 4, 2013
      Hi Adam,

      I've read some of the replies you've received so far, and you're getting lots of great suggestions around piloting, measuring, and the like.  I'll just add my 2 cents (random-access):

      A lot of resistance to new engineering practices is based on (1) fear (you mentioned safety, and fear of loss of safety [revenue] is a powerful fear), and (2) a lack of experience in just how rapidly a change can positively impact the whole system. Some people cling to the believe that software development is inherently messy, and that it cannot get much better than the status quo.

      I recently gave a talk on this very topic (The ROI of Agile Engineering Practices) at a Silicon Valley conference, and I provided three sections of information:

      1. The first was the usual reference material from studies, e.g. Williams on Pair Programming, and Nagappan on TDD.

      2. The other thing I discussed briefly was tools to give execs the ability to identify the constraints they're trying to solve.  I showed them Value Stream Mapping, and we walked through Goldratt's Five Focusing Steps.  This also gives organizations the ability (if they're willing to make the effort, of course) to see how things get better (or worse) when a particular change is made.  As the Theory of Constraints tells us, the constraint "moves" (i.e., when you resolve one constraint, the next one appears).

      3. My own experience as developer and coach.

      Most of my "evidence" for betting on TDD, pairing, CI, and others is based on my own first-person experience on such teams. Every single XP team I ever worked on (as developer or coach) has seen one or two very surprising successes (e.g., a "major architectural change" taking mere days), and that's entirely due to the safety-net of fast, comprehensive tests, and the relentless attention to keeping the code clean and appropriately designed for the known, implemented requirements.

      I've also taught TDD to hundreds of teams, and those who take it to heart (I can usually tell by the end of the 3-day course) have reported back some results that surprised even me.  For example, one Chicago client reported after four months that their latest release of the product was the highest quality release ever (including their very first release):  Fewer defects reported from the field than any other time in their long history!

      You may have found yourself in a catch-22 already, where the leadership refuses to take their own hired consultants at their word, wants to have some idea of how effective these practices will be, but is reluctant to invest too much, as well. 

      Perhaps, additionally, the leadership should be talking to their peers who have adopted these practices. 

      I hope you find something valuable in the above.

      Happy Holidays, my friend!


      PS:  I'm available starting in February, and the bags are always packed. ;-)

      Twitter: @agilecoach
      Delivering the 1/2-day Essential TDD tutorial for the 6th straight year at Agile Development Conference West in Las Vegas, NV, 1-6 Jun 2014.
      Platinum sponsor of Mile High Agile in Denver, CO, 18 Apr 2014.
    • Show all 34 messages in this topic