Agile 101: A Workshop

It's been ages since I posted anything here, but now seems like the perfect time to end that drought. Yesterday, I spent the morning and part of the afternoon at a large local company that wanted to get an introduction to Agile. Since one of the people involved with that initiative is a friend and former co-worker of mine, she put out the call to AgileMan and I was more than happy to answer it!

To accommodate the request, I designed a two-part session that lasted 4 hours. There were 22 attendees, along with two colleagues of mine (my wife, Vicki, and another friend). The first half was a presentation called "Agile 101: An Introduction to Agile", in which I did my best to describe what Agile is, and what it isn't. I started off with a very high level definition of Agile (from Wikipedia) in order to provide at least a notion of what it is, and then talked about why we decided to "go Agile" at the work place where I gained the AgileMan moniker.

Next, in order to put some more flesh on the initial definition of Agile, I took the approach of looking at Agile from several different perspectives, specifically trying to capture what people often assume Agile is when they first hear about it:

• a response to the historical high failure rate of software projects
• a loosely-knit collection of lightweight development approaches
• a way of doing iterative programming
• a mitigation strategy against ever-changing customer requirements
• a commitment to quality and customer satisfaction
• the latest buzzword, fad or silver bullet

Taking that path into Agile allowed me to acknowledge what I suspected were some of the impressions already floating around in the minds of the attendees, and it seemed - based on some of the vigourous nods I saw - as if I hit some nails on the head.

I then spent a consider amount of time going through some of the more common principles and practices in the Agile community, such as:

• Inspect & Adapt
• Empower Teams
• Size Relatively
• Co-locate teams
• Work at a sustainable pace
• Don't compromise quality
• Automate your testing

and several others. There were lots of questions during this portion, as people began to wrap their heads around just how different an Agile work place is from a traditional one. Most of the questions were asked in an inquisitive, interested manner, but of course there was the odd individual who made it perfectly clear by his wording that he thought this was all rubbish. No surprise there.

I had to go at a brisk pace through the presentation because we had a full-on activity to do after the break, and that unfortunately meant that I couldn't spend as long on some of the questions as I'd have liked. By this point in my career, it's gotten very easy to tell the difference between a back-and-forth that may eventually lead to a resolution and one where the other person has already made up his or her mind on the subject. I tried to keep the former type going while cutting the latter ones off, but I'm sure I did an imperfect job at that in the final analysis.

After a 15-minute break - during which time I was inundated with more questions, which is always a good sign - we began the hands-on portion of the workshop. The 22 attendees were split into 3 groups of about 7 people each, and each group got one of myself, Vicki or our other guest as their Product Owner. All 3 groups were tasked with "building" (on paper only) the Meal Planner application, based on a visionary set of requirements (lacking in specificity, by design). The deliverables for each feature included screen design/diagrams, test conditions and help texts, and the teams were given four 20-minute iterations in which to do as much of it as they could.

Interestingly, all 3 groups started off working in smaller groups - screen UI vs testing vs help - only to realize, by the end of the first iteration, that they hadn't known enough about what their teammates were doing to be able to do an effective job on their stuff! We had short planning sessions to start each iteration, followed by the doing, then a hand-waving "demo" to the Product Owner and a quick Retrospective before beginning the next iteration. This exercise worked extremely well, as it provided everyone with a taste of what Agile is like: short cycles, lots of adaptation, emerging requirements, high degree of collaboration, etc. As far as I could tell, everyone in the room was fully engaged in the activity, and there was a palpably-high level of energy present for those eighty minutes!

After the 4th iteration, each team briefly presented its "application" to the others, along with what they'd learned in their mini-Retros. Then we wrapped things up, at which time several attendees offered quick testimonials about what they'd learned and how much they'd enjoyed themselves, which was very gratifying to me and my two helpers.

As I usually do in workshops, I handed out a very short, 1-page survey to encourage the attendees to provide feedback on the session. I asked them to rate three things:

• how effective the presentation portion was at introducing them to Agile
• how effective the hands-on activity was at introducing them to Agile
• how effective the Product Owner had been in helping them understand Agile

The results were extremely good, as we received average scores of 8.4, 9.1 and 9.2 (all out of 10), respectively! Those are some of the best numbers I've ever gotten on a workshop! There were also a couple of comments along the lines of "Best workshop I've ever attended", which obviously makes me day!

It still remains to be seen whether I'll be asked to do any more Agile consulting for this particular company, but the signs are promising at this point. Several topics were mentioned as potential areas they'd like help with, including estimation skills, breaking large features up to fit into short iterations, Retrospective facilitation and Product Owner-type training or consultation.

All in all, it was a great day and it took me back to my initial two years as AgileMan!