Try this: Go to Google and search on GIS Project Management.  You'll get back about 2,490,000 results (give or take a few).  Now start clicking on them and see how long it takes you to find a result that remotely resembles an Agile approach to GIS Project Management.  I got about 140 results in before I gave up.  Notice, I didn't search on GIS application development or some similar search term.  I specifically wanted to know how people view all types of GIS Project Management.  There was a reason I tried this search (and no, it wasn't due to sheer boredom at work) . 

The other night, I was at a get together of some regional ArcGIS developers.  They asked about Scrum and we started talking about the requirement that every iteration must produce some potentially shippable product increment.  Being GIS folks, someone asked how you would apply that "rule" to non-development GIS projects.  It made me sit back and think for a bit.  So, out of curiosity, and to find out if anyone out there used an Agile approach to these types of projects, I searched Google using several appropriate search phrases.  To my astonishment, I couldn't find a single reference to anyone using Agile methods for non-development GIS Projects.  In fact, most led me to very rigid, stepwise, waterfall approaches to GIS project management.

Before I got heavily involved in application development and enterprise GIS architecture, I was a GIS analyst and project manager on lots of non-development GIS projects.  How would I have applied Scrum to those projects?  I thought about that for a while.  First I thought, "Maybe it doesn't work outside of our little software development fiefdom?”  I went to sleep that night without a clear answer in my head.  But the next day, I thought some more and decided that Agile practices, and Scrum, could be used to manage non-development GIS projects without any alteration.  For one thing, Scrum is not really a set of "rules", but more a set of guidelines.  Ken Schwaber in his book The Enterprise and Scrum states that projects are "too complex for a single set of rules to suffice in all circumstances".  My second thought was that the phrase "potentially shippable product increment" was confusing to some.  To me, what it boils down to is that at the end of an iteration, a Team must produce something of value as defined by the Product Owner.

Applying my "new" definition, I started to think about how this would apply to non-development GIS projects.  What's valuable to a GIS Product Owner?  Data, definitely data.  Analyses, map products, metadata (always of questionable value), models, and probably others I'm not thinking of.  Now, in the development world, to deliver a potentially shippable increment (or "something of value") every iteration, we decompose user stories into their simplest forms and provide targeted functionality to address that story.  In non-development projects, we can do the same thing. 

Let's consider an example involving a mutli-layer statewide data request from your Product Owner.  We don't have to deliver all of the data in a single iteration.  Have your Product Owner prioritize the data layers.  Maybe the hydrologic data layer is a higher priority than the land-use layer.  If the hydrologic layer will take longer to deliver than one iteration, break it into smaller prioritized pieces.  Maybe your Product Owner is really only interested in second order streams.  Produce all of the second order otream data during your next iteration.  If you cannot complete that data layer in a single iteration, break it down again.  Maybe your Product Owner is currently interested in second order streams in Kitsap County.  You probably get the point by now.  It works for data production and will work for analyses, map products, models...and yes, even the dreaded metadata!  Work can always be decomposed and re-prioritized by you and your Product Owner. 

The point is to constantly provide your Product Owner with something of value that s/he can use at the end of every iteration.  In our statewide data example above, maybe your Product Owner can only view second order streams in Kitsap County this week, but s/he can at least do that.  The next iteration may include second order streams in King County, and so on.  This can even be a benefit to your Team.  You may find that you do not have to deliver a hydrologic data set for the entire state of Washington.  As you deliver valuable increments of data, your Product Owner may decide that the Puget Sound area was really all that was needed now that s/he has been using the data you already delivered.  You're done with that request, on to the next "something of value"!

So, keep delivering.  Keep getting feedback.  Keep adapting your process to deliver the most value possible to your Product Owner.  It doesn't matter if it's a GIS application, analysis, map, model, or metadata...you'll find your Team delivering higher quality, higher value GIS products faster and more efficiently using Agile practices.