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!

The First Retrospective

Last week I spent Thursday morning facilitating a project Retrospective for a local development group who'd never held a Retro before. As part of my engagement, I was also asked to do some "training the trainers" in the sense of working with a couple of people there who were interested in taking on the facilitation role in the future. The thinking on the part of the executive sponsor was that they wanted to bring an expert in for an early Retrospective (or more) but not be reliant on him forever, which is a sentiment that I totally agree with and was happy to support.

The preparation for the session started several days beforehand, as I e-mailed questions to the sponsor and also had a phone conversation with him. I'd sketched out a possible structure for the Retro prior to that, and then the two of us hammered out the final details during that call. One of the most important factors we talked about was duration, which ultimately ended up being 2.5 hours. I would have loved to have scheduled it for longer since it was covering an entire 6- or 7-month project. However, the flip side of the coin was that this was going to be everyone's first Retro, and there was concern that being subjected to a full-day session first time out would be too much, too soon. That led to the decision for a meeting running from 8:30 to 11:00 a.m.

When I got on-site Thursday morning, I met with the future-facilitators for an hour and described what would be happening. The three of us got the room ready by putting up some large sticky notes (a mostly-blank timeline, ground rules and the agenda) and I provided a few thoughts on what I believe the facilitator's role to entail:

• keeping the group focused on events and learning, not on people and blaming
• warming up 'cold' rooms and cooling down 'hot' ones
• nipping any personal attacks in the bud
• avoiding ruts in the proceedings by keeping things moving forward
• making each of the attendees feel comfortable with the process itself

I'd planned a warm-up activity that went well (got people talking, generated some light-hearted laughter, felt like fun) and then we drove headfirst into the agenda.

Most of the attendees were slow to open up very much, as you'd expect from people in their first Retrospective. Nothing too contentious came out until more than halfway through, and even then it was offered up fairly tentatively. By the 2.5-hour mark, though, things were getting much more interesting... just as time was up! As one of the trainee facilitators pointed out, it was all we could do to get several of the attendees out of the room even half an hour after it was over! And these were very busy folks, some of whom were missing other commitments in order to stay a little later and chat with us about what they`d just gone through. That sort of thing is really rewarding to see!

The results of the 1-page survey that I handed out at the end were very positive (scores averaged between 8.2 and 9.0 out of 10). In our 1-hour debrief after the session (half of which was chewed up by the hanger-on-ers!), the two trainees did a great job cleaning up the room (while I was waylaid with questions) and then talked about how interesting it had been for them. They were concerned about being able to do what I had done, but I assured them it was easier than it looked! In fact, the toughest part for me was that I was on my feet for nearly the entire two and a half hours, an amount of standing well beyond anything that I've done in the past several months. I'd had the presence of mind to bring a big bottle of water with me so I wouldn't get parched, and yet I didn't think to sit down for more than about 2 minutes over the course of the meeting!

I don't know yet whether or not I'll be invited back for additional work, but this first contract was very enjoyable, indeed. The participants were committed to the process and willing to open up in front of each other and a stranger, and you can't ask much more than that!

This Looks Like A Job For... AgileMan!

Later this week I'm scheduled to facilitate a Retrospective for a local development group. This will be their first ever Retro, and so they've decided to bring in an outside expert to lead it. I haven't done one in a while, but back in the heyday of my AgileMan stint I was facilitating about one per week. Of course, that was with people who I knew (to some degree or another) and this is with strangers... but I'm hoping it's like riding a bicycle, regardless of who makes the tires!

So in preparing for this engagement, I've been working with the executive sponsor to sort out the logistics for the event (what type of room, duration, number and makeup of attendees, etc) as well as to determine what kind of format might work best. Because it's a Retrospective for a recently-completed project that ran for nearly half a year, we're going to do a Timeline as our main source for gathering data. In an ideal world, a session covering this long a period of time would probably be a full day in length. However, since these folks have never been in one before, we opted for a shorter format (2.5 hours). Because of that, I want to get as much data out on the table as quickly as possible, and a Timeline seemed a good vehicle for that.

Once we've completed that activity and found a few hot spots (via a voting mechanism), then the plan is to use the Force Field Analysis process to uncover what forces have worked for and against whatever it is that we're discussing. From that I hope to be able to lead the team in agreeing on a few Action Items that can be applied on the next project to either weaken some of the opposing forces or strengthen the supporting ones.

It's not the most elaborate agenda I've ever set out for a Retrospective, but I'm trying to remain mindful of the fact that this is something new for this group. I don't want to run the risk of overdoing it on the first step of the journey, and these activities seem appropriate for striking a balance between sophistication and simplification. Of course I won't really know how well I did until I hand out my 1-page Feedback Survey at the end of the session, and then review the results. That's always been my best metric for these jobs, and I've learned a lot from what people given me on them.

And naturally, if you're looking for help with a Retrospective yourself, or any other sort of assistance with an Agile topic, don't hesitate to contact me (AgileMan@sympatico.ca). I'm always on the lookout for jobs for ol' AgileMan (superhero at large)!

The Story Point Workshop

