Agile Colony

At work I’m considered the Agile Evangelist by some and “Agile Boy” by others.  Yes, I was once called, “Agile Boy” by a colleague.  You know those colleagues right?  There the ones that think “Agile is the Devil!”.

They are also the folks who truly believe Agile and Lean methods require no project plan; in fact some believe Agile preaches no planning at all.   This is a common misunderstanding that traditionalists hang their hats on to knock Agile down a few pegs in favor of BDUF (Big Design Up Front) projects.  

The truth is that Agile demands that a project vision or feasibility develops into a plan and that plan provides enough data for the business (business, not I.T) to make an informed decision towards validating that the vision should have some form of investment placed behind it and we should start an initial iteration or proof-of-concept to further validate our initial plan.

Agile requires more planning than any methodology known to software project management.   The message in the Agile Manifesto of “Responding to change over following a plan” is intended to mean, “plan, build tests, analyze, design, code, validate tests, demonstrate working software” REPEAT.  They never intended to infer that we sit down and start coding our way in the dark.  Conversely, there are Agile purists that believe you should.  Both extremes contribute to the great many software projects that fail.

So repeat planning?  Yes, over and over again to tighten the vision into demonstrable product over a period of time-boxed iterations or sprints.   That’s the agile premise.    The PMI (Project Management Institute) embedded a similar construct in the PMBOK several years ago.   They call it, “Progressive Elaboration” aka.  learning as we go which all projects despite methodology inevitably do regardless of planning accuracy, and “Rolling Wave Planning” which is simply, take what you learned from the last “wave” and plan again, reforecast and tighten up your project timeline.

Sometimes we want to believe something instead of investing a little time to understand it because it feeds our innate desire to avoid change.   Change is good, especially in Technology fields; it’s impossible to avoid.  

Speaking of change, did you notice in the 4th paragraph of this blog entry how I mentioned, “build tests” before coding?  There’s another concept that causes I.T. “faith wars”…more on that some other time.