
Pop culture aficionados will be familiar with the South Park "Underpants Gnomes," who roam through people's homes stealing underwear in the night. Their business plan is classic and simple:
![]() |
| http://www.queuefull.net/~bensons/2009/01/12/reflection-on-the-underpants-gnomes-master-plan/ |
Everyone likes a plan with three steps. Just invert the first two phases, and you get a pretty good model for tech-only agile:
<more>

I got a tweet this morning about a rival vendor's "State of Agile Development Survey" in which the re-tweeter used hashtags like #shocking and #fail. Looking for a good laugh, I clicked on over to the survey, and realized I #liked the survey and I thought it was #interesting and #helpful to me. I didn't find anything that jumped out to me as a #failure in a particularly #horrifying way. Then for a moment I thought maybe I am not one of the #Agile Cool Kids. Of course the moment was brief and I bounced back quickly--please don't worry.
<more>


Thank you everyone who attended the Agile Express and extended the ThoughtWorks Team a warm welcome. We enjoyed the hearty discussion and look forward to seeing you again.
Attached are the slides from both tracks of the event.
Stay tuned to this page for answers to some of the questions we did not get to during the session.
Warm Regards,
Matt

Agile purists will be frightened to learn that in many enterprise environments, an early step to an agile rollout may be to establish an official agile SDLC process, and to post a diagram representing the process, along with its artifact templates, in some prominent place on the company web site. There will be 3-D box diagrams and arrows on it for sure, along with many links and appendices. The diagrams and artifact templates themselves will go through weeks or months of review before central posting, not to mention what will theoretically happen if your project adheres to the highly edited result.
<more>

I've been having many conversations recently about how to set up the agile teams I'm coaching with the right Product Owner. As we all know, the PO must be empowered to make decisions, yet must also be knowledgeable enough about what the software should do that she can make constant small decisions for the team so they don't have to wait. The PO understands the big picture, understands the small picture, and can set priorities.
I blogged a few months back about how the "Team Room" must be considered a metaphor, not a literal prerequisite to trying agile for the first time. I know I am treading on equally sacred ground (stepping into equally sacred cow pies), but I am going to posit along the same lines that in a complex corporate environment, the "Product Owner" should be considered as a small village, not a literal person. (I hear the sounds of distant drums, or maybe bagpipes, preparing for war). I believe if the village can reach consensus and speak with one voice in a timely way on a consistent basis, the whole agile development team will be in fine shape. The trick is building the right village.
<more>

Log in if you have an account.
Otherwise, register for an account.
For more details, please visit the How This Site Works page.