I've been meaning to write up a description of the Story Points Workshop that I designed and delivered in 2007 and 2008, but hadn't gotten around to it... until now. I figure that there's always a chance someone will stumble across this blog and be interested in getting some training on Story Points, and so I really should have something here by way of a sales pitch. If you're reading this and would like to know more, please contact me at AgileMan@sympatico.ca and we can discuss it further.

The workshop that I created is intended to be appropriate for anyone involved in the development of software: programmers, testers, integrators, project/program managers, product owners, team coaches and even executives. In other words, you have to possess at least a basic understanding of the process of software development in order to be able to complete the exercises. Note, however, that you don't have to be of a technical bent, as there's nothing in the workshop that requires you to design, program, or even debug any software.

My goal in providing the workshop has always been to increase the attendees' understanding of, and comfort with, Story Point estimates. At the end of the day, I want everyone who took part to feel confident that they can use Story Points themselves - either as producers of them, or consumers - as part of the release planning process.

To get a large group of people, often with disparate skills and perspectives, all the way to that goal, I use a format that's proven to be both effective and fun (based on the results of feedback surveys that I've done at the conclusion of each session). Basically, the day-long workshop goes as follows:

Part 1: Introduction of Story Points

Here I cover the concepts of relative sizing (as compared to absolute) and what Mike Cohn characterizes as "Estimate size; derive duration." I do this through a combination of slide presentation and interactive exercises, the latter of which allow the group to do some estimating on things not at all related to software (eg. figuratively moving piles of dirt). This 60- to 90-minute section ensures that everyone has a solid foundation of understanding around the conceptual portion of Story Points before we move on to applying that knowledge.

Part 2: Estimating in Story Points

For this part of the day, which takes up the majority of the workshop, I introduce a new application called "the Meal Planner." This is a Java program that I wrote years ago, but the attendees don't really see it or any of the code for it. Instead, what they see is a description of what it is, as well as a set of additional features for it. Because the Meal Planner is a simple and fun concept that anyone can grasp within a few minutes, it provides a perfect backdrop to use in understanding how to Story Point items. No one in attendance has any history with it, and therefore it's unlikely that anyone would dominate the proceedings based on any real or imagined "expertise" with it.

The attendees are then broken up into smaller groups of 5 to 7 people and physically separated (by team) as much as possible. Each team is tasked with coming up with Story Points for each of the items on the Meal Planner's product backlog. I serve as the Product Owner for each group, running back and forth between them in order to answer questions or offer clarifications to the requirements that they've been given. This exercise typically takes between two and three hours to complete, as the teams often get off to very slow starts while they go through the "forming/storming/norming/performing" cycle.

Part 3: Comparing the Results

When all of the teams have produced their Story Points for the complete set of backlog items, I bring everyone back together, post their results up on the walls and encourage each team to review what the others came up with. Then I have a representative from each team briefly go through their rationale for each estimate, allowing the other teams to comment or question them. Sometimes the teams will have arrived at similar estimates; often they'll be quite different. We discuss what sort of factors contributed to those results, and build up a list of "What Worked and What Didn't" that help the attendees understand what sort of things contribute to better estimating versus what works against that goal. I usually will also provide my own Story Point estimates (after everyone else has), based on having written the application. All told, this section usually requires about an hour to get through.

There's a slight variation on the above that I've done in one instance, which proved quite insightful for all involved. I had 2 groups in that case, and so I decided to spend most of my time with one, at the expense of the other. Also, I'd planned it so that the "AgileMan-starved" group got a different set of requirements than the other group, with slightly less details in it. The results of this disparity were striking, to say the least: in many cases, the "starved" team produced estimates that were completely at odds with what both the "better-fed" group came up with as well as the "expert's Story Points" that I provided. I think this sort of thing is probably only appropriate if the workshop is being set up for an environment where the product people are struggling to fulfill their responsibilities (as was the case where I did it).

It's possible to get all of the above done in as little as about four and a half hours, although that's awfully rushed and not very conducive to learning. I prefer to schedule it for either five or six hours, in order to allow for regular breaks and to give people the opportunity to reflect on developments as we go along. Something like a 9:30 start, with lunch brought in, and a wrap-up by 4:00, works best. I've done the workshop with as few as a dozen people, and as many as 25 attendees, and both extremes seem to work fine. With fewer than 10 to 12 people, it's difficult to get 2 groups that can compare results. More than 25 would provide quite a logistical challenge for me to facilitate once the smaller groups are formed.

When I took this workshop on the road to a company in the San Francisco area in late 2007, I did 3 sessions there (one per day) and received an average score of 8.7 (out of 10) in terms of "overall quality." One of the company's Vice-Presidents recently recommended me to a colleague based on those workshops, saying that I had "received the most positive reviews from folks that any trainer has at our site, and we've had quite a few." So I like to think that it left a good impression!

"My Life As A PM Is Over: The Company Just Went Agile!"

