How I Discovered That Agile Can be Taught to 200 People at a Time

I was speaking to some fellow Agilists at an event recently about an Agile training course that I do that can accommodate up to 200 people at a time and they were pretty skeptical that it could be done. Later, I realized my path to creating the course might make an interesting story as well as be a good illustration of the power of self-organized teams. This is that story.

Marvin Toll Creates the First Bridge to Large Scale Training
At some point before the first Agile and Beyond conference, which was held in March of 2010, I was contacted by Marvin Toll and asked to present at the conference. He wanted to know which topics I could present on and I sent him my list.

Marvin chose "Hands on Agile" which had a title and an abstract, but no content. I just had an idea for a small hands-on workshop that might help people better understand what Agile is all about. I agreed to do it and took the first of many serendipitous steps.

You Want Me to Do This for How Many People?!
Luckily I was able to drawn on some material that I had already created for various Agile-related presentations. But then the second unexpected thing happened. One of the conference organizers sent me an e-mail letting me know that I should expect upwards of 100 people to attend my session and possibly many more. I had forgotten to let them know that I was planning on an intimate workshop of about 20 people. Now what was I going to do? I never would have set out to do a hands-on session for more than 20 people, let alone 100 or more!

I realized that all of the hands-on activities were structured around co-located whole teams. Everybody would be split up into teams with one team per table. Assuming that the instructions were easy to follow, each team would work together to figure out and perform the exercise.

I also realized that the question was, did I really believe in self-organized teams or not? Was it possible for just one person to keep over 100 people on track doing self-directed exercises? In the end I either believed in Agile or I didn't and if it worked out it would be another good example of how self-organization works and if it didn't I would learn some important lessons.

The Big Day Arrives
The day of the event I felt as prepared as I could be, but I really didn't know what to expect. Just before the session was about to begin I discovered that the sample user stories that I had so carefully prepared as handouts for each team were missing and I didn't have time to create new ones. And then I discovered that the easels and stickies for each table weren't set up for each table as I had requested and weren't even in the room! I was starting to get knots in my stomach. What would I do now?

I found one of the organizers and asked about my materials. Ten minutes later, all of the easels and stickies were at the front of the room and it was time to start. Approximately 150 people were all staring at me expectantly in 17 teams of 9. Necessity really is the mother of invention. After going through the preliminaries, which included explaining the role of a Scrum Master and having the room from into cross-function teams, two ideas came to me. First, I realized that I had 17 Scrum Masters that had materialized as a result of self-organization. I had them come up and get all of the needed materials for their teams and it looked like I had always meant to do that.

The second idea turned out to be one of the key reasons that the training is so much fun. Rather than use the pre-created user stories that I no longer had, I had each team pick a software project on their own. The only requirement was that it be something that the whole team thought would be fun and had nothing to do with anything they were currently work on. Two examples of projects: an on-line recipe creation and a death ray. Apparently, one of the teams was made up of military contractors.

The Rest of the Story
After a successful debut, I've since repeated it at Agile and Beyond 2011 and will be doing it again at Agile and Beyond 2012 in March. Because it went so smoothly the first time with 150 people, I'm confident it will scale up to at least 200 people with a single instructor. I plan to test that theory in the near future. I also turned it into a full day training course which was offered all over the US last year. A brand new full day version, called Agile Whole Team Training is now available through Valtivity via public courses starting in Boston on March 20th and is also available privately on site or off site.

Exciting New Agile Training Option - Train Your Whole Organization!

Agile training is pretty expensive and generally targeted towards Scrum Masters. If you have a lot of people you want to train, it makes sense to just send the Scrum Masters. But now there is another option. Valtivity is proud to announce its new Agile Whole Team Training program. This course is being delivered in cities near you, starting with Boston, and can also be delivered as a private course either on site or off site.

Agile Whole Team Training allows you to train everybody in your organization (up to 200 people at a time) for the same price as just training the Scrum masters! Not only that, but people will only be away from their work for a single day.

This is a unique one day course which introduces Agile to the whole team and is also a great team-building opportunity. It is for anybody involved in development: management, product managers, business analysts, designers, developers, testers, DBAs, technical writers, project managers, etc. You'll form into cross-functional teams, pick your own software product to "build", and do hands-on exercises as a team. Bring an existing team or join a team during training.

Learn more about this new Agile training option here .

Panning for User Story Gold: Increase business value and reduce costs

Putting User Stories into business value order is a key tennet of Agile, but that's just the first step. There's much more value to be extracted from your user stories using specific story splitting techniques combined with reducing cycle time. By splitting user stories you can separate the gold from the dirt as well as reduce the cost of implementation.

Come check out my webinar on splitting user stories on March 6th at 1PM EST. The session will cover a variety of methods for splitting user stories and reducing cycle time including the "create/read/update/delete" method, the acceptance test method, the split by value method, frequent grooming, Kanban flow, and software tool support.

Announcing Valtivity!

You may have noticed that I haven't been very active here in a while. Over the last year I've been spending more time doing Agile presentations than blogging. Well, that's about to change. I've just started a new company, called "Valtivity". I will now be devoting my time to Agile full time which means that I'll not only be doing presentations, but also blogging in tandem with focusing on Agile training and coaching. Need to get started with Agile or move to the next step in your Agile journey? Check us out at Valtivity .

Valtivity enables companies with a software development component to find and implement their ideal way of working that maximizes value to the company and its employees and allows them to find and serve new market opportunities faster. Valtivity does this by using unique training and coaching methods to rapidly teach the latest Lean and Agile techniques.

For the curious, Valtivity is short for "Valuable Activity." It comes from Lean's focus on activities that provide value.

Valtivity will be hosting its very first Webinar, "Agile - A Focus on Value" on Feb 1st at 1pm EST. Register now!

Here's a little Agile Humor for you. I recognize a couple of these. :)



This comes from my friends over at SmartBear

Introducing Kanban Into an Existing Scrum Implementation

By far, the talk that I am most requested to do is "Scrum and Kanban Like Chocolate and Peanut Butter". I've given the talk all over the US and Europe, most recently in Kiev for Agile EE. Invariably, people come up after the talk and ask how to get started with Kanban. I've given book and coach suggestions, but they are primarily pointers to pure Kanban resources.

Scrum and Kanban Like Chocolate and Peanut Butter
There doesn't seem to be much material specifically geared towards introducing Kanban into an existing Scrum implementation as opposed to going from non-Agile to Kanban. So, I've decided to write a short and concise guide to folding Kanban practices and principles into an existing Scrum implementation called "Scrum and Kanban Like Chocolate and Peanut Butter." I will write the guide via a series of blog entries over the coming weeks. I hope you will follow along with me, asking questions and offering feedback.

Who is "Scrum and Kanban Like Chocolate and Peanut Butter" Intended For?
The first question is: when does it make sense to introduce Kanban where Scrum is already in use? It turns out that is a very complicated question. Rather than answer that question, I'm just going to gear my posts towards folks that match a certain set of circumstances. My material for introducing Kanban into an existing Scrum implementation is geared towards folks for which the following is true:

• You have already been doing Scrum for 6-9 months
• There is a general feeling that things are going better than before Scrum was introduced
• You are using user stories
• You have a definition for "done"
• Your user stories are relatively short with no stories that take longer than 1/2 of the iteration to get to done
• Most stories are "done" at the end of the iteration
• You have an iteration length of 4 weeks or less
• You have a cross-functional (though not necessarily self-managed or co-located) team
• If there is a "business unit" that previously served as "the customer" then you've integrated the business unit and software team at least to the point that there is a product owner on the team which talks to the customer of the business unit, and the business unit is no longer considered to be the customer for the software team.

If you do not have all of the above, you may want to consider getting to this point first prior to taking any of the steps that follow. Over time I'll come back and update some of the points above with links to resources for addressing these points if they are not already true. The first post will be available over the next few days. The guide will be based on my talk "Scrum and Kanban Like Chocolate and Peanut Butter". If you want to get a head start you can check out a recent video of the talk which is available on vimeo.

Agile Book Recommendations

The following books are the main books that I recommend as starting points for learning about the various aspects of Agile. While their is a fair amount of overlap each of them covers a specific topic. The one on leading self-directed teams is not strictly an "Agile" book, but it is one of the few books talking about self-managed/self-organized/self-directed teams that I have found. The Toyota way is also not an "Agile" book but does a great job of explaining the concepts of Lean which I believe are the foundation for Agile.

Click to enlarge.

Sticking to Estimates

I got a great comment from Kelly Waters on my recent post "Scrum: No commitment required" via his web site. After responding I realized that the response was a good basis for this follow-up to my original post.

In the original version of Scrum, the commitment of the team for the sprint is dependent on two things: a good work ethic and good estimates. If either one is an issue, then the work won't be done on time. The “no commitment required” title of my previous post was a bit tongue in cheek. Absolutely commitment is important, but I don’t think that making it part of “Scrum” will suddenly make team members with a poor work ethic suddenly have a good work ethic or team members with problems estimating better at estimating. Nor will having commitment part of Scrum automatically improve a bad team/PO dynamic. 

People with a good work ethic will work hard. If you have folks with a poor work ethic, I believe Agile will expose this more clearly and then you can use your management skills to address it one way or another. Hopefully, with a win-win solution.

Estimates are just that, estimates. They are a good-faith representation of what the team believes it will take with the information they have at hand. When something is discovered, then it is important for the team to communicate that to the PO, but I don’t think it means that they have to stick to the original estimate. Is that “letting them off the hook?” I don’t think so. Let’s face it, if they estimate 8 hours, but it turns out to take 24, the only way to do it in 8 is to do 8 hours “on the books” and 16 hours off. To have the team absorb those extra 16 hours means that they will have to take it out of their own time which is violating the idea of sustainable pace.

If you have a team that consistently misses their estimates, that’s something different. Missing estimates should be the exception rather than the rule. When it becomes the rule, the question is what’s going on? Is team morale low? Why?

When using story points combined with tracking velocity, there shouldn't be a problem with estimates because story points and velocity should make the issue of estimates a moot point. What I mean is that if all estimates are suddenly off by a factor, the result is simply that velocity goes down. If estimates have always been "off" then velocity will not be going up or down, it will just be fairly constant. Since story points and velocity are relative, estimates that are "off" by a factor aren't a real problem.

Instead, the “problem” may be manifesting itself more as a general feeling of “this team just doesn’t seem to be as productive as it could be.” But then you are back to “why not?” I don’t think an enforced framework of commitment will change anything if the team has, for instance, low morale.

On the other hand, if the problem is wildly varying velocity (perhaps due to wildly varying accuracy of estimating stories) then I would venture there is a good chance that the stories are just too big in general and a good remedy to consider is to aggressively split stories into smaller stories.

Scrum: No Commitment Required!

A couple of years ago I first talked about applying the decoupling principle to Scrum. Since then I've turned a bunch of that material into a presentation called “Scrum and Kanban Like Chocolate and Peanut Butter.” I’ve made many updates to the presentation and presented it to a wide variety of audiences. One of the main points of the presentation is that all of the things in Scrum that are coupled to iterations can be defined in such a way that they are no longer coupled to iterations. I argue that once you have done that with everything, there is really no value left in an anchor point which anchors nothing. That is, there is no fundamental need for iterations in Scrum.

From time to time I’ve realized that I forgot to decouple something, figured it out, and added it to the presentation. For example, burndown charts, burnup charts, and per-story timeboxes. The per-story timeboxes were tricky to even notice because in Scrum we generally think of timeboxing at the iteration level, but in effect that also imposes a timebox on individual stories. If you remove iterations without taking this into account then you are also removing the per-story timeboxes.

But recently, buried among the many feedback forms from presenting at Agile 2011, I found three little words: “What about commitment?” Ouch. I had missed a big one! The Scrum team makes a commitment that is tied to an iteration. How could I have missed that?

As I thought about it more, I realized that I do actually address this point in an off-hand way when talking about decoupling story assignment from iterations. However, I am very grateful for the comment. It helped me realize that I had been effectively dismissing commitment as though breaking a promise with a shrug.

Scrum's Commitment

It turns out that Scrum's commitment is a bit too strict. Even the version of the Official Scrum Guide as revised by Ken Schwaber and Jeff Sutherland, the co-creators of Scrum acknowledges this. In the new version of the Scrum Guide, the commitment has been replaced with a forecast. The idea is that the forecast represents the combination of what the product owner wants and what the team believes it can deliver as the next shippable increment. This is a reasonable response, but I think something is lost in the change. Let's look at this another way.

Mutual Trust

The original idea behind Scrum's commitment is that the team commits to finishing what they have signed up for for the sprint and everybody else commits to leaving the team alone. It is really two commitments based on mutual trust. Without this mutual trust, both commitments break down. But both commitments are actually completely unreasonable and don't reflect reality. The goal is good, but the implementation is poor.

The problem is that the team is not prophetic. They can't possibly know how the work will turn out until they have actually attempted it. More often than not, their estimates will be wrong. Sometimes a little, sometimes a lot. Things happen. The product owner is not prophetic either. They can't possibly know what demands of the business will come up or how customer needs may change within the timeframe of a sprint. A set in stone commitment makes it difficult for both parties.

In practice, the most important ingredient is mutual trust between the team and the product owner. This rapport allows the team to go to the product owner when they discover they have made an unrealistic promise and ask to switch out a story. It also allows the product owner to come to the team with a new request that is more important than another unstarted story and ask to swap them.

Decoupling the Forecast

If Scrum now talks about a forecast, and we are comfortable with the transition of commitment to mutual trust, then the real question is how do we decouple the forecast from iterations? First of all, ask yourself if you need it. If you don't, then there's nothing left to do.

On the other hand, if you feel the need for a forecast then the same approach can be used as for decoupling other aspects of Scrum, you simply redefine the timeframe. By default, the forecast is tied to the timeframe of the iteration. If your iteration is currently 2 weeks long, then go ahead and provide a two week forecast. It is a subtle point, but by defining a forecast period on its own, it is no longer tied to your iteration length. For instance, you may be doing four week iterations and then move to two week iterations. But if you decouple the forecast from the iteration then you can keep your four week forecast. And once again, after you have decoupled everything in Scrum from iterations, what's the value of an anchor point that has nothing anchored to it?

You may also be interested in the follow-up to this post, "Sticking to Estimates"

Scrum and Kanban Like Chocolate and Peanut Butter Slides

For those of you that have attended one of my recent talks on "Scrum and Kanban Like Chocolate and Peanut Butter," here are the slides for the presentation. If you haven't already attended the session, be warned that there are no speaker notes and clicking through rapidly may result in vertigo due to the high degree of animation contained within.