Agile Development is right for most organizations.  Modern, competitive release cycles are much too short for more traditional methods, and customers have grown accustomed to continuous improvement in the products they buy.  We live in an age where software updates need to be seamless and frequent.  In a cloud context, it’s a no-brainer – you control the “infrastructure” (be it the service or the application), so there’s no excuse for not updating it constantly.  In a traditional COTS model, the market expects automatic updates with little or no interrupt in production.  The winning formula for vendors and service providers alike is iterative development resulting in code that is always stable and releasable – in other words, Agile (generally Scrum).

Unfortunately organizations can lose their way and become far too reactive, generally leading to divergent code bases, over-commitment, and decaying product quality.  At some point Sales demands a reset – they don’t care what the product does, as long as it works.  Good salespeople can sell working product with limited functionality.  They cannot, for very long at least, sell feature-rich product that doesn’t work very well (or at all).

This is where you come in – the Development executive charged with righting the ship.  Never mind that decaying product is generally a result of undisciplined account and product management.  The most obvious scapegoat is Development.  The sooner you accept that life is not fair, the sooner you can usher in lasting change, for the better, in very little time.

Before you do anything else, build a tight bond with your Product Management executive peer.  It’s both outdated and naïve to accept that Development and Product Management should be at odds.  You are both working toward the same goal, and in an Agile model, you are 100% codependent.  Chances are, the PM is fatigued from not being able to do his/her job well in the first place.  Product Management of course is not about prioritizing contradictory requirements from every individual customer prospect Sales runs into – it’s about building the right product for all customers in all markets the company targets.  While extremely important, the inbound flow needs to be balanced with the business strategy and the “big picture”, then lifted to a product level before any execution takes place.  A good PM will interrupt any question of “can we do <blank>” immediately by asking “what problem are we solving?”  Imagine the horrifying result of designing an airplane based on the (often contradictory) feedback of 100 customers without really thinking about whether it will fly those customers safely and in relative comfort.  As a Development executive, you completely understand this, so it should be perfectly natural to be in lockstep with your PM peer.  Your PM should already be in lockstep with your CTO (if that’s a discreet function in your company), so the internal technology vision will already be factored in.

Now that you’ve agreed to basic terms with your PM, it’s time to start the transformation in 3 easy steps…

Step 1: Sell Agile Development to Customer Support

Given that Sales will soon be happy receiving well defined product that actually works, the biggest remaining stakeholder is your Customer Support peer.  His or her main concern is that existing customers in the field get timely fixes for their bugs.  Unfortunately the company probably has several outstanding code bases due to past indiscretions.  Your priority should be unifying the code bases and offering iterative stable releases very frequently, in order to maximize resource efficiency and boost product quality.  Here is a deal I’ve personally made that worked very well: Development will maintain current (stable) and one previous release.  Customers on older releases, in turn, will need to upgrade.  I had the luxury of having very strong relationships with our largest customers, so this was not as difficult as it could have been.  I handled much of the messaging myself, assuring these long term clients that we would take care of them.  It turns out customers were more receptive to this strategy than our internal support was.  They had simply stopped asking certain customers to upgrade.  Can you imagine if Microsoft decided to support every version of Windows back to 2.03?  Even for a giant company like Microsoft, this would be nearly impossible.  It’s even more difficult for a startup, yet you see this way too often.  Assuming you have the mandate to do what you need to do to right the ship, this must be step 1.

The other thing you must sell, which is more difficult for traditional thinkers to grasp, is that you will be doing active development in a stable release from now on.  Customer Support must buy into the promise of Agile, and iterative, stable development.  Your trump card is the 1 prior release, but in some cases, you may have to agree to 2 prior releases.  The thing you must stand firm on, of course, is that there will be no new development in the mainline of the prior releases, only critical fixes.  To get new features, customers must upgrade, period.  Otherwise, you’re not transforming the process, just changing the realization.  Doing the same thing and expecting different results is the definition of insanity, even if you measure those things a little differently.

Step 2: Sell Agile Development to Your Own Team

Engineers and architects love process, except sometimes when they have to follow it. Some will consider Agile Development to be micromanagement, which obviously it’s not.  Others will meet you with the same level of skepticism of quality and functional improvements as Customer Support did.  Agile is not rigid, but it demands team cohesion and serious accountability.  There’s no place to hide in an Agile organization, and this does create a bit of pressure for many, even if they are already doing a good job to begin with.

What worked very well for me was to offer a big incentive, which is inherently obvious.  Given that I negotiated the Support burden down to something manageable, developers had to do much less of the thing they hate the most: repeating themselves.  Fixes that in the past meant checking code into 3-5 different code bases became 1 or 2.  In exchange for this, I demanded transparency and accountability.  The team bought in right away, and more and more as we developed the practice, which brings us to…

Step 3: Stick to Your Guns, but Keep up Your End of the Bargain

Nothing sells change better than results. The first sprint will be rough, but in no time, you will have the machine running like clockwork.   You’ve made commitments to your own team as well as Customer Support, and if you stick to the process, they will be recognized.  Inherently you agreed to full transparency up and down the chain, so be prepared to summarize the results both to the executive team as well as your board when called upon.  Produce charts.  I’ve found that cumulative burndown diagrams have a magical effect.  It’s easy to show the process working internally, and if you do it well, customer satisfaction will improve, and PoCs will convert more than before thanks to working code.

However – never, ever break sprints.  You may do this very early on but by the 3^rd or 4^th sprint it should no longer be necessary.  Do not split code bases unless it’s for a funded custom project.  If you have 1 product, you should not have 5 code bases.  And finally, measure, adjust, and repeat – your work is never done.  Practice continuous product and process improvement through iteration and you will make believers out of even the worst skeptics.