Last night was my presentation on Agile Project Management to the local chapter of the Project Management Institute, and based on the electronic polling results that were collected right after I finished, I think I did fairly well. Each member of the audience was given a handheld device about the size of a small calculator and then asked to respond to a series of statements along the lines of: "The topic presented by tonight's speaker was informative and interesting" and "Tonight's speaker appeared to be well-prepared" by selecting, on their device, either "1" (strongly agree), "2" (agree), "3" (disagree) or "4" (strongly disagree). For those who were having trouble figuring out how to work their new toys (since this was the first time they had tried this approach), I helpfully offered the advice, "Just press the button labeled '1'!" In most cases, I received scores where the total of "1"s and "2"s put me at or above the 80% mark, which was gratifying to see.

As for the material itself, I had worried that I had too much to cover in 2 hours, but somehow it all worked out, even with a 15-minute break midway through. I spent the first half introducing Agile, and then called for a short break. However, I asked that, during the break, everyone write down how they thought they might react if they went into work on Monday and their boss walked up to them and announced, "Guess what? We're going Agile in a month!" Just before resuming, I collected their responses and read them out for everyone to hear. Here are some representative samples of what I got:

• "Agile? Can we get the Functional Managers to support it?"
• "Good, [but] first educate the clients."
• "Let's go!"
• "Can we still perform accurate Earned Value analysis?"
• "Great, but how do I co-locate with my global team?"
• "1 week cycles??"
• "But what's wrong with RUP?"
• "Great, let's try it. As long as we follow ALL of the steps, not only parts of it."
• "How do we break deliverables into iteration-sized chunks?"
• "Risk of scope creep."
• "How do you budget??"
• "What are the signs that we NEED Agile?"

and my personal favourite:

• "Do Agile? We don't even do Project Management!"

What impressed me most about these results, aside from the variety, was that it was pretty clear that everyone had been paying attention to what I'd been saying up to that point and attempting to rationalize it against their own experiences and work environments. Virtually no one was writing off the notion of "going Agile" as some crank thought experiment that they could laugh off or simply ignore. Also, I'd say that about 1/4 of the responses were of the "Let's go!" variety, showing that there was at least some buy-in among a group that was mostly hearing about Agile for the first time.

During the Q&A session at the end, many of those same concerns were expressed once again. One woman was sure that no budget would ever be approved without a guarantee that the work done would match what was being approved, to which I said, "If that sort of arrangement is working out for you right now, then I don't know why you'd ever want to move to Agile. The organizations that move to an Agile methodology are the ones where things change considerably between initial concept and final installation." Another fellow was understandably concerned about how to create automated tests to replace the extensive manual testing that they currently do at the end of each project, and I said that that was one area where you'd want to allocate time in order to research the new products and services that are coming out on the market for that purpose. "But in the end," I said, "you really don't have any choice: you need to have automated testing, or you'll never be able to do short cycles." I also got asked whether Agile was really only appropriate for "UI companies", to which I was able to describe some of the very-different types of organizations I've heard of - or seen! - doing Agile.

The moderator eventually had to call an end to the Q&A, as I think it might've gone on for quite a while longer otherwise. I received a $25 Chapters gift card for my troubles (which was nice, and unexpected) and eventually took off home to unwind. Sadly I didn't make any book sales, despite having several copies with me for just that reason. Maybe next time!

The Latest Lecture

Today I did my third iteration of the "Introduction to Agile" university lecture for second year Computer Science students. The class size was around 30 this morning (out of a possible 38), which was bigger than it's been in the past. I'd love to chalk that growth up to the AgileMan reputation spreading across campus and bringing them in from far and wide, but I think it's actually just a larger enrollment this time around.

Since my material tends to be the same each semester, what distinguishes the different sessions are the questions posed by each group. Today, one student asked whether Agile only worked for smaller companies, as it seemed to him that it wouldn't scale well. I explained that it had been fairly common for people to assume Agile wouldn't work in larger companies, but that books had then started to appear that provided insight and guidance on how to scale the practices without losing the principles. Because time was limited, I didn't go into any of the examples, such as the Scrum of Scrums (or even Scrum of Scrum of Scrums) concept to facilitate communication between teams, or Communities of Practice to share learning and discoveries. But I thought it was a good question and showed that the young man asking it had been thinking about what he'd been hearing.

Another question was, "With Agile, do you see more instances of burn out?" As soon as this was raised, I realized that nowhere in my slides do I mention the concept of "sustainable pace." I'll have to correct that for future lectures, but in the meantime I explained what's meant by that term. Then I described how you have to reinforce that principle, in both words and actions, and that failure to do so can quickly lead you down the path to an endless series of death marches.

I was also asked what tools are available to use if you decide to go Agile (I rattled off a few, and mentioned that since Nature abhors a vacuum, there were new ones showing up on the market all the time) and what sort of projects would be better suited for Waterfall (a question I've gotten before, and to which I always offer up "heavily-contractual, government and/or highly-specified work where the customer doesn't typically change their mind midstream").

As happened with the third year, 3-hour lecture last November, this one ran out of time before we'd exhausted all of the questions. That's always a much better feeling than what's occurred with previous incarnations of this second year course: few or no questions and a palpable sense of relief from the attendees that it's over! I'm not sure what to attribute the difference to this time around, but it just seemed to flow better all around.