It’s 2008,

… and the time for guerrilla Agile is over.”

Or so says Gil Borza from Industrial Logic at his talk at SD Best Practices titled “Secrets of High-Performance Agile Implementations”.  Gil’s position is Agile has proven itself in enough places and on enough projects that we should not hide the fact we are doing Agile anymore and just do it.  If you can’t do it, then change your organization.

One of the interesting refrains I heard regarding Agile transitions was the need for executive-sponsored Agile transitions teams with charters, budgets and authority to remove organizational impediments.  It was clear from many of the consultants that organizations who are successful with Agile transitions are the companies who put real money behind these initiatives, run transitions as change management programs using traditional project management tools and invest real money into their staff in the form of training and reduced productivity as the organization learns new skills and behaviors.  Real goals and milestones on what the organization should look like in 6-12-18 months are established and people are held accountable for their progress.  Giving everyone a copy of Kent Beck’s Extreme Programming Explained or Ken Schwaber’s Agile Project Management with Scrum and saying, “OK, now you are trained.  Go do it.” ain’t gonna cut it.

As for the practical side of things, rarely does a mismash of cherry-picked Agile practices work.  Eventually whatever you left out – pair programming, automated testing, lightweight documentation, cross-functional teams, stand-ups, etc. – will come back to haunt you later and kill your productivity.  It is very important in the early stages of the transition process to select teams and projects that are appropriate for the Agile approach.  When you are fixing bugs, there is just not that much to learn about how to be good at Agile.  If you think a team trashing around with legacy issues as there first Agile project will be a success, you are deluding yourself.    Once you have got over that big hump of learning, then you can extend Agile to parts of your organization that are tightly coupled to each other and perhaps tackle those nasty legacy bugbears using a SWAT team of your best technical and business folks.  Another thing to keep in mind, co-locate your teams\product communities as much as possible and don’t break up the communities.  Keep people together with the product.  A lot of time and money was spent investing in these growing and nurturing these communities (I like to think of them as corporate assets) and reallocating “the resources” when a project is done just pours all that money down the drain.

If you are serious about an Agile transition, recognize that every part of the organization that touches software development will have some type of change.  An Agile transition is trying to incrementally change the habitat in which an Agile team resides and to do that you need executive sponsorship.  Oh, if you lose your sponsor, you’re done (until you can find a new one).  Finally, expect to wait about a year before you start realizing the high productivity levels promised by Agile processes.