Introduction

This article will address a common reaction to those presented with the possibility of adopting agile in their enterprise: skepticism.  CIOs, application development managers, directors, and senior architects will glean the greatest insight from this but development professionals and project managers will find interest too.

On Being Skeptical

As a software professional your skepticism is not necessarily misplaced. There are plenty of agile coaches in the market today professing to deliver faster, better, and cheaper on a regular basis.  Their message is honey in the ears of the right executive.  It becomes even sweeter when you consider the economic climate that many businesses are facing today.  There is opportunism here and it would be well advised to vet any agile coach.

How do I know an agile coach is worth the money?

I’ve devised a simple matrix ( below ) to help guide one in validating an agile coach.

So let’s talk through this matrix a bit.  First, I give pretty heavy weighting to experience here.  In truth we’re not just looking for an agile coach we’re looking for someone with the battle scars of being in the AD/SD world and knowing when and where agile works vs more predictive methods.

We also want to know that they’ve actually implemented agile methods in other places hence the need for validating references.  The key word here is “implemented”.  There are plenty of folks who can regurgitate the agile manifesto and paraphrase the thinking of leading agile theorists, but agile coaches should show a track record of making it happen.

Budgetary management experience, in my opinion, is essential.  If they haven’t managed the dollars/euros/yen around a capital project ( or operating costs ) then they may have a very misguided notion of why projects succeed or fail.   The CSM or PMP who was merely accountable for a timeline with only a misty concept of how it related to money is ill-equipped to profess a transformation of your SDLC process.  Why?  Agile techniques profess delivering software in iterative cycles ( every 2 weeks ).  If some level of requirements aren’t complete by the end of each iteration you have two options on a fixed bid capital effort:

• Don’t do that functionality.
• Postpone it until you do have the capital available.

This sounds fine in theory, but the truth is that every system has some minimal set of requirements that must be completed for the software to be functionally usable.  If the money runs about before the agile projects succeeds in delivering this minimal functionality then your project will be seen as a failure.

Certifications show learning of theory.  I weight them low, but still think its practical to have these ( Certified Scrum Master and Project Management Professional ) if an agile coach is selling himself as a professional in software development delivery.  They should understand and know agile as well as more traditional management concepts and techniques.

Lastly, you should realize that agile adoption is not just a function of the agile coach.  The organization needs to be willing and able to accept the changes agility will introduce.

But my current process works, so why should I switch to agile?

If you have a working process and there is no immediate need to push you to agile then you should take the time to map out a strategy for your development shop.  Agile can be beneficial and Ryan Martens at RallySoft does a decent job of articulating when agile methods can benefit a development project.  His rendition of the Uncertainty vs Complexity diagram proposed in Stand Back and Deliver gives an AD manager a basic tool for plotting his/her projects along these two broad metrics.

What are the benefits if agile is applied to the right type of projects?

Better Risk Mitigation – Agile methods emphasize iterative delivery of software.  A standard cadence and check point to the project sponsors allows for defects, requirements misunderstanding, and general issues surrounding the effort to be mitigated on a timely basis.  Couple this with a daily stand up meeting where team members determine how to resolve issues and coordinate work and risks to the development effort are generally better managed.

Testing starts earlier – Agile development emphasizes vertically slicing your application and developing functionality incrementally.  This is a technical challenge, but assuming the development team can tier the system architecture this way, then your testers can usually start functional testing much earlier in the development cycle.

Increased Sponsor Satisfaction – Project sponsors are involved routinely through agile.  The developers have a direct line to the customers.  This continuous feedback loop usually leads to better communication and understanding between the team and customer.

Stronger Team Accountability – It takes time, but as the team culture shifts from command and control to a collaborative effort where developers take responsibility, collectively, for their work; the team begins to see how their efforts help/hinder the project.   An adjunct to this is an increased sense of pride in their work and kinship with each other.

What do I need to watch out for when adopting agile?

Cultural Shift – This can’t be under weighted.  Agile places greater emphasis on the team managing itself and its day to day activities. Subtly, agile preaches two things:

1. Development team and customer working together.  Meaning other managers and IT leadership have a de-emphasized role.  Your risking attrition by some of your better players if you ignore this.  Proper coaching and preparation for this change and its effect on roles and responsibilities is essential.

2. Team stepping up and coordinating activities among it’s members.  This is normally done by a PM or Dev manager or even a senior technical leader.  Some methodologies, like Scrum, emphasize a new role ( scrum master ) to take on the facilitation aspects.  For developers unaccustomed or uncomfortable with organizing and planning this may be difficult.

“Documentation is not needed”  – You may hear this from some agile coaches and theorists.  The original agile manifesto emphasizes working code over documentation, but as a development professional you’ll need to decide if this really makes sense  for your project.   Some of us have regulatory and legal reasons for documentation.

Dogmatic Views – I wrote about some of this in Bad Attitudes of Agile, but some team members will see agile as a very strict set of practices and may twist the theories and methodologies to suit their own ends.  By its very description agile is meant to be a flexible approach to software and application development not a rigid set of rules that cannot be altered.  There are the pragmatic agilists and then there are the agile zealots.  Watch out for the latter.

Summary

Benefits can accrue from agile methods.  These benefits, for the right projects, should result in better quality, reduced cost and schedule variance associated with requirements misunderstanding and defect management, and a more complimentary relationship with your customers.  As mentioned earlier skepticism is not misplaced, but by looking for an opportune experimental project to introduce agile a development manager can assess its applicability for his/her shop.