10,000 Foot Developer

Last year I was working at Huge Company, Inc. and they were trying to implement some agile.  I was brought in as one of those stack lead developers — domain, UI, smile, do a jig etc.  But soon I found myself leading two development/qa teams and kinda of a nightmare on my hands — top-down agile.

You see what would happen was this:  we (doing scrum method) would add our agreed stories to our sprint, start working, and about halfway through a big wig would come in and tell us to drop everything for one of their quickie projects.  This happened several times and we could never get our sprint goals done.  Worse, all the big wigs were going to agile training and still missing the whole point; and none of the task people were getting any training at all.  I wasn’t even allowed to set up our own training time if I wanted.  And we couldn’t get resuources like even regular meetings rooms — at times we’d scrum in stairwells.

What do you do if you are ordered to march agile, but they won’t let you actually do agile? Well this isn’t anything new — it has happened with all the project management styles I’ve been through in all Huge Company, Incs. I’ve been at.  Agile — does not offer a solution for this it is only a software building technique and that is all.

Well, if you are doing waterfall, rup, any ISO style or any other equivalent of agile you know you are up a creek and here’s what I do:

• Allow the leadership who is putting your team into these situations to be accountable for their decisions.
• Wait it out.  Unfortunately many times, especially with non-selfevident methods like agile, no matter what you say nothing will change until others get it themselves.  People have a funny propensity for continued thinking in a box and you just have to wait.
• Don’t struggle and argue,  don’t complain.  Give the paycheck writers what they want.  They may not want timely good software.
• Since you probably know that they really do want timely good software, do what you can in prep.
• Don’t work overtime for crappy underplanned goals.  Failure at the start of agile is imperative for gathering velocity metrics.
• Learn how to report to the big wigs in the agile tool, set up someone, usually the scrum master, as the cock-block to  management and let the task people get their stuff done.
• Don’t let your life go.  Don’t work huge overtime.   For some reason modern agile put its roots like XP in the crapper — don’t do it.  Everything you do outside of work contributes also to who you are at work.   It’s important.
• Track EVERYTHING.  For instance, your starting sprint snapshots.  Make sure all docs are in a version controlled repository even if you have to give the BA’s access to a folder in your code repository to do it.
• Be innovative.  Most times the control freaks will try to get in your way but just do it; developers are creators.
• Again — be patient, do what you can, and wait it out.
• You can always quit too, if its driving you nuts.  I know a QA/build master guy who was ‘totally agile” and it drove him nuts so much that all the developers weren’t doing TDD 100% of the time he had to quit — and he was happier.
• If you really feel strongly about, say “we need Hudson” then mock it up on a system and make a power point and show them the ROI.  If they don’t bite on it, present it to a weekly group and use it on your resume, Knowledge is always win-win.
• Patience.
• Be happy.

The bottom line is, yes, its all about the money and the target of agile tooling and methodology today is not the people who will carry it out but instead the people who are going to pay for the enterprise licensing.   Its just reality.

Here’s my recent example.  We just changed radically changed domains on a 10 year old code base;  its an DMU design (down middle up) — and the objects in the app do not in any way reflect the new database.  We were forced to bastardize the objects to deliver functionality based on what the sales people and management promised.

I ran the numbers — all the indexes, metrix, class relationship charts, analyzed stories and bugs  etc.  showing how brittle our domain code was and the dangers were were in (to change one class meant a physical change 100 other classes; giant huge SQL queries etc.).  The architect and management wouldn’t buy it.

So — all’s I could do was wait.  They had to see it to believe it.  And they are.  I didn’t get my panties in a wad, I wasn’t trying to introduce the newest version of “whatever” — just do a badly needed oil change.

The hardest and most important quality for creative developers to learn is patience. There is many times a bigger picture than what’s sitting in your IDE, right or wrong.  Just be patient, and keep your own box open for improvement.