Resting on Agile Laurels

"During a period of exciting discovery or progress there is no time to plan be perfect headquarters. The time or that comes later, when all the important work has been done. Perfection, we know, is finality; and finality is death." (C Northcote Parkinson).

Now that we're nearing the end of in exciting period of discovery and progress in the Agile approach, I thought you'd like to hear from a few of my former students on what it was like to become successful Agile teams. I was going to give you the five greatest success stories, but unfortunately, my headquarters aren't as well organized as I'd like.

I must be a terrific teacher, because I've got literally hundreds of success stories in my files. I've spent three hours digging in the mess, but I can't seem to find those five, so I'll just grab five at random.

Frank: "I remember you told us that 'growth produces bigness,' but I never appreciated what that meant. After being promoted for our team's successes the third time in less than three years, I had lost my instinct for what was going on, and I couldn't figure out why.

"Eventually I realized that our Agile team was so close-knit we'd been cut off from all our former sources of information—in my case, leisurely lunches with the people depending on me—because I couldn't be allowed to have unprogrammed time.

"So I began to program in some unprogrammed time. It's not the same as in the old days, but it's better than it was a few months ago. I'm trying to convince my other team members to follow my example, but so far they just think I'm slacking off from our real work."

Iris: "We were all promoted because of my role in our team's work in creating and installing a system to operate our machine tools. Nobody had ever done anything like that before in our company, let alone a woman. I was truly proud of my achievement, but technology in the machine tool business moves fast. Within a year there were new developments that could have been improved in the system.

"When some of the people in my team suggested replacing part of 'my' system, I came down pretty heavily on them. At the time, I thought I was being perfectly rational. It was only much later when I saw through the smokescreen my own pride had created. In one year, I had gone from being the solution to being the problem."

Barry: "For the first seven years of my career, I moved from one crummy organization to another. Finally, I arrived here and found a place on an Agile team that really valued my technical competence. I was the primary lead on six major design efforts, which you'll understand kept me busier than I'd ever been before. In those other places, they didn't give me anything terrifically challenging, so I always had time to read, take courses, and go to technical meetings.

"Also, moving from one job to another at least broadened my vision, but now I was stuck in one place—with one standard way of doing things. It took less than two years to become a piece of technical fluff—a real lightweight."

Ahmed: "Over a period of two years on our Agile team, I rose from an unwashed college kid to one of the kings of systems programmers. I had participated in designing and creating such a toolkit of programs and techniques I could make that system sing 'Waltzing Matilda'—and dance to the tune. Then the company bought a new system. Our team was asked to tend the old one during a one-year period of parallel operation—one year that stretched to two. Obviously, we were the best qualified to do it, but we weren't excited about the lack of challenge. To motivate us, they made us a very attractive financial offer. I went along with it, at least partly because I didn't really feel like giving up my top position and starting over at the bottom with the new system.

"The problem came when the old system finally went to the scrap yard. I had no place to go but the bottom of the new system, and everybody except our team had a two-year headstart on us. I decided to take a non-technical position in operations. I don't particularly like it, though the pay is good."

Sue Anne: "For the first three years I was analyst/designer for the marketing department, nobody paid much attention to me. We converted the development group to Agile, and I became the customer surrogate for four Agile teams. Then all four of the systems I had worked on came online within a period of two months. They were all great successes, and suddenly everybody thought little Sue Anne was a genius—including little Sue Anne. I was given three new projects in quick succession, each representing a different department.

"When I was back in marketing, I had take the time to get to know everybody really well on a personal basis. Now that I was so much in demand, my style changed. I was cutting people short and ramrodding my own ideas through meetings. I suppose I don't have to tell you the new projects went nowhere. One manager actually asked the development manager to have me removed. That really hurt, but it's what woke me up to what I had become."

Gee, maybe they weren't such great success stories after all. But these five must be exceptional cases. The Agile approach is so terrific that the majority of technical leaders working with Agile teams must surely glide smoothly from one triumph to the next, not letting themselves be weighted down by past successes. I'm sure I could prove that with cases from my extensive files of success stories, but I'm so busy keeping my published books up to date, I don't have time to keep them organized.

Success Can Breed Failure

Of course, I'm kidding. About my lack of organization, but not about this stories of Agile success—though the names and circumstances have been altered to protect the innocent. And Frank, Iris, Barry, Ahmed, and Sue Ann were innocent.

Innocent of what? Innocent of the way the world works on winners. You see, winning doesn't happen automatically. Boulding's Backward Basis says, "Things are the way they are because they got that way."  [see, The Secrets of Consulting] None of these five winners really thought about why they had become winners until after they became losers. Too late, they realized that their competence had come from their experiences and environment, so that when their experiences and environment changed, so did their competence.

The Agile Manifesto Principles says several things about maintaining tech competence, starting with this:

• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

After becoming winners, our five heroes each worked at a non-sustainable pace, largely due to the Pile-On Dynamic. [see, Quality Software 5, Managing Yourself and Others] In this dynamic, the best-informed people tend to become overloaded. When they're overloaded, they tend to ignore any task that doesn't contribute instantly to the primary task.

In other words, they can no longer pay continuous attention to what made them best-infomed in the first place, thus violating two more Agile Principles:

• Continuous attention to technical excellence and good design enhances agility.

• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Success doesn't happen automatically. It's not Zeus granting you favorable treatment. It's not because you're just better than other people, so don't be smug. It's not just good luck, either. It's constant attention to what it takes to become more effective, but also adjusting your behavior accordingly. You succeed by paying attention, which our heroes did—until they didn't. You succeed by adjusting your behavior—but in accordance with what make you more effective. Our heroes did adjust their behavior—because their environment changed but they weren't adjusting their behavior.

When Agile was first introduced, many people though that issuing a Manifesto and some Principles was all that was needed to transform the way their organization developed software. As the years passed, more and more people realized that introducing Agile required more than saying the right words. But once they succeeded with the introducing, some of them forgot that agility must be maintained—and maintained using Agile principles. There can be no resting on your Agile laurels.

[NOTE: The remainder of this article can be found in my ebook, Agile Impressions, along with several additional new chapters. It suggests some ways each of our five heroes could have avoided the failures that followed their successes.