TITLE: Agile Themes: Honesty and Blocking AUTHOR: Eugene Wallingford DATE: July 26, 2007 1:08 PM DESC: ----- BODY: I recently wrote about a long-running thread on the XP discussion list about defining 'agile'. Another theme I've noticed across several threads is honesty. This entry and the one that follows look at two facets of the theme. In one thread that seems to be dying down, the list has discussed the ethics of "blocking", a term that Scott Ambler borrowed from (American) football to describe teams that create the facade of following the official software development methodology while behind the scenes doing what they think is best to deliver the software. Scott wrote about this behavior, in which some members of the team protect the agile process by Running Interference for the rest of the team, in a 2003 Software Development article. Is it right to do this? As developers, do we want to live our lives doing one thing and saying that we do another? I'm leery of any prescription that requires me to lie, yet I see shades of gray here. I don't think that my employer or our client are better served by actually following a process that is likely to fail to deliver the software as promised. Or, if my team is capable of delivering the software reasonably using the official methodology, then why do I need to lie in order to use an agile process? For me, programming in an agile way is a lot more fun, so there is that, but then maybe I need to find a place that will let me do that -- or start my own. As I mentioned last time, I have not been able to follow the list discussion 100%, and I can't recall if Kent Beck ever chimed in. But I can imagine what he might say, given the substance and tone of his postings the last few years. If you have to lie -- even if we give it an innocuous name like "blocking"; even if we view it as a last resort -- then something is wrong, and you should think long and hard about how to make it right. Agile developers value people over processes, and honesty is one way we demonstrate that we value people. George Dinwiddie has a blog entry that considered a more pragmatic potential problem with blocking. We may be getting the job done in the short term, but blocking is shortsighted and may hurt the agile cause in the long run. If we give the appearance of succeeding via the official route, our employer and customer are likely to conclude that the official route is a good one -- and that will make it even harder to introduce agile practices into the workplace. There is a practical value in telling the truth, even it requires us to take small steps. After all, agile developers ought to appreciate the power of small steps. -----