Why Agile isn't good for shrink wrapped Product development

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.

Relevant Links

Post-Agilism: Process Skepticism
Agile people still don’t get it
Accountability in a Scrum World
The start of the end for Agile software development?

11 thoughts on “Why Agile isn't good for shrink wrapped Product development

  1. Steve,
    I don’t think the problem is shrink-wrap products, it’s large and distributed development teams. It seems to me that the entire process industry exists because of the problems with large teams.
    You are quite right that wholesale changes of process guarantee failure. My view is that teams should think about what they are doing and choose methods that they like and feel comfortable with. Thinking about what you are doing is more important than what you are actually doing. That is you are more likely to be successful if you adopt methods that you have thought about and believe in than if you follow somebody else’s process in a rote fashion.
    However, management in large companies don’t generally approve of such approaches so I think you will continue to see large companies screw up.

  2. Good words, Steve. That very short turnaround was a key requirement of the system we built at my last job, right up to supporting hot deployment.
    Maybe there are different inferences that could be drawn: are shrink-wrapped products still the right approach nowadays?

  3. Barry,
    I agree and would add are long development cycles right? For example, Microsoft has radically changed it’s approach to shipping it’s ASP.NET bits something that started with their AJAX toolkit. They got lots of feedback early and the kit went through several public iterations a process that they’ve now carried through on with the MVC support.
    One of the things I always struggled with was having features that were ready to ship but that were tied to a release date 10 months out. Somehow you have to find ways to get code into people’s hands faster and long dev cylces ending in shrink wrapped bits isn’t it.

  4. I am in CAP with a number of guys from the Lockheed Marietta plant, including one who is Chief Systems Engineer on the C130-J. He’s recently had to deal with a software development group that thinks Agile is Nirvana. The problem is that business at Lockheed is chiefly on government projects, and contracts are based on milestones, definite deliverables, and in general, things that are anathema to the free-wheeling Agile approach. Specifications are not malleable.
    Until we reach the point where software development becomes more science than art, we will continue to see these movements come and go. And until I see one documented case of an Agile group that finds a way to reconcile their approach with a traditional contract environment, I will counsel against my friend giving support to such fancies.

  5. I should probably have identified CAP as Civil Air Patrol, as many folks seem not to have heard of it.
    To give credit where it is due, the unit testing discipline is one I would not willingly give up. And there is certainly value in pair programming, especially with a rotation, as it will tend to lift the skills of those in need of it, and to make people’s approach more consistent. Frequent builds are an advantage I began exploiting with TP 1.0 😉
    My concerns with Agile, as expressed in my first note, relate chiefly to accountability issues, and to the fierce resistance to fixed requirements that Agile seems to engender. In consulting work, especially with a client whose specification skills may be marginal, the feedback process has always been essential, and the frequent delivery of builds helps to ensure that expectations are in agreement with the developers’ understanding of requirements. But in a more traditional large systems environment such as the Lockheed case, I think that Agile–as a package– breaks down because of the gross conflict in approach.

  6. Hi,
    Excellent article – I really appreciate your knowledge about shrink-wrap products, I have bookmarked it for later viewing and forwarded it on. Cheers.

  7. Hi Steve-
    I agree with much you have to say here. I’ve worked with many different teams, and for the last few years have been a contractor myself. My experience is that every single team has their own unique methodology that works best for them. The ones that work best can’t be classified by any name in particular; they’ve evolved over time as the team learns how to be productive together.
    Once I worked with a gung-ho group of agile developers. There were some very good results, but the religious fervor with with it was implemented ended up tearing the team apart. Hardly a success in my book.

  8. Janice,
    Great point. It’s never a good thing to have zealots on the team with regard to development methodologies. I think the most successful teams find ways to adapt various methodologies as appropriate to get the job done.

  9. Agile is not about developers, its about users. When users can’t specify what they need (well) then Agile will fail. When users won’t dedicate enought time and effort the the process, then Agile will fail. And, when releases can’t be released, Agile will fail. That last may be the problem with a big company like Borland that feels constrained by SOX or other regulation and can’t make a monthly product release with new functionality.
    Steve, I have to agree with your fundamental concerns. I’m not sure what Agile buys you if the organization in the end (product release) is truly commited to waterfall. The most you can hope is that management of development will take some peices from Agile and improve the lot of waterfall developers.
    Anyway, now that you’ve come over to the light side, you have also felt the pleasure of actually delivering your work to a client! Congrats.

  10. Hi Patrick,
    Thanks! I think you’ve hit on a valuable point which is not only does the development team have to be Agile but everyone who touches the process has to be as well. If your customer isn’t able to make quick decisions or changes their mind too frequently the process is bound to fail.

Comments are closed.