CIOpedia

So much has been written on Agile Development, its methods, practices and benefits to a software development team.  If you are not fielding calls from vendors wishing to present to you on Agile/Lean methods, perhaps you are already implementing Agile within your organization.

As with most IT methodologies, there have been a great many passionate and alternative views expressed, ranging from the appropriate levels of dogma, to the historical influences of other methodologies to the “post Agile movement” and what that might mean to you.

It seems to me that, in addition to all the constructive discussion of the benefits of this particular methodology, there is another, equally important set of issues to consider when an organization begins to move from the books and presentations into the real world of processes managed by humans.

Following are a few warning signs that might be helpful to watch for as you begin planning your move to Agile.  Note that although this post concerns Agile implementations, the warning signs might apply to just about any new process methodology within IT.

(1) Excessively Dogmatic – where Agile will not be tailored for your business situation in any way.  In your planning meetings, can you see that your team has an understanding of the specific or unique traits of your organization, and has discussed or made plans to tailor Agile to those needs?  In my experience, most mature methodologies have, as part of their approach, an understanding that some tailoring is to be expected within an organization.  Does your team understand this need, or are they imagining that the methodology will be implemented purely as found within a book, with absolutely no changes?

(2) Yet Another Excuse for Re-architecture - CIOs have grown accustomed to hearing about the latest and greatest re-architecture idea (either physical or process), and are understandably wary about architecture-for-architecture-sake.  Is the move to Agile being talked about in terms of the concrete improvements to be expected in your delivery to business customers, with real accountabilities on the part of staff?  We have all seen situations where re-architecture seems to be a never-ending process, with little focus on the actual deliverables coming out of the pipeline.

(3) Cherry-picking – The Agile methodology has a critical mass of core principles and tenets that provide value to an organization when implemented as a package.  In your implementation, are you using such a small part of the methodology, or changing it so profoundly, that it will not have the planned impact?

(4) Corruption – Are individual Agile principles being changed by staff in ways that were never intended?  For example, is the Agile principle of “valuing working software over comprehensive documentation” being turned into “valuing working software over no documentation”?

(5) Panacea – Is Agile being discussed as the silver bullet that will drastically improve your organization’s delivery of software, without a real understanding of how that will occur?  What is your understanding of and confidence level in the implementation?  Are members of your team hoping to be able to point to Agile for blame if there isn’t a substantial improvement in the next software development project?

What additional warning signs would you add to this list for CIOs?