{"id":187,"date":"2009-04-09T10:51:09","date_gmt":"2009-04-09T15:51:09","guid":{"rendered":"http:\/\/www.outofwhatbox.com\/blog\/?p=187"},"modified":"2009-04-27T19:55:51","modified_gmt":"2009-04-27T23:55:51","slug":"living-agile","status":"publish","type":"post","link":"https:\/\/www.outofwhatbox.com\/blog\/2009\/04\/living-agile\/","title":{"rendered":"Living Agile"},"content":{"rendered":"

My plan was to quickly write a follow-up to How To Make Mistakes<\/a>, 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.<\/p>\n

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.”<\/p>\n

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

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<\/em>, not The Great American Software Book.<\/p>\n

That crowd of ideas came out of some discussions about Agile software development at last month’s No Fluff Just Stuff<\/a> 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<\/em>. Create and deliver in small increments instead. You get feedback faster this way, and your customers get the use of your work sooner.<\/p>\n

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<\/a> 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.<\/p>\n

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