I was reading a blog post last month by Dave Bouwman about agile adoption in the GIS industry. He posed a very good question:

"…65% of the software industry have adopted some agile techniques and 40% have adopted an agile methodology. So why are we not seeing more discussion of agile in the geospatial industry? Is the GIS industry still caught in the waterfall?"

I've been ruminating on that question for a few weeks now. Dave and I have discussed it several times with no real answer yet. Then, a few days ago I read a post by Andres on BlinkGeo that posed the question: "Does the GIS needs analysis model need to be updated?".  Another good question.  So I began thinking about why the GIS industry is having so many problems adopting agile practices in general. I was also considering Adres' question.  What does the GIS industry turn to as the authoritative needs analysis model? 

When I travel, I usually take several random books from my bookshelf to read on my trip.  This time I picked up Roger Tomlinson's book Thinking About GIS: GIS Planning for Managers. (For those of you not from the GIS world, Roger is considered to be the "father of GIS" back in the late 70's). This book is regarded in the GIS world as "the" how-to book for large-scale GIS implementations. While I was stuck in a Wilmington, NC hotel room, I thumbed through some of the pages and immediately the light went on in my head. Tomlinson's GIS Planning Methodology is a ten-stage process that essentially says we need to define all of our system requirements up front and do detailed planning before we can think about implementing a GIS. Hope you didn't miss that...TEN STAGES! Mr. Tomlinson goes on to state that "Because GIS planning is usually not a short-term effort, it typically represents a serious commitment of time and money. It can take from six months to a year to look at the overall needs of a large organization." Six months to a year....astounding! The book goes on the espouse a typical waterfall approach to GIS project planning and hardly touches on what it takes to actually implement a GIS.

Now, I respect Mr. Tomlinson because he's a legend in the GIS world.  But I have serious problems with his planning methodology. While it is very comprehensive, it takes too much time for up-front planning and leaves us without a GIS system for at least 6 months. Following this planning methodology, it would be difficult to show any value for our initial investment in GIS for quite some time.  Plans and documents do not represent value.  A working GIS, even a partially working GIS, represents value (or incremental value).  In addition, Tomlinson's approach has us spend so much time planning up-front, that changes to the plan become very expensive down the line. There is a law of diminishing returns with regard to planning. When we reach a certain point, we need to stop refining our planning and get to work. Any additional planning is wasteful. In fact, if we follow this traditional approach to planning and design, we can be assured that we will probably spend up to 50% of our project doing planning, change 35% of our requirements along the way, and using only about 35-40% of the system functionality. In his defense, Roger does say we should plan comprehensively and implement incrementally (but I’m not sure his definition of incrementally meshes with the iterative nature of agile practices).

An agile approach views requirements as inventory. If the requirements are not going to be used, the time spent planning for them is a waste. So, if we have several planning horizons (from nebulous requirements we'll consider way down the line, to fine-grained requirements we'll develop in our next iteration), we can begin delivering value from our GIS much sooner.  As we progress through our implementation, we can continue to refine the coarser requirements only if and when we are actually going to implement them.  We may find down the line that we don't need some of the coarse requirements we thought were important at the outset.  Because we used agile practices and didn't plan for them in detail , we wasted little or no time if we discard these requirements. 

I wrote about effectiveness versus efficiency in my last blog post. I want to emphasize the point that the GIS world needs to become more effective in what we produce. To do so, we need to stop relying on outdated academic texts about GIS implementations. We need to look for better ways to bring GIS development in alignment with the broader software industry. In short, we need to start employing agile practices for GIS development...and we need to do it as soon as possible. Maybe it's time for some unknowns in the GIS world to start blowing away the industry by using agile practices and making some noise. And maybe it’s time we start Re-Thinking About GIS.