“Iterate and release” has its problems, too

One of the teams I’m working with has adopted a sort of customized agile-style development process. I really like it, but a few problems are coming up:

  1. Just like after a heavy workout, you need a warm down of some sort. You can’t just suddenly stop and declare victory after a sprint. There are always a few more things to do, and your brain muscles need to flush out the acids that built up during the race. And just like that feeling the day after a good work out, it’s hard to actually get momentum going again, and a cheerleader only makes you bitter.
  2. Collaborating with other teams in the company is very tricky. Team independence is crucial to the agile process, but that means no two teams are ever in synch. It’s like IM’ing with a friend in Europe. You can catch them for a few minutes in the morning if you get into the office early enough, but by the time you’re ready to actually say something, they’ve logged off and hit the pubs.
  3. Similarly, business operations quickly get out of synch with what’s happening on the ground. The roadmap review or the hiring planning or the marketing communications or the performance reporting should all operate with the same “rapid iteration, frequent release” methods.

    For example, in my previous jobs I kept a big whiteboard marked up with all the key metrics of my business. I stared at it all the time. Patterns emerged with each new line row of data which made the short-term decisions much easier to identify. The 3 year plan was then an abstract vision with tangible month-to-month goals. Of course, we weren’t able to act on many of the short-term needs because the planning for the current year was already locked down.

  4. It seems hugely important to have an abstract framework to work within as a guiding light when you’re chasing 30 to 60 day goals. But agile development doesn’t necessarily have an end point. The goal needs to feel like a BHAG, yet it needs to be as measurable as the end date of your development cycle.

    For example, a news media site may want to chase down a long term goal of “High customer loyalty”. That goal then needs to be measured in terms of things like repeat visits. And so the result of each sprint should be an understanding of whether or not that sprint had an impact on repeat visits.

There are lots of great things that come out of the agile process including an intense focus on a goal that everyone can work towards and the freedom to postpone things that block progress, among many others. However the process is not without flaw.

At some point, all the IT solutions you can purchase and project management processes you can adopt will hit a ceiling. That ceiling is most likely a need to fundamentally alter the goals and direction of the business itself.

2 thoughts on ““Iterate and release” has its problems, too”

  1. Matt – totally agree. We use agile-style iterative development processes to develop new websites for our clients and it’s not a panacea although its responsiveness to change in the environment do massively lower risk. For example one of our clients changed a core part of their business between iterations – the next iteration gave us all the opportunity to embrace this change whereas a waterfall development process would have left the client in a stickier dilemma.

  2. You raise some issues that inevitably come up when you start trying Agile. It’s been over a year since you made this post, so maybe you’ve sorted it out. For what it’s worth, I have a little input. One solid point that you raised is that it is tough to simply end one iteration and start a new one. I have found a few things that have helped in this regard. For one, it is nice to have an iteration review meeting to demarcate the end of an iteration. Discuss what was accomplished, have team members demo their work completed, and have a mini post mortem to get feedback on the process and suggestions for improvement. This helps you improve your process incrementally and then puts the last iteration behind you. Another useful practice is to plan your iteration so that development is done 2 days prior to the end of the iteration. When you spend the last 2 days in the bug fix cycle, it provides the time to tie up the loose ends, mixes things up a bit and provides a bit of a ramp down for developers in most cases, assuming estimates were reasonably accurate. When the next iteration starts, they are more likely to be ready to get back to heads down development. I have written a few articles about Agile topics like sustainable work pace, iteration planning, and other topics that you indirectly raised in your post. In case you are interested, you can read them at http://www.SmartAgile.com.

Comments are closed.