ITMPI FLAT 005
Main Menu
Home / Project Management / Agile / Agile in Name Only

Agile in Name Only

Saying that your company is agile is quite different from actually having an agile company.  You could say that your company is biggest earner on the planet, and just saying that does not make it true.  This is what James Turner of O’Reilly Programming refers to as being Agile in Name Only (AINO).  Turner suggests that a major part of the problem is that many organizations simply do not understand what it means to be agile.  Being agile is not, as Turner notes, about juggling time, people, and cost to make each area perfect.  In fact, understanding what you can and cannot control may be the first step in truly understanding what it means to be agile:

I’ve written before about “waterfall with a crunchy agile shell,” the problem that if you are trying to control all three of the variables (time, features, resources), you can’t really do agile.  Agile acknowledges the uncertainty in development estimates, and requires the team to stay “ready to ship,” so that when the decision is made to pull the trigger on a release, all the work done to date can be easily consolidated and shipped.  But focusing on keeping shippable units in shippable shape only makes sense if you also embrace the idea of frequent releases, and putting only in the release what fits in the bucket.

For companies that are AINO, sticking to distant dates and short-term “sprinting” goals is done more for the sake of management than for the benefit of developers or the team.  These “short sprints” of two or three weeks, as Turner notes, include time wasted on a great number of overhead meetings that include grooming, planning, retrospectives, and other items.  Furthermore, it requires developers to divide things up into bite-sized chunks whether or not doing so actually benefits the overall project and company.

On the other hand, agile is wise when circumstances allow for quick release dates and low costs thereof.   Turner gives the examples of mobile applications and cloud computing.  He does, however, remind us that, in instances where there are no more than one or two release dates in a year, the benefits of agile begin to decrease.  Just because something is ready to ship does not necessarily mean that it must be shipped immediately.  If you are not going to ship an item immediately, Turner reiterates that “it doesn’t matter that the code you just wrote is ready to ship.”  He continues to explain that you will most likely develop another dozen or so features before the release date, and that will equate to doubt about how shippable the first feature really is.

The overall takeaway here is that businesses need to avoid taking on project management best practices without fully understanding why they are doing so.  If you do not have frequent release dates or project deadlines, there is not much point in being agile in the first place.  Make sure you understand what it means to be agile, because being AINO can really do more harm than good for your organization.


About Anne Grybowski

Anne is a former staff writer for CAI's Accelerating IT Success, with a degree in Media Studies from Penn State University.

Check Also

Shin Godzilla: An Unexpectedly Agile Monster Movie

Last weekend, I had the good fortune to catch a limited screening of Shin Godzilla …

Leave a Reply

Your email address will not be published. Required fields are marked *