No AgileMan At Agile 2009

I got the official word in the middle of last week that my proposed session for the Agile 2009 conference, "The Real-Life Adventures of AgileMan", didn't get accepted for inclusion in the program. In fact, of the 11 proposals that were made by people within my circle of friends (including my own), only one of them made the cut. Therefore either we're all very inept at writing up interesting session descriptions, or the competition was very fierce this year.

I don't know that my own efforts at "selling" my session idea were all that impressive, but I figured that I'd done OK. For the sake of posterity - and to let the readers of this blog judge for themselves - here's what I had written up:


Overview

What’s really involved in “going Agile”? While every Agile adoption has its own unique challenges and rewards, I’ve written 2 books about my company’s experiences moving from Waterfall to Agile. My focus is always on lessons learned, and we had literally dozens of those by the time we were done! In this session, I’ll be talking about early successes, what surprised us, where we dropped the ball, why role definitions turned out to be so important, where coaching would have helped, and many other similar topics. I think anyone considering a move to Agile would benefit from attending.

Process/Mechanics

In the 2+ years that I spent as my company’s Agile Manager, I was involved with every aspect of our transition to an Agile methodology. I worked closely with the Project Managers, Development Teams, Product Owners, Information Technology and the company’s Executives over that span, and also had several stints as Agile Coach to some of the teams. I’ve written two books (“The Real-Life Adventures of AgileMan (Lessons Learned in Going Agile)” & “More Real-Life Adventures of AgileMan (Year 2: Easier Said Than Done)”) about our experiences, describing our lessons learned so that others might benefit from what we discovered.

Each of my AgileMan books contains 32 chapters, covering a range of topics related to Agile adoption, all told in a conversational tone from the perspective of someone who went through it all first hand. As reflected by the Learning Outcomes for this session, I always regarded our 2-year journey of “going Agile” as having a narrative thread to it. That perspective made it quite easy for me to transform what might have otherwise been fairly dry material into what ended up being a very entertaining series of stories (I’m told). The focus of the books is always firmly on what was learned, even to the point that each chapter ends with a Lessons Learned summary page recapping the key insights that were gained on each particular topic. I believe that the material would therefore lend itself quite naturally to a 90 minute (or longer) interactive PowerPoint presentation in which I recount the key experiences that we had, following the narrative flow from the books, and answer questions from the audience. I’ve done this same sort of thing for various university Computer Science classes here in Ontario and have had great results to date. Obviously the treatment would, by necessity, be somewhat different within an Agile-centric environment like Agile 2009, but I would imagine that anyone attending the conference because they’re considering a move to Agile would find such an in-depth experiential discussion invaluable.

For the conference, I plan to do the following:

• introduce myself in terms of background
• explain why I wrote the two AgileMan books
• provide context for how the material in the books is organized
• spend about 5 minutes on each of a range of topics from my books, including fielding questions from the audience
  

Although the final set of slides will depend on the session length, I would expect to cover many of the following topics, as I run through the chronology of our experiences and what we learned from them :

• the pitfalls that may develop when Agile is mandated down from the top (rather than beginning as a grass roots movement)
• some early signs of trouble (role confusion, under-staffing, shaky legacy code)
• considerations around team composition
• areas where management may send the wrong signals by only “talking the talk” without “walking the walk”
• the challenges involved with promoting a cooperative (Agile) environment while still employing compensation systems that are essentially competitive
• the pros and cons of co-location
• what to look for in a good Agile Coach
• where metrics can do more harm than good
• the role of an Agile Champion
• areas where teams may struggle with providing good estimates
• what can happen when you consistently try to do more with less
• the perils of redefining job titles when not everyone has bought into the new system
• the problem of bug debt
• what it may mean if your team members begin talking about “zone time”
• what a team may look like when it’s sticking to its principles even in the face of opposition
• how to build up trust within the organization, and what can happen if you don’t
  

I typically first describe the “story” aspect of the topic - what was going on in the workplace as it relates to that subject - and then provide a bullet-point list of the lessons that we learned. Tailoring the material to the length of the session (90 or 180 minutes, for example) is simply a matter of expanding or pruning it down to the appropriate number of topics, based on importance and target audience.

Learning Outcomes

• Why we believed that Agile was the right solution to our problem
• How we went about transitioning to Agile
• What the early surprises were
• Where Agile produced the biggest rewards initially
• Which areas of the company struggled the most with Agile
• How Agile was received and perceived by different parts of the company
• What Agile can reveal about an organization’s culture
• What roles proved the most difficult for us to get right
• Where we needed help (and often didn’t seek it out)
• What we might have done differently

While the e-mail notification that I received indicated that I could check my proposal for more feedback on it, there actually wasn't anything there to indicate why it wasn't accepted or what might have made it more attractive.

Oh well... I'm sure it would have been fun to do, and that any attendees in the audience who were either considering an Agile adoption or just starting down the path of one would have gotten a lot out of it. Heck, I wish someone had provided some of the insights that I intended to include in the session back in 2006 when I attended my first Agile conference!