Preamble: Here’s a post I wrote nearly a year ago which I’ve sat on until now. I know the Agile vs. Waterfall (or whatever other development methodology) issue has been rehashed a great deal but now that I’m working as a consultant and particularly after having pushed my first project into production, I felt it was time to hit the “post” button.
First, notice that the in the title the “P” in Product is a capital letter. When I was at CodeGear (CG), there was an effort to use $g(Agile software methodology) and I reached a point where I felt it was not good for large, complex, version 10.0 code bases sold through channel sales for profit. To me the $g(Agile Manifesto) describes what I’d refer to as a “close combat” software development that calls for the ultimate flexibility necessary to adapt quickly to a dynamic situation. But that level of flexibility comes at a high price, like close combat itself, given the unpredictable nature of a dynamic environment. It’s been my experience that that’s not retail product development and what I’ve come to realize over the years is that if you fail to evolve your development process along with your product your chances for success will likely follow.
For me, what came out of the formal Agile training I received while at CG and a year spent using the process is that it was worth learning but the team would have benefited more by not trying to completely switch lock, stock and barrel (first mistake). The first clue, which admittedly I missed, came during the training where it was made clear there would be a “transition period”, lasting potentially several iterations before each mini-team could accurately “calculate” it’s velocity. With 20-20 hind sight I believe a better approach would have been to start with a complete review of what was wrong with the existing process and an analysis of why Agile was necessary. I now believe what we did was probably typical of many teams as the “Agile mentality” washed over the shores of development engulfed us all.
We (the development teams at CG) bought into the whole thing, got training, switched project management software, started SCRUM meetings, daily stand-ups, a backlog the works. That was wrong. I think it was too much change all at once and when the product requirements changed late in the process we reconfigured the team to respond accordingly and wound up relying on an older tried and true development process that had been used for years. At that time, CG polled it’s customer base and with that knowledge decisions where made to refocus on other areas of the product. The interesting thing is that Agile more or less fell by the way-side and no one really seemed to skip a beat. We needed a complete RTM plan with priorities and requirements pitted against hard dates. And yes, dates were, and I presume still are significant as CG works towards becoming an independent company. We desired many of the principles of Agile though many of which aren’t new nor unique to Agile. I mean who doesn’t want:
- Satisfied customers
- Sustainable development
- Technical excellence
- Motivated individuals
If your team hasn’t switched to Agile or is perhaps considering switching you need to take a long hard look at your current process and at the very least get your ducks in a row before you decide that a true culture change is best for your team.
I think Agile fits particularly well in the world of contractors (of which I’m now a member), internal facing application development and IT and in those worlds makes a lot more sense. I’m now doing contracting work and I think working on small deliverable chunks over short periods of time is a great way to sustain a project. In fact, working as a contractor on a project several years ago, I didn’t focus enough on Agile principle #1:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Which directly lead to the end of the contract. Needless to say, lesson learned.