Running as Root

When I switched jobs recently, one of the reasons I cited was our frustratingly slow and/or incorrect adoption of an Agile methodology. I always have problems organizing my thoughts as to what we were doing wrong, but here's a good post the summarizes some common Agile stumbling blocks. I think we were having problems with variations on 2 through 5 primarily:

No Executive Sponsorship

Well, we sort of did. It was more of a lip service type of thing. Other developer experience certainly varied from mine, but my personal experience was, "if you see anything wrong please point it out so we can promptly ignore it." I think this is a consequence of the fact that it's a company that grew through acquisition (so there are a lot of turf related politics keeping things from getting done) and that it's such a large company. I was simultaneously amazed and disappointed at the rate of progress, if that makes any sense.

Offshore/Outsourced Developers

Well, we had some offshore QA team members in my case, not developers. But we did have developers in two cities. They were in the same timezone though, so I guess that's something. I feel that having everyone in the same office would have been a huge help. That notion of eliminating that wasteful communication and coordination layer by being able to meet face to face seems very appealing. Of course, when you're a big company, you use all these resources you already have regardless of whether or not they're the best location/configuration for the job. Kind of like using WWII surplus supplies during the Korean "conflict." You see, watching all of those MASH episodes finally paid off.

Lingering Waterfall elements

I think this is one of the biggest things we suffered from. Speaking only for the team I was on, we went into our Agile adoption with a strict set of deliverables and a hard deadline and very little flexibility with regards to either. We also did not have shippable software at the end of each iteration and we knew it. There also was no time in the schedule for going back to revisit/improve "completed" features after feedback from the product owner (who was never there).

No Customer

I would say this was a pretty big one in a lot of peoples' eyes. Our product manager / customer advocate was omni-absent and never really understood the product very well.

All's Well That Ends Well?

Now, the funny thing is, at my new company, I work as a third party developer using my previous company's software. I've told everyone I used to work with the same thing: when you work with this stuff away from the daily development issues, it's really pretty impressive. Especially so when you know the timeframe and numerous problems that were faced during its development.

That's where too much success can be a dangerous thing. I've been at several companies that had the attitude, "We're making money, so we must doing something right." It's hard to quantify lost opportunity in the presence of existing success. However, I believe if we had addressed the issues listed above, everything could have been better: software quality, employee happiness, turnover rate…We'll never know.

This entry was posted on Monday, December 19th, 2005 at 4:28 pm and is filed under Business, Project Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.