Is Your Agile Really Ad-hoc in Disguise?

I worked with a client to help them transform their software development team from an ad-hoc, developer hero model to a planned approach, with testing based upon Agile Techniques.  The approach seemed successful in that the client accomplished specific business objectives that they would not have been able to do in their existing model.

Recently I was talking to one of the leads there and learned that over the last six months much of what we had done was reversed, and old habits (with their resulting consequences) had returned.  It’s always disappointing to see that the long-term results of work one did was not what was expected and I’ve been thinking about what went wrong.  I think that there were two critical success factors that we didn’t achieve namely sustainable leadership commitment and a change to an engineered approach.  My thinking was reinforced by an article in the December 2016 Communications of the ACM by Ivar Jacobson, Ian Spence and Ed Seidewitz titled “Industrial Scale Agile – From Craft to Engineering.”

The leader of the organization was aware of the challenges, and causes of the problems that the team faced.  He, in fact, was the source of some of them.  He followed a very ad-hoc approach, dashing from crisis to crisis handling things with heroic efforts and constantly interrupting his team with new tasks and challenges.  I was aware of the problem, and thought that I had “converted” him to a more disciplined approach.  But as seems that was not the case.  I’m still torn about what I should have done as a consultant?  Should I have promoted actions to have the leader replaced?

The other challenge is that the leader, and the key members of the team had worked together in the “hero mode” for a long time, and while they intellectually understand that the Agile approach was not a substitute for discipline, they didn’t think like engineers – they were craftspeople.  They saw their work as individual effort, based upon their skill and experience as opposed to seeing their work as part of a larger picture, where everyone works to a defined outcome.  The latter is an engineer’s mindset.

I think that many teams I see are calling their approaches Agile, but that’s really a disguise for informal and ad-hoc.  I think that a software team trying to adopt an Agile approach should understand that it is a formal approach to designing, developing, testing and supporting software.  They should not be fooled by the fast turnaround and limitation of formal documentation.  High quality software is engineered, not crafted