Frustrations of a non-Agile Developer

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.”


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.


About Ruprict

I am a nerd that is a Nerd Wannabe. I have more kids than should be allowed by law, a lovely wife, and a different sense of humor than most. I work in the field of GIS, where I am still trying to find myself on the map. View all posts by Ruprict

7 responses to “Frustrations of a non-Agile Developer

  • danrough

    Your post made me smile, some of the things you note have been frustrating me for the last 18 months or so, I’ve got 2 suggestions for you:

    1. Be careful not to chase the wrong thing, don’t chase being Agile, look at how you can deliver value, what can you be doing now?
    2. Keep at it, identify people that understand what you’re talking about and agree with you, get together with those people and start talking
    3. Make sure you’re not alienating people with the message that you’re delivering (something that I have been guilty of)

    If it helps any, as I sit here, I can see 2 teams doing a Stand Up and another team has just walked off to do its’ retrospective and last week I sat in a meeting with the heads of Project Office, Development and our Director and we were talking about how many story points were left to go on a project.

  • Kevin Schlabach

    You can always find an employer who desires agile transition support. There are many companies out there.

    You can go to the Agile 2008 conference to get a lot of advice on this from peers firsthand. Or, you can find a local agile support/networking group (who could assist in the finding of another employer).

    Note: you can go to last year’s conference website and download loads of great presentations including this topic… ( and one of my favorite on this is from a friend of mine J.B. Rainsberger ( but the notes don’t do the presentation justice.

    Or, if you are determined to fight the uphill battle (as I am)… start expanding your “agile book knowledge” from Martin Fowler and Bob Martin to others such as Alistair Cockburn and Linda Rising. You are trying to tackle a business/culture/management problem, so you’ll have to leave the world of geekdom and seek outside help to build the business case and terminology that they’ll listen to. The purist scrum/xp view is not going to get you through those brick walls.

    The renegade option is to find a peer that is interested in agile and just work with them to do it. Adopt practices that management can’t stop or even see (pair programming, daily iteration, auto-testing, etc).

    Good luck

  • ruprict

    Wow. Thanks for the comments and suggestions, gentlemen. Really. @Kevin, I am looking over the links you sent now. I did read the Schaber book (Agile Project Management with Scrum), which is very good. I need to find another one to fuel the fire.

    @Dan – you are dead right about #3. I was guilty of that when I joined my current project.


  • Aaron

    Given some of our conversations are out in the open, I thought I better respond 😉 so ok – here goes.

    First off, I’m completely not against using an Agile approach in projects – I realize that it’s a valuable way to get users involved, productive from a development point of view, and the end product we end up with it pretty much guaranteed to be better than if we buried our heads in the sand (or locked the office door) and coded for 6 months after a quick requirements workshop.

    But, a couple of specific responses dealing with your points above and current frustrations.

    Your current customer isn’t going to be fixed with a change in process. You got the PM on our side to completely re-write the plan and approach to meet your Agile demands/request (and I know, it may or may not be a real Agile approach, but it was definitely better than what was originally being used, and that’s a whole different conversation – baby steps, remember), but if the customer isn’t willing to put “any” people on the project who know what they actually want (or are going to be users of the end system), the process/approach isn’t going to fix that. The last couple of months have definitely been better than the first 6, so we’re making _some_ progress, but there’s still a long way to go, so it’s a work in progress.

    Next point. The specific RFP question – it was an opportunity that came to us through a partner software provider, and as such, we had no relationship or conversations with the client before we got the RFP. There was specific wording in the RFP that would required a firm fixed price for all of the work – so, faced with the choice of bidding, or not bidding (and given the actual work itself was in our sweet spot, and we’re probably the best company to win the work from an experience/technical point of view) we bid it. I’m confident we have a team that can make the project successful if we do win, and whether that means sticking to their preferred methodology they currently use, or educating them on something better, we just have to cross that bridge when we come to it. If we keep no-bidding work just because they don’t like using an agile approach, or we don’t have an opportunity to discuss it before we get in, we’ll start running out of work pretty quickly, and the looking for a job option for both of us will be required, rather than something that we can do on our own terms.

    From a customer point of view, and knowing how the budgeting process works in the companies we do work for, not having a firm fixed price for a specific (very high level) piece of functionality is never going to happen. If you wanted to build a new kitchen for example (again 😉 I’m not sure you’d be happy having saved up all that money, and not having Home Depot tell you exactly what it’s going to cost you when you go through the plans up front. What if you go half way around the room, had a great oven, but realized you ran out of money before you finished the countertop, or hadn’t bought your fridge, because you had spent too much money on having the really nice handles on your cabinet door? Or you just didn’t have enough money in the first place set aside to build a kitchen?

    We have to come up with a way around this issue, because it isn’t going to go away. I think using our experience to price out the work on the big jobs we work on is still valid, and then using a more iterative approach as we go through delivering the project (whether the client knows we’re doing that or not) is a reasonable approach/compromise that both sides could live with.

    If you think that customers are going to sign up for a Sprint 0 and multiple sprints after that without knowing what they’re going to get for their money overall, I think in the majority of cases you’re going to be incorrect (at least in the industries and size of projects we work on).

    Next point – from your approach to pushing the Agile methodology, it seems to imply that you’ve never been on a successful project in all the time we’ve worked together. We both know that isn’t true, so your approach when trying to persuade other PM’s, developers, architects etc shouldn’t imply that. A more softly softly approach, and understanding the specific issues around peoples reluctance to go this way (I know Glenn, I’m asking a lot) would go a long way to people not shutting you down.

    Also, using special words doesn’t make a new process 😉 Relating the new words you’re using to something that you know other people are familiar with and taking the time to walk through what your talking about might help.

    And like I’ve said before, I don’t think Agile is an all or nothing approach – gradually leading people down a path to enlightenment is going to be a lot more successful than demanding to be taken off a project coz they’re not using the methodology you think will make the project successful and solve all problems….

    And from a personal point of view, I’m trying to get educated as quickly as I can without dropping the ball on all the other stuff I’ve got on my plate, so I don’t want you to think I’m shutting you or this conversation, or this approach down. We just have to work out the best way to educate the organization, and how the approach can/will work given some of the constraints we’re forced to work for. Like I said baby steps are better than nothing.

  • ruprict

    Fair enough. We have made very, very small steps on the current project, and you’re right, the source of evil on that project is not the process. So, while I am still frustrated, maybe I should be hopeful too. Point taken.

    The RFP is really what set off this post and, as I said in the post, I understood why we had to go FFP. My frustration comes from every bid being FFP and every excuse being “we can’t change the RFP” The clients in our industry need education, just like we do. The only way they are going to get educated is if companies like ours show them the “better” ways. We can’t show them until we’re educated. We won’t get educated until it’s a priority, and it won’t be a priority unto the project managers say it is. I’ve gone to the source (the PMs), and for the most part, we don’t DO much. We say a lot, but I started this quest over 2 years ago, and the only thing we have to show for it is some faux-agile processes on this project. That is why I am gloomy.

    Oh, and I admit that I am over-the-top, domineering which leads to people shunning the idea before I they really consider it. I am working on it.

    I don’t really want to air too much dirty laundry here. The fact that an executive in my company took the time to read this, understand it, and thoughtfully reply makes me one of the very fortunate employees on the planet.

    Thanks, Aaron. Let’s take more baby steps.

  • Tartley

    I’m late to the party, but I just searched out Glenn’s blog this morning, and am loving it. Hi all!


    Glenn: It sounds like you’re already all over the Kent Beck books, but as I recall there is one specifically aimed at how to persuade people to do Agile. Ah yes, it’s “Extreme Programming Applied”:

    /…advice on implementing XP in your organization, illustrating key points with stories from pioneers who have successfully introduced XP./

    It does cover technical, social and political aspects, as you and Aaron mention above. I think XP and Scrumm have enough in common that you’d still get mileage out of it.

    2) WHINGE:

    The fundamental point of Agile, as with other good software engineering practices, is to do software engineering properly, ie quickly, and with high quality and few defects. If you are at a company whos business model is based upon burning customer money for the duration of the project, then there is a significant institutional disincentive to do projects faster or with higher quality. There is therefore an inherent conflict.

    In such circumstances, you will encounter unwitting resistance at every level. It isn’t deliberate. It comes from the best intentions in the world. But regardless, it makes such changes an impossible task. Eventually, your frustration and disillusionment may begin to show.

    You cannot change an organisation (or even just a project) if it is not receptive to the idea of change. In such cases, it is much easier, faster, and more rewarding to change jobs.


    I don’t know about conventional wisdom over in the Scrumm camp, but I think that traditionally, Agile techniques don’t really provide much benefit unless you do them wholeheartedly.

    For example, if only 5% of your code is tested, you still have no way to know if recent changes introduced new bugs. Only when 100% of your code is tested can you do that. The effort spent creating that 5% tested code will provide some benefit, certainly some tests are better than no tests, but the benefit will be *less than* 5% of the benefits achieved from 100% tested code.


    For what it’s worth, I’m working at a hardcore Agile shop, specifically Extreme Programming, with a few tweaks to suit our circumstances. As a direct result of that, we’re ten* times more productive than any of us have ever been before, our product has incredibly high quality in terms of high functionality and low defects, we work 35 hour weeks with no overtime ever, we’re all incredibly proud of what we build, and coming to work makes us want to sing with joy.

    The cornerstones, for us, are:

    – Fifteen minute stand-up at the start of each day, where we tell each other all the was we fucked up the day before.

    – Then we pair up. Everything we do, we pair program on.

    – Then each pair grabs a user story and gets busy writing the tests and making that functionality work.

    – User stories are very brief human-readable text documents (in a wiki works for us.) A pair will cut-and-paste these into source code as comments, then implement the actions described to create an executable acceptance test. From this point on, this test is our requirements.

    – Each user story is small enough to be completed, from start to finish including absolutely everything, in one to three days.

    – Once the acceptance test is written (and failing) then we design the new product code, and then write a set of unit tests.

    – Create the product code using the usual test-driven iteration until all tests pass.

    – Go home at 6pm (we start at 10am) Did I mention we never do overtime?

    – Everyone thinks we’re barmy. It really works for us though.


  • ruprict


    Thanks for the comments. I’ll check out the book(s) you mention. I have reined in the whinging for a bit, as my first effort to get some agile processes going was not very successful.. However, I didn’t really expect it to be, as we have much to learn and we are currently being led by the blind (me, some others)

    I think we’ll see some training around this stuff within the year and I think the word is getting out. We are typically behind the rest of the software world in implementing the latest stuff. I am mildly encouraged, but not yet cautiously optimistic.

    Glad to hear you are in a great environment. Truth be told, I am a bit jealous…

    Oh, and let’s not forget.. DO shut up, Hartley!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: