Practicing ‘Pure’ Agile.

Recently I started my new job, and I have been spending the past couple of weeks learning about how software is delivered here.  Some of my colleagues, aware that came from a company with a reputation as a leader in Agile, have felt the need to point out, “I realize we’re not doing pure ‘Agile’.  But there are good reasons for that.”  They then explain how contractual constraints and client perceptions required them to operate in a more waterfall-like way than perhaps they would prefer.  I have heard similar things from clients, especially when starting Agile coaching engagements.  Someone would always feel the need to say  “Look, I know this isn’t what’s in the book, but…”

Whenever I hear this, two conflicting thoughts jump into my mind.  The first one is,

If it ain’t broke, why fix it?

There’s a part of me that winces at the term ‘pure Agile’.  What I’ve always found attractive about Agile is that it started as a rejection of rigid processes that rarely seemed to work.  Instead, the founders of the Agile movement expressed Agile as a set of principles. The practices they then introduced were expressions of those principles.  The fact that a number of different disciplines have evolved demonstrates there are multiple, valid ways to achieve the same thing.  Sometimes, the tools we have traditionally used continue to fit the bill as well.  The idea that there is a ‘pure’ form of Agile, therefore, is antithetical to this school of thought.  And if the methods you are using to build software are resulting in happy clients and quality solutions, I’m not going to look askance at you because you produce requirements documents, or because you run four-week sprints.

But then the Agile coach in me kicks in, and the second thought emerges as the question,

What problem are you solving by doing things this way?

OK, so you say you have to create detailed design specs, or a complete backlog of stories.Why? Is this really the best way to solve your problem?  While there can be valid reasons for employing such techniques, it’s important to remember: many of these were discarded or replaced in Agile for good reasons.  We eliminated the requirements definition phase because we recognized that, not only is much of that work was wasted when we chose to drop a feature, but that it can also create resistance to changing the backlog, even in the face of user feedback.

The point is that, in solving one problem, you can create the potential for others.  It is critical that when you chose to employ a more traditional technique or approach that you recognize the risks inherent in that technique, and that you have a strategy for mitigating those risks.   If you don’t, you face the classic “scrummer-fall” problem:  Those elements of Agile that you did adopt have little impact on the real problems in your development process, and you still experience most, if not all, of the problems that drove you to adopt Agile in the first place.

So don’t let Agile purists shame you when you pull out your Gantt chart, or talk about a  project’s design phase.  But make sure that whatever tools or techniques you are using are the right one for the problem at hand, and not just because it is familiar or comfortable for you and your stakeholders.

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply