Out Of What Box?

My plan was to quickly write a follow-up to How To Make Mistakes, aiming it more directly towards software developers. I’d planned to pick up where I’d left off, drawing a connection between my earlier topic and Agile software development. But inevitably, just as I sat down to write, a new idea poked its head in. Looking at me with its big, wide eyes, it asked me ever so sweetly: “Can I come in?” “Sure”, I said.

That was my first mistake. Sure enough, hot on its heels came another one, wearing a full-body smile. I couldn’t resist. “OK”, I said, “You can come in too.”

Then a third idea showed up, this one a bit more obstreperous. “You let them in. I want to come in too!” “Uhh… I guess so.”

Some of those ideas were so charming that they were hard to resist. But before I knew it, there was a crowd of them, each struggling to be the first to slide into the keyboard. With all of their jostling, none of them could get through. If I couldn’t break that logjam, this post was never going to happen. “Stop! Time out! All of you, go to your rooms! Now!” I hated to see the looks on their faces, but I had no choice. I’m trying to write a blankety-blank blog, not The Great American Software Book.

That crowd of ideas came out of some discussions about Agile software development at last month’s No Fluff Just Stuff conference in Boston. It’s fitting that in dismissing them (at least for now), I was applying a lesson from Agile: Don’t try to do everything at once. Create and deliver in small increments instead. You get feedback faster this way, and your customers get the use of your work sooner.

This isn’t the first time I’ve taken a concept from Agile to use in domains that are removed from software development. How To Make Mistakes was essentially a distillation of Agile concepts. I’d even suggest that one of Agile’s greatest strengths is that it helps to create a process for making better mistakes. Conversely, one of its greatest weaknesses may be that few people recognize this.

How does Agile help create better mistakes? To illustrate this, I’ll list the guidelines that I set out in How To Make Mistakes with their foundations in Agile:

• Understand the risks: The most popular flavors of Agile, such as Scrum and Extreme Programming, emphasize specific methods for identifying and mititgating risks.
• Define your goals, Seek feedback early and often, Assess and Adjust: I lifted these fairly directly from the Agile Principles.
• Work consciously: This mirrors another Agile Principle: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Such reflection can and should be a part of each developer’s personal work methods too.
• Make your own mistakes. The Agile Manifesto states a preference for “Individuals and interactions over processes and tools.” Similarly, the Agile Principles declare that “the best architectures, requirements, and designs emerge from self-organizing teams.” Put together, these remind us: No process, however intelligently it was designed, possesses its own intelligence.  Human intelligence must be allowed to trump process guidelines. In fact, any well-designed process must include guidelines for overriding and updating itself. Agile processes are living processes.

One of the risks to successful Agile adoption is having unrealistic expectations. Business stakeholders may expect that a “better” software process is one that results in fewer mistakes being made. A more pragmatic expectation might be that Agile can help a team make better mistakes, which eventually will lead to fewer being made. Better mistakes and fewer mistakes both lead to better results.

I may have some other ideas on this, but they’ll have to wait for another time.

“Wheee!” [*Splash*!]

Back to your room! I’m closing this post down now!

Tags: Agile Software Development, Mistakes, Process, Risks