Frustrations of a non-Agile Developer

Thu, Mar 13, 2008 4-minute read
As I look across the landscape of GIS development, I see the tide turning to Agile Methodologies. Specifically, I see SCRUM taking hold and changing the way clients and implementors look at doing their work. Blogs like Chris's make me fell all warm and fuzzy, as I dream of the day where massive, BigDesignUpFront (BDUF) fixed price RFPs are replaced with agile, iterative, pay-per-deliverable/sprint type requests. I am in constant conflict with the people I work with about this very subject. There are 2.4 billion reasons why I have to write this requirements document or that approach document. I push back with YAGNI type responses, begging for us to encourage the client to create user stories and dump the IEEE "shall" statements. This scenario has played itself out since the beginning of the year several times. In the end, while my fellow developers agree with my plight, the program management and client just find me combative and difficult. I imagine they tense up everytime they have to ask me to write a new approach document (oh, you have no idea how I loathe approach documents) and recoil in expectation of my Agile Evangelical Sermon. I have taken the approach of writing user stories for the client as an example, then listing what I think the remaining stories are so they can finish them. After all, having he developer write user stories is akin to having the fox watch the henhouse. So, I get "This is great. We can use these." and just when I think they are getting it someone asks "Have we mapped these back to the requirements?" and my hope is crumpled up and tossed toward the already full wastebasket of former agile dreams where it bounces to a rest on the floor. Well, now that the self-pity party is over, I would love anyone to give me examples of getting stubborn, set-in-their-waterfall-ways Project Managers to listen to the merits of Agile. And I mean REALLY listen. I have sent articles of how to move to agile, I have authored e-mail novels on it, and I have discussed it over beers. Nothing takes hold. I've already been through the patronizing head-nodding, reassuring "uh-huh" discussions that I bet are eerily similar to what my wife gets when she tries to talk to me while I watch TV. They seem to agree, but their actions betray their nodding. Just today I was asked to validate a "high-level" estimate for a MASSIVE (roughly $3 million) project as they submit their RFP. It went like this: Them: "Glenn our hours are X for the first iteration and Y for the second." Me: "2 iterations? Each about Y months long? Also, trying to estimate a project of this size and scope is ludicrous. (I hear the sigh on the other end of the IM) We should ask them if they are willing to spend a little money to go through an Iteration Zero, y'know? Create the Project Backlog, estimate number of sprints, then we can get a really good idea of cost and risk......" (I go on for a bit) Them: "The RFP asked for a fixed price bid against the requirements that are in the RFP. We can't just ignore that." Me: I don't know what to say. I see the problem and agree we can't just ignore the RFP rules and submit whatever the hell we want. But estimating everything up front is just bad, bad mojo. It never works, and whoever wins the work will either 1) Stick with the BDUF approach and fail, or 2) Get the work, and then totally change the approach to something that has a snowball's chance in hell of succeeding. Lather. Rinse. Repeat. Anyway, if you find yourself reading this and have some suggestions beyond "Stop being some a whiny child," I would love to hear them. Truth be told, most of what I know about Agile is "book knowledge", as I have had precious few opportunities to apply the principles in my career.