There is a common problem I find among development teams that end up failing when they switch to using scrum or other agile processes. Not all teams do this, but I find that many simply don’t understand the underlying concepts behind developing code quickly and iteratively. Too many team members hear “we’re going to work in short iterations” and translate that to “hack it any way you can as long as you get it done fast.” This is especially bad when a superstar programmer (the one in a hundred that can write code 10+ times faster than anyone else) has this particular misunderstanding. The end result is very predictable: an unstable code base that quickly becomes impossible to maintain.

If “hack it in fast” isn’t what is really meant, then what is the desired result? At Net Objectives we’ve tried a variety of phrases to describe this. One we use quite often is:

Add code quickly, while maintaining the ability to add code quickly in the future

Simple, but effective at the same time. Think about this for a minute. You can’t follow this advice by hacking. Hacking implies creating something that is not easily worked on in the future. On the other hand, if you don’t add code quickly, you also fall short of the mark. It is the combination of coding quickly, but effectively that makes the difference. In the past few days I’ve come to think of this as being called “sustainable agility.” The ability to stay agile for the long haul.

Think back on teams you know about that have gone to some sort of agile process. How many broke their own rules over time because they got themselves into a box they couldn’t get out of? Sustainability is important for agile teams. In the end, a team that goes agile but can’t sustain itself, or can’t sustain a predictable velocity is not going to be as valuable as other teams that continue to deliver productive results over a long period of time.

When you think about writing code in an agile environment, think about sustainability. It is really a superset of maintainability but has many of the same basics. Think about use of design patterns, test-driven development and effective programming practices. Be prepared not only for maintenance, but for true change. Design and code so that the most possible decisions are still left as open questions for further down the line. Don’t limit options. Do only as much coding as is required for the specific work at hand. Working at a sustainable, predictable pace with high quality and short iterations will by default produce products that are better, do it faster, and do it less expensively. Teams focused on sustainable agility will continue to build products better, faster, cheaper. Teams that forget about sustainability will tend to lose a little bit in each of those areas over time as they make corrections to decisions made without having sustainability in mind.

Personally, I’d rather be on a sustainable team, wouldn’t you? Write a comment and let me hear about your experiences on sustainable teams and how they worked, or on non-sustainable teams and how things could have been done differently. I think it would make for some good reading by all of us!

Technorati Tags: Lean-Agile

tag with del.icio.us