As a solution architect, I'm usually the team member that sets technical direction for a given project and it usually falls to me to negotiate the process with the client that will be used for design and development.  We're trying to move more toward the "Agile is the way we do things" mantra, but I'm not yet ready to slap the guy keeping the lights on.  One of the first questions out of my mouth on a new project or with a new client is, "What's your process?".   Over the past couple of years I've gotten a variety of answers including:

• We don't have one. What's a process?
• We use a hybrid process (perhaps with some agile features).
• Waterfall (~shudder~), spiral, etc.
• We have a formalized Scrum process with "n" scrum masters onsite.

Clearly I'd like to hear that last answer a lot more in the geospatial realm, but more often than not its one of the first three...and that's fine.  As a consultant, it's my job to not only do design and development, but to educate and leave a client with the tools and skills to do their business better when my contract is up.  As the long as the process they use works for them, everybody's happy. Interestingly enough, when I ask them to expound upon their answer and lay out the details for me, some interesting things come to light.  First, many folks that claim to have a formalized agile approach don't have anything in place that a Scrum team would call recognizable...but they'd picked up some lingo along the way and bandied it about profusely.  Second, others who gave one of the first three answers above look pretty to agile to me upon further review.

For example, consider a case where I was informed without ever showing up onsite that, in no uncertain terms, the project we'd be consulting on was going to be managed and run using Scrum techniques. Way cool right?  When I arrived on site and reviewed the larger project plan, I saw that they had taken a formidable list of system requirements (all of which were critical by the way).  No meetings, no further planning, no negotiations or prioritization...just a slap on the back and a "Go gettum' boys!"  Waterfall with some agile lingo sprinkled about for good measure... But consider a second example from another site where I showed up and the client disavowed any adherence to any process insisting on the "Pablo Picasso" approach...in other words, software is art.  A little nervous, I picked the brains in the room and heard some things that turned my frown upside down.  Daily stand up meetings, weekly checkpoints, monthly planning increments preceeded by negotiations as to expected functionality, prioritization of features, post mortems after each "iteration".  Sounds reasonable to me... The point here? If the geospatial industry is going to become more agile as Bouwman and Spagnuolo seem to advocate, we all need to start walking the talk. But saying agile stuff isn't going to produce more good software (witness the "scrummerfall" of my first client example above)...doing agile stuff (the right way, at the right time, for your situation) is.  It also makes me a little nervous about how accurate some of the "Are you agile?" surveys really are.  We've got plenty of research and writing on agile processes, Scrum, etc...it's enough to keep us all reading for years.  But how do we get to place where we're keeping ourselves, and each other, honest about the effectiveness of our dev process?  And does it really matter?