In my last post, Agile Development in the '80s, I talked about the team I was on in the early '80s that was, in many ways, a Kanban team. I was discussing this with a colleague the other day, and he pointed out that my team lacked one very important attribute of an agile team: sustainability.

In the intervening 30 years, I may have fallen prey to the The Way We Were effect ("What's too painful to remember, we simply choose to forget.") There were several aspects of the team that were not sustainable.

We would all come into work around 10 AM, work closely together till lunch time, take a long lunch together, where we designed the product while eating, then come back to the office and work till 10 PM. That was really too much togetherness, since we had no time alone.

In spite of its agility, it really was a death-march project, since we had a fixed deadline, and way too much work to do. And this meant we could not experiment, because there was no time in the schedule for failing. (See my earlier post, Failing so you can win.) There was even a point where the boss asked us to reduce the quality of our code so we could get it done faster. (I had a lot of trouble with this. I know how to write good code, but I don't know how to write code that is only 85% good.)

There were a lot of weird (and bad) interpersonal dynamics between some of the team members, and particularly between the boss and the rest of the team. And the 12-hour days were not sustainable. This really hit home for me when I realized that I had lived in Chicago for a year, and the only places I knew were two restaurants that were open late, and the 7-11 down the street from my apartment.

So why did we do it? I always think about Tracy Kidder's book, The Soul of a New Machine, where he talks about "signing up". This isn't like signing a piece of paper, but is the point where the team starts feeling that the project is their project, and they will do whatever is necessary to make it go. We were young, and we were launching a new product. Most of us had come from a systems programming background and now, instead of just maintaining the systems at a data center, we were Building Something New and Great. That was enough to keep us going for the year or so it took us to make the first release of the product, but it was not sustainable.

Getting teams engaged enough that they "sign up" is important, but they have to be able to work at a sustainable pace, or they will eventually burn out and disintegrate.