Agile Advice

October 12, 2007

Agile Classroom Management

I'm fascinated by the idea of applying agile methods outside of software... be it to business management, family and household, or, as I and my father have been exploring over the last two and a half years... agile classroom management. Here's how I do it in my Agile Project Management / ScrumMaster Certification courses:

My father, Garry Berteig, had been using agile methods in his classroom for over two years before I tried it myself. I had gone into one of his courses at Keyano College in Fort McMurray to give a presentation to his second-year media students on agile and Scrum. They used it for a video project (see "A Student Documentary Film Project" and "Scrum Saves the Day for Media Student". Out of that experience, and others, he developed the idea of the Learning Circle as the basic cycle in an agile learning environment.

In the meantime, I became a Certified Scrum Trainer. Back when I did it, this just meant co-teaching a Scrum class with Ken Schwaber. He had a standard slide deck which he presented as he masterfully guided a class through two days of Scrum training. I (as expected) took that deck and made it my own by reformatting, rewording, changing a few of the exercises, and changing the emphasis in a couple of spots. And then I used that deck with minor corrections and updates and some expansion over the course of the next 16 months.

In the meantime, I was also doing a fair amount of training for teams and organizations that didn't care particularly for Scrum, but just wanted to know more about this "agile" thing. Sometimes it would be a one-day course, sometimes as much as five days (that was exhausting!!!). I developed a substantial body of modules including exercises, case studies, and special topics. Eventually, I found that I was having a hard time fitting my fixed agenda materials into the time I had allocated. For example, I was commonly doing a three-day course and would find that by the end of the first day I was a little behind on my agenda and by the middle of the third day I would certainly be running out of time and miss possibly even two or three modules in the agenda.

Finally, last Sprint, I got a big client who asked for training for a large number of their staff. This gave me the opportunity to: a) work with the same materials and agenda at least three times, and b) involve an assistant in all three deliveries. The first time through, I had the typical problem where the third day was a terrible rush. The second time through, it happened again, but I had de-scoped and re-arranged some of the material so it didn't seem as bad. After that second time, my assistant, an excellent coach, David Chilcott, suggested that I try to apply a more flexible... agile... approach to handling the materials. We did a quick revision of the materials to support this idea and then the third class was run as an "agile training environment". What did this mean?

The main insight was that the time allocated to the class was timeboxed. This meant finding a way to prioritize the work of the class so that the majority of the participants would get the best value possible for their time in the class. We did this in two ways:

1) As questions came up, we found that some of them needed to be deferred because they would be answered in a later module or because there was background material that needed to be covered first. So, for every question that needed to be deferred, we wrote it up on a 3x5 note card and put it up on the wall. Now, in order to keep track of this, we also had all the course modules written up on 3x5 note cards and up on the wall too. Most of the question cards would immediately be put up with the associated module card.

2) We drastically cut back the core required modules for the three days and made everything else optional. We then decided on a simple in-class mechanism to choose from those optional modules. At the end of the first day, we had time for one optional module so the class voted and we chose the module based on that vote. Likewise at the end of the second day. By the third day, we had a substantial portion of the day un-allocated. As soon as we finished with the required materials, we got the class to choose the next module to cover. As soon as that module was covered, the class chose again from all those still remaining.

It was a bit of a mess and our mechanisms didn't work perfectly, but it got the job done. At the start of our second day, the cards we were using to track modules and questions looked like this:

After we finished the course, we did an in-depth reflection and decided on some changes to be made. One of the most important was actually very simple: make the module cards much larger so that it was possible to put many question cards right on the module card. Here is what this looked like in a recent class:

The left is the module card at the start of the course with questions that were generated by the course attendees when asked what they wanted to learn from the course. The right is the same module at the end of the course. You can see that one additional question card was added between the start of the course and the time when the module was actually covered. You can also see that I use big check marks to show to the class that the module is complete.

Another change to the method of doing this agile classroom management came in the further refinement of the module content and sizing to be more appropriate for doing the modules in unpredictable sequence. This included things like checking definitions, improving some of the introductory material (to make sure all the concepts were introduced, not just some of them), finding references to other modules and removing them, and in some cases moving material from one module to another. There are still improvements to be made in this area.

Thirdly, we now are better at explaining to the class how this will all work at the start. We are modeling an agile process in the way we run the course. This means that the attendees will have an opportunity to influence what material is covered and in what depth. It also means that if the class takes a lot of time with questions early on with the basic material, it leaves less time at the end for optional modules. The people in the class can now visibly see these tradeoffs.

Here are two photos from a recent class. The first was taken at the end of the first day (note that I forgot to use the check marks on these cards). The second was taken at the end of the third day. You can clearly see how the modules of the third day were chosen entirely by the participants from the available optional modules.

This mechanism of managing a classroom using an agile approach has had some very interesting results:

1) Every class is substantially different. Before, the differences were always in the details: timing, specific questions, etc. Now, the actual material covered is uncertain. I always make adjustments to the course materials after every course. Now, not only are those differences in play, but also the actual modules covered might be different. The fascinating thing is that now, by the time we get to the last module, most of the people in the class are giving off a palpable sense of satisfaction: their urgent questions have been answered. Sometimes, this is so strong that I do the graduation "ceremonies" right before covering the last module so that people not interested in that last module can leave a little early.

2) I get far fewer comments in my feedback forms that indicate a desire that the course was longer. Before I started using this agile learning environment, I would get a substantial number of comments to the effect that it was really too bad there was not another day. Now I rarely get those comments.

3) The attendees in the class see how an agile approach actually works in a real life situation. They see that allowing the requirements to change over time is actually a good thing. Every single time I do this, there is a pattern that shows up on the third day that relates to the way the class prioritizes the next module. I count up the votes and choose the next module to cover. All the other modules have their scores written on them as well. After a module is covered, instead of using those old scores, the class takes another vote. Every single class, the priority changes between votes. This clearly demonstrates the power of allowing stakeholders to change their minds after seeing real results.

4) Participants in the course are engaged at a deeper level. There are lots of "tricks" for keeping people engaged: discussions, exercises, simulations, questions, presentation eye candy, etc. All of those things have their place and are important. However, by having participants steer the course itself, the level of engagement suddenly becomes much more substantial. The participants are responsible for the results of the class in a way that is quite unusual in most educational environments. This responsibility is granted to them and they take it seriously. I rarely see anyone refuse to participate in this process, and I never see anyone attempt to subvert it.

---

If you are interested in learning this mechanism of classroom management, I strongly recommend:

1) Learn up on agile. The openagile.org web site is starting to define an agile method that is abstracted away from the software legacy that agile methods currently are shackled with. This site is still in its infancy so treat it gently :-)

2) Come try one of my courses! (Yes, that's a blatant shameless plug!) You will get to experience and learn the agile method in a focused setting. The courses are IT/software focused in some respects, but since they are non-technical courses, and really about agile project management and human interactions, almost anyone can attend (I've had dancers, administrative assistants, educators, artists, community workers, executives, and actors all attend).

3) Get in touch with me to find out more of the details that didn't make it into this blog entry. The best way to do this is (really) through my business web site: berteigconsulting.com where you can find both email and phone contact information.

---

Well, I finally got around to writing this up. This is part of a series of related articles "tagged" as USEFUL started by Scott who writes at Tyner Blain. His article, which started the game of tag, is called Software Product Success Stories. Scott... I'm sorry this article isn't about software!!!

I would like to now tag a few people who write useful blogs:

Mike Vizdos who writes the Implementing Scrum blog. This blog is best known for the fabulous cartoons of the Chicken and the Pig, but also has a lot of great and practical insight on the challenges of, you guessed it, implementing Scrum!

Tobias Mayer who writes at Agile Thinking. He doesn't write often, but his articles are always fantastic! I hope that Tobias will take the time to write something in this "useful" stream and pass along the tag.

Mark Levison writes Notes From a Tool User and discusses many things, not just agile. His writing is fun and he's in the trenches doing real serious work getting his company to use agile. He's got good insight.

Posted by Mishkin Berteig at 03:46 AM | |

August 22, 2007

Stuck? Try Extreme Obstacle Removal!

What happens when you are iterating away, your team is totally groking agile, delivering great results every couple of weeks, and then unexpectedly, suddenly and firmly everyone is stuck!? An obstacle has come along that forces a full stop. A barrier has been placed in the path. What do you do?

I know of a team that was in exactly this situation. They were building software on BEA's Weblogic platform. They discovered that a defect in the platform made any forward progress impossible (until the defect was remedied). So they canceled their iteration (good), tried to work in an open ended mode without iterations (really really really bad!) and then got absolutely nothing done for four months...

Encountering large obstacles like this puts a team in a nasty danger zone!!!!

Me, I like to consider the extremes:

1) Dump the vendor. This means building the component from scratch or replacing it with a component from another vendor or changing the whole platform. Although this sounds extreme, a self-organizing team should be aware that this is an option that might make the most sense given the circumstances. Keep iterating.

2) Make the vendor part of the team. Insist that they provide a dedicated, on-site person who is expert on the component you are using, insist that they provide you with source code. Both of these are so that you can cross-train in-house team members to solve this problem. Keep iterating.

3) Cancel the entire effort until the vendor (or some other entity) resolves the problem. Get the team to stay together but work on something else in the corporate portfolio that is valuable enough to justify the cost of the team. Let them work in short iterations so that there is little delay from the time the component is fixed until the team finishes an iteration on the other project. Keep iterating.

In my opinion, if you can't do one of the above three options, it is because your project is not valuable enough and no one is willing to admit it. (Actually, there might be other reasons too, but this is the one I would really be worried about.) Don't forget the Art of Obstacle Removal!

That said, there are of course half measures... just make sure you KEEP ITERATING!!! Whatever your current iteration length, find a way to deliver potentially shippable software at the end of every iteration.

Posted by Mishkin Berteig at 12:40 PM | |

August 09, 2007

A Cautionary Tale - Delaying Agile Adoption

What happens when you delay adopting agile? Well, one large client I have worked with has found out...

Because this story is a story of failure, and because most people don't like to have their failure's exposed, I have anonymized this story and changed some details to protect the innocent (and they are innocent! Failure is a learning opportunity, not something that's bad).

I started working with BigCom about two years ago. They got a whole bunch of training from me; in total about 60 people received some in-depth training in agile methods. They also decided, wisely, to get me to help coach them organizationally and for some of their Process Facilitators. What they didn't do is heed some good advice: start iterating.

They decided that they needed to do some important up-front architectural research on their huge product re-write/porting project. They had an existing product used by many clients and built over the course of several years. This product was implemented in a legacy programming language and in order to make it easy to add features and keep it up to date, BigCom decided to re-write it in a more modern programming language... but they couldn't decide which one: Java or .NET. Because it was a pure porting job with little if any functional change, they already had a good detailed knowledge of the functional requirements. But this one question of the platform to build upon stalled them. Their research committee studied this questions (and some other less important ones) for four months.

I had advised my client that they should feel free to go ahead and do the research, but that they would be well served by starting to iterate and build the new version of the product, even if it meant building it on two platforms simultaneously. The actual experience of trying to implement real functionality in both Java and .NET might seem like a waste, but actually would provide valuable information for the research effort and help speed the decision-making.

Perhaps my advice was too scary. Or perhaps there was some legitimate reason for many capable people to sit idle for four months while the committee researched, deliberated and failed to make this important decision. In any case, product management and dev management finally got tired of waiting, and they started up the work.

Of course, without the decision made, the work initially was a real mess: developers were left to choose when to use Java and when to use .NET. Sometimes functionality was duplicated in both languages. Sometimes it made connecting functionality extremely difficult. It wasn't systematic. But it was experimental, and it did help clarify the issues quite quickly. After only four weeks of doing actual work on the functionality of the product, it became clear how to use these platforms (for the curious: Java on the UI and .NET on the back end).

The research committee had very little to do with the final decision other than to rubber-stamp it.

Time passed. BigCom continued the development work, features were implemented, and eventually the deadline for releasing the product loomed. And then it passed. Six weeks after the deadline, the product was finally released. Nine months after the start of iterations. Thirteen months after I recommended that they "just start".

Four months wasted... and a deadline missed by six weeks. Was it worth it? Might have been nice to distribute some bonuses for coming in ten weeks early instead. Oh well!

Please, just start iterating!

Posted by Mishkin Berteig at 09:55 AM | |

March 02, 2007

Travel and Trust

I don't usually talk too much about personal stories here - I try focus on agile methods pretty directly. However, the last two days have been interesting enough that I want to share them, and a lesson from the experience.

About six weeks ago, I started making arrangements to do an in-house ScrumMaster Certification course for a good client of mine. These types of courses are always interesting because it is possible to go into the details relating to a specific organization. As well, because I have worked with these people before, I knew that they would have great, challenging questions.

I was supposed to depart yesterday on a short flight to get to their location. The weather forecast included a substantial snow storm for the day. I decided to make a change to my booking to go on an earlier flight in the hopes that I would get out before the storm. Unfortunately, about 30 minutes before I was to get into a taxi, the airline called to say that the flight was canceled and that I was re-booked on a flight for this morning. Since my course was to start this morning quite early, this was a bit of a problem.

I called my airline and found an alternative flight that would leave late in the afternoon (yesterday), get to an airport about 90 minutes drive from my client, and which was not canceled or delayed. I hopped in a taxi, got to the airport, checked in, went through customs (Canada to the US), went through security, hung out in the frequent flyer lounge, took the shuttle to the terminal, waited about five minutes and then found out that this flight, and all others for the rest of the day were canceled. (I then had to find my way back home which was extremely difficult with all the cancellations; getting a taxi was a two hour wait, so I decided to take public transit. The cost of getting to the airport was 40 minutes and 80 dollars. The cost of getting home was 240 minutes and 3 dollars!)

I called my client to let them know that I would have to arrive in the morning on the original re-booked flight. If I was lucky, I would end up at my client's site around 9:30am and be able to get the class started before 10am.

My flight this morning was scheduled to depart at 6:20am. Since I am a fair distance from the airport, this meant leaving my house at 4:20am and waking up at 3:55am (shower, brush teeth, dress, check email); thankfully, I didn't have to unpack/repack.

Before I left, I checked to see if the flight was still a "go" and it looked okay. I got to the airport to do my check-in. The automated check-in terminal told me to see an airline agent. Oh oh! I waited in line for 30 minutes only to find out that again my flight was canceled. The ticket agent was happy to try help out, but because of the weather (freezing rain), most other flights were also canceled and the earliest I might be able to get to my destination was about 3:30pm... if flights resumed in the afternoon. Definitely a problem!

I didn't put up a big fuss - no point really. So I made my way back home.

The end result: I called my client on the phone, explained the situation. He was quite understanding and we are going to re-schedule hopefully for later this month.

The lesson? He didn't have to be nice. He could have said something to the effect of "we had an agreement and you didn't deliver... it's all off, I'll find another vendor." And the fact is, he may still do that if we can't find a suitable date... but he's giving me the chance and that is important for both of us.

It builds trust, it is collaborative rather than contractual. And it's great that two people in two organizations who are doing agile are willing to put the principles into practice even outside of software development.

Posted by Mishkin Berteig at 02:58 PM | |

February 05, 2007

Iteration 6 - Cleanup!

Well. Last iteration was great! I didn't document it, because it was trivial: I had one full day coaching engagement plus a two-day public course. And then the rest of the week I did nothing!!! What a joy! Anyway, now onto iteration 6 - cleaning up from the cancelled iteration and catching up from the vacation.

My plans this week are simple:

1. Training Follow-up: lots of admistrative details to take care of.
(7 Tasks)

2. Coaching Follow-up: some marketing and coaching things to help my client.
(3 Tasks)

3. Development Work for my Client
(6 Tasks)

4. Long-overdue Financial Stuff: getting papers in order, doing spreadsheets, etc.
(4 Tasks)

5. Reduce Email Inbox Backlog by 125 messages
(2 Tasks - this is an odd one which I'll talk about more in a moment)

6. Prepare Some Technical Training Materials
(1 Task - collect already existing materials into a single piece)

Reducing my email inbox is really about 125 tasks, but most of them will be very fast. From past experience, getting rid of 125 messages should take between 4 and 8 hours of concentrated work. We'll see!

I'm committing to 23 Tasks. This should be about right, although, (again!) it might be a bit of an over-commitment. The only reason that I think I might be okay here is that I am trying to include more of the stuff that I would be doing anyway but just not reporting on my Work Queue. The admin stuff in particular!

To be clear: the past few iterations I have learned about my capacity. This time, I am trying to be more visible. Usually, I do not put _everything_ on my Work Queue and in tasks. I leave out things that are small or that I am always doing. I'm going to try to become more honest about what I am doing, not just my capacity. We'll see how it goes!

Posted by Mishkin Berteig at 12:27 PM | |

January 27, 2007

The Freedom of Limited Capacity

Something that I would have thought impossible has happened. By understanding how incredibly limited my capacity to do work is, I am getting a greater and greater sense of freedom and contentment.

My "experiement" to run my business using Agile Work practices is starting to bear some fruit. The trouble is, that so far, that fruit is simple better knowledge of my extremely limited capacity to get things done during a single week-long iteration. I can do 3 or 4 items from my Work Queue which works out to about 15 or 20 tasks. This seems ridiculous to me! Surely one hard-working guy can get more than that done!

But I can't. I'm getting to the end of my fourth iteration and it's the same thing again!

I know some of the reasons for this: interruptions, unexpected work, unremembered work, and my general nature of being easily distracted by shiny things!

In some ways this has been quite frustrating. I have a huge queue of work I want to get done for my business. But the other side of the coin, the one that looks different than I expected, is that knowing just how limited my capacity is... is liberating! I don't feel nearly as stressed as I did four weeks ago. I have the courage to commit at an appropriate level. I can start to believe my plans. I can see - realistically - just how much I need help to achieve my goals. I can see how soon I will be able to do cost/benefit analysis on hiring vs. doing the work myself (can't do that yet). I can even start to believe that I might be able to reach my original goal of reducing my working hours from 80+/week to 50 or less... as long as I make sure that my Work Queue is properly prioritized with that goal in mind.

---

I have worked with a number of teams that have gotten to this point of certainty about their capacity. I've seen this happen in others... and now I recognize it for what it is: relief. One team I worked with after only two iterations had a very clear idea of their capacity, and you could feel the comfort level of everyone with this new agile thing skyrocket. Another team I worked with got a clear sense of its capacity after only three iterations. This team settled in and then started to work to increase their capacity and did a fabulous job by using automation tools, eliminating various organizational bottlenecks, etc. They wow'ed the rest of the organization with their incredible, consistent delivery of value. One of my former students, Dmitri Zimine, gave a presentation at the XPToronto group where he talked about the incredible level of trust that developed between his team and the rest of the organization after consistently, iteration after iteration after iteration meeting their commitments.

All of this is only possible by a rigorous application of timeboxing, careful and consistent task breakdown, and good, honest tracking of results. I wrote a previous article called Seventeen Tips for Iteration Planning. Look it over and see what new ideas you can apply in your situation. If you are frustrated by a team continually over-committing, you will find a lot of valuable advice there.

---

As a parting shot: consider how you feel right now. Are you stressed out? Over committed? Failing to meet your commitments? Feeling guilty? Working insane hours? Not spending enough time with your family? Killing yourself!?

What about the team or organization you work in? Is it constantly being bombarded by problems it can't handle? Surviving on pure heroics?

I can't tell you that following a careful iterative planning approach will fix your problems... but I can tell you that it will reduce your stress levels, help you (or your organization) make appropriate commitments, and let you see the reality of your situation (good or bad).

Posted by Mishkin Berteig at 03:07 AM | |

January 23, 2007

Iteration 4: Restart

My third iteration was a big bust. I have re-planned, but there is very little different from my iteration 3 plan. I have chosen the same 4 items from my Work Queue. I have updated the tasks slightly based on experience from the last iteration so that I have 22 tasks. Even with more tasks, I have actually reduced scope slightly so that the tasks are finer-grained.

It was difficult getting around to doing this. I "wanted" to slide back into old habits of just doing whatever I felt like. I found myself spending way too much time doing email stuff.

Re-committing to the same plan (with minor changes) as the last iteration is difficult because I'm feeling slightly demoralized. Still, I think that it has a good chance of succeeding because I actually don't have any major commitments this week other than work.

Wish me luck!

Posted by Mishkin Berteig at 03:33 PM | |

January 22, 2007

Cancelled Iteration

Last week went totally wonko for Berteig Consulting. My planning was bad, bad, bad!

For planning, I totally forgot about three very important scheduling things:

- a ScrumMaster certification course on Thursday and Friday which required not just time in class, but also three hours of commuting each day.

- my birthday for which I had planned a very informal party on Saturday (normally a very productive work day) which consumed the whole day from morning to late at night.

- the departure of my brother Alexei and his wife Ma Jin so that Sunday would be my last day of visiting, again, taking up my whole day from morning to late at night.

Suffice it to say, a 3-day work week was not what I was expecting when I did my planning. Sometime on Thursday I gave up.

I decided to delay starting a new iteration until I could recover a bit. Over the course of four days I get nearly 200 emails that I actually need to pay attention to at some level or another. So, today has been a recovery day and at the end of the day I will plan my next iteration. Since I did not have a delivery meeting (since I cancelled the iteration), I can only do an informal review of the accomplishments:

- some progress on development work for my client
- some progress on invoicing my client
- some progress on automation of my course listings (Selenium is great!)
- no progress on providing a statement to my other client

The causes of this massive failure are obvious. It should be noted that by doing the ScrumMaster training, I did actually deliver value to Berteig Consulting... it just wasn't the value that I had planned!

Posted by Mishkin Berteig at 05:58 PM | |

January 17, 2007

Arg! Bitten!

Two things I realized that have almost certainly thrown off my ability to complete all the work I committed to for this iteration:

1. I'm doing a course on Thursday and Friday that I completely forgot about thus lowering my capacity by at least 28%!
2. I discovered that my "Save a Spot" feature on my agile course signup page was broken.

There are consequences to these things! Read on for a little treat...

First of all, I seriously doubt that I will complete everything I committed to in this iteration. That's not the end of the world, but it could be better. I have made some really good progress on lots of them so there is still a slim chance I will make it. One really good piece of news there is that I found out that Selenium can be used to automate remote web sites. This of course means that it should be a fairly simple matter for me to whip up a Java thick client app to submit new courses to my listing sites of interest. "Whip up" being the big spot with a question mark as to level of effort. I haven't done Java GUI development for quite a long time!

The second problem had dual consequences. First, it ate up a bunch of my time figuring out what was wrong and fixing it. PHP is okay, but combine it with AJAX stuff and debugging becomes a real pain in the arse. Let's just say I used a lot of JavaScript alert() boxes! I don't do enough of this type of development to bother figuring out how to do better debugging.... or (shudder) test-driven development. I know there are XUnit frameworks out there for JavaScript, HTML, HTTP and PHP, and the aforementioned Selenium is a great functional testing tool, but learning at least 3 or 4 XUnit frameworks for this really simple stuff I'm doing, just doesn't seem worth it. On the other hand, given that my "Save a Spot" feature has been unavailable for at least 3 weeks, it could have cost me literally many thousands of dollars !!!

Which leads nicely to my friendly offer to you, my loyal (and new) readers:

I was running a discount for readers of Agile Advice to sign up for my courses. Since my signup system wasn't working, I've decided to extend the discount until the end of January. The discount is 10%. Get it while it's hot! Even if you weren't aware of the previous discount or the fact that my signup system had failed, you can still take advantage of this great deal.

Here's the link again: Agile and Scrum Training and Certification - courses delivered by yours truly!

Posted by Mishkin Berteig at 05:47 AM | |

January 16, 2007

The Wisdom of Teams - Generalizing Specialists

I've almost finished reading The Wisdom of Teams: Creating the High-Performance Organization. I wanted to share a couple of paragraphs that give a great example of the idea of Generalizing Specialists that is such a key part of Agile Work. Here's the passage:

The [Connectors Team] made several decisions that solidified its common team approach and sense of mutual accountability. First, it set some rules. Everyone on the team had to identify two others who could serve as backups during vacation and sick days. To eradicate the attitude of "it's not my job" from the team, it was agreed that whenever anyone needed help, the person asked had to respond even if the activity was not in his or her area of expertise. And the team also agreed on a peer appraisal system that gave everyone the opportunity to evaluate everyone else and, through [their team leader], feed it back to the person being evaluated. Clear-cut rules of behavior like these are an important element of all successful teams.

Second, the team eliminated the two managerial positions that had retarded empowerment. This effectively modified the membership of the team because only one of the two managers whose jobs were eliminated chose to stay. The other believed he could not take a perceived demotion and left. By January 1991, however, the Connectors Team was a dramatically more effective group of people than it had been at its formation a year earlier.

Energy and enthusiasm reached higher levels as the team started pushing itself harder and in more innovative ways. One of the engineers, for example, decided to become completely qualified as a purchaser as well. Instead of being threatened, the purchasers on the team worked hard to teach her the basics of the job. The peer review approach worked so well that the team agreed on the additional - and, for many teams, difficult - step of directly providing each other feedback instead of relyinng on the team leader for this task.

There are several great points in the above story:

Backups: many agile methods do not explicity talk about this, but there is a need to make sure that the Truck Factor increases. A low truck factor can be a real problem and I strongly recommend that the Queue Master (Product Owner, Customer) in particular needs to have backup. As well, this hints at the idea that eventually the roles of Process Facilitator and Queue Master should eventually go away to be taken on by the team as a whole.

Skills: the example of the engineer learning to be a purchaser is a great example of a brave soul really taking to heart the idea of working for the good of the team by becoming a generalizing specialist. In my own coaching work, I have seen purely business-oriented Queue Masters become technical contributors to the team through a process of both deliberate and "accidental" learning. Every human being has an incredible capacity for learning. In a high-performance team, everyone takes that ability very seriously - to the point of it becoming a responsibility.

Rules: one of the simplest, yet most profound, ways that a group of people can start on the process to becoming a high-performance team is by working together to agree on some ground rules about team behavior. One team I worked with, among other rules, decided that no "stinky food" was allowed in the team room. The passage above notes the non-trivial rules. Both "trivial" and non-trivial rules are important to the team for two reasons:

1. Develop a set of expectations that individuals can hold each other to in order to avoid or deal with conflict.

2. Become aware of the team's power to set their own working conditions, independently of management or other "leadership".

Management: regrettably for most managers, in a high-performance team the value of formal, traditional management is much reduced. However, there is now an opportunity for two different types of work: the generalizing specialist work on the team, and the servant leader work of supporting the team. The servant leader is someone who is exceptionally good at problem solving, organizational change, and working through influence rather than authority.

---

This book is incredible. Every time I read a few pages I think "Oh! I've got to write about that on Agile Advice!" Unfortunately if I did that, I'd be in serious copyright violation. So all I can do is encourage you to read the book.

If you have already read the book, I would love to hear your impressions, particularly if there were things about it that you really didn't like. What didn't you like and why? What are the holes in it's argument?

Posted by Mishkin Berteig at 04:05 PM | |

January 15, 2007

End of Iteration 2 ("Capacity") and Start of Iteration 3 ("Automation")

This second iteration when much better than the first. I committed to an amount of work that was much closer to my real capacity, and I stayed more focused on that work. Here are the results of my demo, retrospective and planning for Iteration 3 which I am calling "Automation" for reasons which will be described below.

Demo

I committed to the following items from my Work Queue:

I also added these in the middle of the iteration (which is really a "no-no", but I did it anyway to my regret).

What did I actually get done? Here are the stats:

For Iteration 002 - "Capacity":
# Work Queue Items At Start: 5
# Work Queue Items Completed: 3
# Tasks at Start: 32
# Tasks Remaining: 17

What is scary is that my velocity is exactly the same in terms of number of tasks: I really need to start my iterations with only 15 tasks.

Anyway, what I need to do for my next iteration is schedule my "demo" with my other stakeholder (my wife Melanie). Demo'ing to myself in the wee hours of the morning is not really practical in terms of my overall goal for this project (running my business at a sustainable pace).

Retrospective

Here are the things that went well:

- Came much closer to getting everything done that was in my iteration. This was great - I continued to use Tiddly Wiki to track my Work Queue and Tasks.
- Felt less stress. Although I still worked very hard, I was not worried nearly as much about the things still on my Work Queue that weren't in this iteration. I also decided on certain boundaries to work: generally work 4 to 6 hours during the day and another few hours after lights out (usually after 11pm).
- The prioritization worked well - didn't feel impelled to do too much that was _not_ in the iteration. Althought I did take a couple more items in, it was more because of opportunity than anything else. My brother Alexei wanted to help me with my book (for example). Next time around, perhaps I should be more explicit about negotiating with myself about taking something out of the iteration if I bring something in.

Here are the things that need improvment:

- Get even better at judging capacity and committing to an appropriate amount of work. The numbers speak loudly! This next iteration I have to limit myself to 3 items from the Work Queue and about 15 tasks. I have to remind myself that I can always bring more work in if I complete my work early and I still have time.
- Care with long term scheduling - made a mistake in my scheduling with a Client - hopefully it will be okay! This is a bit of a nit, but I need to keep my daybook up-to-date even with long-term stuff.
- Spending time with my family - e.g. playing with kids, helping around house, assisting with homeschooling. This was better than I was doing in Dec., but I need to continue to improve here. I would really like to work with Justice and Haifa on learning Chinese. We've got tons of materials to do it, just need the discipline to get through it together.

Planning

Okay, maybe I'm a glutton for punishment, but I've decided on four items from my Work Queue:

Client2 Invoice
Client2 Work
Automate Listing of Scheduled Courses on 3 Sites
Client3 Statement of Account

The key one is the automation since that will be an investment to save me time later on. In my task breakdown it looks like this (tasks with an "x" are already done from the previous iteration):

So, that's 4 items from the Work Queue and 17 tasks (the ones with "--" in front of them are sub-tasks... not sure how to handle those, but for now I'm not counting them separately.

I'm really excited about this. It sucks to see that I get so little done in a single week, but on the other hand, knowing my capacity allows me to understand just how much work I have on my plate and how badly I need two things: automation and assistance! I'm going to start with automation, but I'm also looking for assistance. The trouble is that I can't affort to hire someone on a salary... (if you know anyone who would be interested in working on commission/revenue-sharing basis, I would love to talk!).

---

One final note: I did manage to include my wife Melanie in my planning for this iteration. She seemed pleased :-)

Posted by Mishkin Berteig at 03:09 PM | |

January 08, 2007

Planning Iteration 0002 "Capacity"

I've completed my iteration planning for my second iteration. As a reminder, I'm doing this because I want to be working only 50 hours per week by July 2007. My sole improvement item from last iteration was to use get better at committing to an amount of work within my capacity. Here's what I have planned:

I have included my complete list of work to be done broken down into tasks. It is anonymized:

Client1 Proposal Writing
- 1 day intermediate team course
- phone consult details
- QA/tools coaching
- email proposal
Client2 Invoice
- get template from them
- collect hours
- collect receipts
- image receipts
- currency convert receipts if needed
- type up hours
- type up receipts
- email/submit
Client2 work
- 4 hour task
- 4 hour task
- 4 hour task
- 4 hour task
- 4 hour task
- 4 hour task
- 4 hour task
- 4 hour task
India Training
- ping Contact1 "V"
- ping Contact2 "N"
- ping Contact3 "M"
- ping Contact4 "S"
- ping Contact5 "V"
- air reservations
- prepare visa application
- submit visa application
- hotel reservations
Client3 Statement of Account
- equipment
- invoice 1
- invoice 2

As you can see, I have committed to only five items off the Work Queue for this iteration and they add up to thirty-two tasks. This is more than I indicated last night in my retrospective results. I'm nervous about this in two ways. One, I think that I am under-committing and that I'll get into huge trouble if I don't do more than this. Two, I think that I'm over-committing and that with my brother visiting, even doing this much smaller amount of work will be challenging. Still, I have tried to make both the items from the Work Queue and the tasks smaller than in my previous iteration. I guess I'll see in a week!

Posted by Mishkin Berteig at 11:01 AM | |

First Interation Ending

My first iteration using Agile Work for my business development has come to a close. Here is what I did for a "demo" and retrospective.

Demo

This was simple. I looked at my selected Work Queue items and my tasks and check to see what I had accomplished (finished or partially finished). Here are the statistics (grim and discouraging as they are):

For Iteration 001 - "Beginnings":
# Work Queue Items At Start: 11
# Work Queue Items Completed: 2
# Tasks at Start: 43
# Tasks Remaining: 28

From these numbers, for my next iteration I should probably be hesitant about committing to any more than 2 items from the Work Queue and any more than 15 tasks.

Considering how many work hours I have in a week, 43 tasks is absolutely ridiculous... unless they are really small, which many of them weren't. For example, I had one task as "Integrate part one of Alexei's feedback into my eBook" which when I did it actually took about three hours. Its just one sample, but 3 x 43 is 129 hours and is just not possible for a single human being in 7 days.

Aside from the value-oriented items from the Work Queue, I also did the work to finish a more complete Work Queue. It now has 37 items including those which remain un-finished from this first iteration. It is poorly prioritized, but that will improve over time. As well, I suspect there are quite a few things missing that I forgetting. I should probably get my wife, Melanie, to look over it and make some suggestions. I also have some old "to do" lists for my business which might remind me of some things to add onto it near the bottom.

Retrospective

I did a little mini-retrospective to find the three things that went well this iteration, and the three things that need improvement. I also decided on a clear action item to take to try to improve my next iteration. (Another clear reason to use Card Meeting - worked great for my retrospective :-) .)

Three Things that Went Well:
- Referred to my iteration tasks frequently. I kept my TiddlyWiki up in my browser and checked it several times a day.
- Spent time with my family and friends despite huge workload. We had guests and family visiting and I got some good time in with them. I also spent a good amount of time with Melanie and my kids. I had to make a conscious effort to do this, but since this is the goal of my using Agile Work (to have a good life/work balance), I figured I might as well start making some progress on it right away!
- Had courage to do some development work which required changes to other developers' work. I ran into a problem with some of the work I am doing as a contract. I dug around and realized that any fix I made would be felt by other parts of the codebase as API's changed. I made the fix and then tracked down the dependencies and fixed everything up. Fun!

Three Things that Need Improvement:
- Pay more attention to my schedule / calendar so as to reduce problems with work/family boundaries. Still a loooooong way to go on this one!
- Spend more work time "on-task", rather than on things not on my list. I ended up doing a bunch of work stuff that wasn't in my iteration plan. Partly I did it because I got bored of what I had planned, and partly becuase I forgot to focus on my plans. It would probably help if I had a Process Facilitator breathing down my neck :-)
- Make realistic plans given my capacity for work. This is the biggie! It is going to be very hard for me to keep to a small commitment. But considering the my brother is visiting from Beijing with his wife this week and next, I really have to try to get this right.

It is that last point that I will use as the basis for my next improvement. For my next iteration planning meeting (to be held in the morning after a far-to-brief sleep), I will commit to a maximum of 3 items from the Work Queue. This may mean breaking the items down into smaller bits. I'll talk with the Queue Master (myself) tomorrow morning about it :-)

Posted by Mishkin Berteig at 04:37 AM | |

January 03, 2007

My First Challenge

Wednesday is nearly done and I'm looking at my list of tasks and cringing! I've only done a few out of the forty for this week. What's going on?!

Well, for one thing, I'm over-committed, and I know it. This is why my goal is to eventually time-box my effort to 50 hours per week. As it is, I expect I'll have a few more short nights this week in order to get even a reasonable amount of my commitment done.

Also, I've been cherry-picking. I'm doing the easy/nice/comfortable tasks first. I'm avoiding the paperwork tasks. I'm avoiding the administrative tasks. These are the ones that I hate and I always procrastinate about. (Hmm... writing this is actually procrastination too... just a few more words and then I'll get back to work.)

Finally, I've got some obstacles which I'm not sure I will overcome this iteration. First of all, I'm spending less time on work than I anticipated. Secondly, I'm getting distracted by tasks that are not directly related to my work items, but which seem to be pre-conditions. For example, I need to do a bunch of administrative follow-up for recent courses I have delivered. Part of that is to send of images of the attendees license forms. I've got the images on the SD card in my digital camera. I've also got a lot of other images on there. So, instead of focusing purely on the task at hand, I am actually cleaning up the whole card. Which is getting rid of technical/administrative debt, but it is slowing me down. Hmm... "administrative debt"... that's gotta be a common theme for the procrastinator!

Anyone out there want to write an article for Agile Advice about administrative debt?

Posted by Mishkin Berteig at 05:16 PM | |

January 02, 2007

Top Ten Most Popular Entries from 2006

If you are new to Agile Advice, these are not just some of the most popular articles, they are also some of the best! Take a look around; you will find ideas to inspire you, challenge your thinking and maybe that one little thing that will make the difference in applying agile methods in your situation.

1. How Two Hours Can Waste Two Weeks - 25,617 unique views
This little hypothetical story by Dmitri Zimine was very popular on Reddit, and Joel on Software ranted a bit about it.

2. The Case for Context Switching - 2,936 unique views
My rebuttal to Joel's rant. Goes well with Dmitri's article. Emphasizes the idea of building trust in an organization.

3. The Qualities of an Ideal Test - 1,579 unique views
Six qualities that will help make your tests as valuable as can be. Similar to the ACID properties of databases or the INVEST properties of user stories.

4. The Pros and Cons of Short Iterations - 1,555 unique views
A few words that will help you decide how long to make your iteration length. This is an important decision, and most teams and organizations don't know the factors involved.

5. Five Signs of Trouble in an Iteration - 1,489 unique views
A good howto on using burndown charts to discover problems in an iteration.

6. Seventeen Tips for Iteration Planning - 1,427 unique views
A good list of hints and tips that can make the difference between struggling with iteration planning and having it go smoothly and effectively. This is a key part of the Agile Work process, so getting good at it is a high priority for any team new to Agile Work.

7. Change is Natural - "Embrace Change" - 1,397 unique views
A short riff on the universality of change. Also introduces the idea of the "horizon of predictability".

8. The Art of Obstacle Removal - 1,287 unique views
This is a good reference article on types of obstacles and methods for removing them... a critical practice for Process Facilitators.

9. The Seven Core Practices of Agile Work - 1,285 unique views
Agile Work is really quite simple. This is a concise list of the practices that make up this effective methodology.

10. Interview with Alistair Cockburn - Agile and House Renovations - 902 unique views
Applying agile methods to home and garden renovations! Learn a bit about how this luminary of the agile world has taken agile practices out of the software world and into the hardware world.

Posted by Mishkin Berteig at 06:32 PM | |

My First Iteration Planning

I've done my iteration planning for my first iteration called "Beginnings". The length of my iterations is one week (including weekends). Here is the list of backlog items that I have committed to (some detail removed):

Catch up on Scrum course follow-up work
Advertize future courses
Finish eBook 2nd Draft
- email request for feedback return
- go through feedback
- finish references
- finish diagrams
Invoice
Finalize India Trip
Interview (Tuesday)
Meet up with and co. (Sunday)
Continue development work for

I have broken all of these into tasks, but only put here the ones for finishing my eBook since the rest get into lots of private detail.

I'm currently using TiddlyWiki to track my Work Queue, my tasks and my recurring/scheduled duties. I create a new wikiword for each iteration and copy items from the Work Queue into that section. I also have a menu that has links to my daily, weekly and monthly tasks.

I'm not doing any estimation on either Work Queue items or tasks. This may become a problem, but for now I'm going to try doing the work without the estimation overhead.

I also spoke with my wife, Melanie who is my business partner about all this. She agrees that using Agile Work is a good step to take and looks forward to all the benefits of my being more organized :-)

Posted by Mishkin Berteig at 12:05 PM | |

November 15, 2006

The Case for Context Switching

Recently, Dimitri Zimine wrote an excellent little story about context switching. Joel Spolsky writes in "From the 'You Call this Agile' Department":

Dmitri is only looking at one side of the cost/benefit equation. He's laid out a very convincing argument why Sarah should not interrupt her carefully planned two week iteration, but he hasn't even mentioned arguments for the other side: the important sale that will be lost.

Okay... I'll bite.

Let's look at that argument from the perspective of the sales person first since that is where Joel's concern starts:

The Sales Guy Perspective

"I need the 'ezhibal' feature now! Big bucks coming soon if we can get it now."

Let's suppose that this urgent email has come in somewhere near the start of our two week iteration. The normal response to this in Scrum is to push back a little. The ScrumMaster says something to the effect of: "Look if you wait 7 days we can put this on the top of the list for our next iteration."

First reaction, and it's a normal one, is for Sales Guy to freak out. I've actually heard people saying things like "You're going to lose your job over this! I'm getting the VP involved and he's not going to like it" and then they stalk off to find the big dog to come and bark at us. Anyway, let's pretend that the Sales Guy is willing to be reasonable and not instantly escalate the "problem". So what he actually says is: "Look, this is super important, it'll probably only take a few minutes for us to talk about it and then we can figure out how long it will take to fix. Let's just do a quick phone call and yadda, yadda, yadda, blah dee blah..."

---

Enough of the Sales Guy perspective.

Nowadays, if I'm in this situation, I do a value assessement. I tell the team to keep working on their plan, nothing's changed yet, and I sit down with Sales Guy and the person who's sponsoring the current work and we start a discussion about the options of which there are really only two that work in Scrum:

1. Stay the Course
2. Cancel the Iteration

First, let's talk about how we decide which option to take. Then we'll talk about why.

Deciding on the option is easy. You look at the value of the work currently being done and compare it to the value of the work that Sales Guy needs. You take into account probabilities. If Sales Guy doesn't have a signed contract, then it's hard to day if there's going to be any real revenue from the 'ezhibal' feature. Still, you might be able to do an assessment of the probabilities based on your level of trust and history with the client, etc. You also need to take into account the time value of money. Does delaying the current work have consequences for another client or stakeholder? What is the cost of those consequences.

This is a relatively simple cost/benefit analysis and comparison. If you're not comfortable with money and numbers and spreadsheets, you better get comfortable!

---

Okay, so we have a way of comparing the two bits of work. Now let's look at the two "allowed" responses and a third "bad" response.

Stay the Course

Turns out that the potential benefit of the stuff Sales Guy wants is not quite as high as the potential benefit of the stuff that Suzie Stakeholder prioritized for the current iteration. Well, that's easy. Put the request from Sales Guy in our prioritized list of work and get to it when there is an appropriate level of benefit relative to the other work.

Cancel the Iteration

The stuff Sales Guy wants is super-valuable. So let's get the whole team to stop what they are doing and everyone supports this very valuble work. Stopping the whole team is appropriate because obvioulsy, the stuff they're working on isn't as valuable. Oh, and because we treat a team as a unit in Scrum. And because the team needs to commit to work, not individuals. This isn't so obvious... more later.

Peel Sarah off to do the 'ezhibal' Feature

This is what normally happens, and in a "normal" non-agile environment, it's probably okay. In a non-agile environment, Sarah hasn't made any commitments (she's been forced to agree to dates and scope, etc., but she hasn't made a commitment that she is empowered to live up to). So if she goes off and does this one little thing, it probably will be just business as usual. In an agile environment, the team has made a commitment and doing this work this way invalidates the team's commitment.

---

Why do we do it this way? The main reason is around trust and commitment. Yup, it's that soft icky stuff that we're so incredibly bad at that customers think that bugs are normal, that management shoves the kitchen sink into projects in the frustrated hope that they'll get something out of the IT team at the end of the project. Sound familiar to anyone?

Anyway. An iteration is a commitment. It is a firm and solid commitment. The team as a group of smart and honorable people is making a definite commitment to the rest of the organization to get a certain amount of work done in a fixed amount of time. In return, management is agreeing to give the team every support in reaching this commitment. When a team is new at this, they might get it wrong. But having done this with dozens of teams now, I know that after a few tries, the team gets the hang of it and commits to appropriate amounts of work, and management provides appropriate levels of support.

This commitment is essential for developing trust. And anything that comes in the way of the team meeting its commitment is considered "BAD". An obstacle to do away with.

This is interesting, because Joel's second example is about defects. And I strongly agree that defects are "BAD" and need to be dealt with at a very high level of priority. The reason is simple: they prevent a team from meeting its commitment.

---

One team I was coaching was constantly bombarded by these types of it'll-just-take-a-few-minutes-need-it-asap requests. They had many stakeholders and very very limited resources to service these requests. They had several small projects that were taking literally years to do because they couldn't get enough concentrated time on any one thing. This was considered normal and good in their environment.

The trouble is, no one had really looked at the overall consequences. Everyone was doing local optimization. For us geeks, we all know that local optimization is something to be avoided if possible. We climb a peak only to discover that we have to climb back down a ways to get up to the higher peak we now see is next to this one. We climb up that one only to discover yet another higher peak even further along thus requiring us to climb down and up again... When really what we should have done is stepped back a ways, looked at the lay of the land and said, "hey, that peak over there is the highest of them all, let's go climb that one."

Scrum helps us avoid local optimization by forcing all feature requests for a team to be prioritized in a list of work, and by allowing the team to complete small pieces of work so it actually gets _something_ done that you can learn from.

---

Joel said:

Agile is not supposed to be about swapping out one set of bureaucratic, rigid procedures for another equally rigid set of procedures that still doesn't take customer's needs into account.

True enough! But it also demonstrates a serious lack of understanding about what is being done in Dmitri's example! First of all, without being agile at all, it is possible to switch from 18 month projects to two week projects. Both can be bureaucratic as you please (well, actually, there's only so much bureaucracy you can cram into two weeks and still get something done). The shorter projects will allow you to be much more responsive to customer needs... by definition!

So what happens when you add in all the other things that agile really is about? Transparency. Truthfulness. Creativity. Learning. Meta-Learning. Prioritization. Self-Organizating Teams. Eliminating Waste.

Well, first of what you get is something that's damn hard to do right. It goes against almost everything we've been taught to do: the extreme of heroics of the extreme of careful planning and process.

Secondly, what you get is something that needs safety zones and meta-rules. Like mutual, freely-given, team-to-stakeholders commitment. Like assuming positive intent.

And thirdly, what you get is an environment where not only is the business getting what it needs more than it used to, but also, the team likes working with the business, and the business likes working with the team.

---

I admit that the point Joel is making isn't too different. Yes: look at the costs and the benefits. But agile isn't quite about instantaneous responsiveness. That's a red herring and I'm suprised that Joel threw it's stinky carcass into the discussion. Agile is also about balancing that responsiveness with the overall view of value for the team and the organization. The tool for doing that is the prioritized list of work, not the email message from Sales Guy to Sarah.

Posted by Mishkin Berteig at 04:13 AM | |

October 23, 2006

Agile Analysis - Just What is Value Anyway?

Just a quick anecdote: one client I have has decided to use Agile Work to develop the user stories as part of a large project they are embarking upon.

In this meta-project, their team is composed of analysts and some technical people (although not everyone who will be on the development team).

The items in their Work Queue are large functional areas that have been identified. Each functional area could be thought of as a mega-epic which needs to be developed into epics and user stories.

They are using short iterations (I think 2 weeks long) and working on refining their user stories until they can make an estimate on the development part of the project that they are comfortable with.

"Done" for this meta-project means that the user stories are small enough, follow the simple template, and have the INVEST qualities.

---

At first, I tried to convince this client to do much less work on getting ready and just start the development teams. However, they quite rightly pushed back. They are doing work for a client who has agreed to pay them do develop a good set of requirements and an estimate to go along with it. Both my client and their client are aware of the advantages of early delivery of working software (their ultimate goal), but both have agreed that early delivery of good user stories in a Work Queue is also needed.

Fascinating!

Posted by Mishkin Berteig at 07:55 AM | |

October 12, 2006

Financial Models - Another Form of Visibility

I recently had an eye-opening experience with one of my coaching clients. We were trying to find a way to reasonably have a single team work with several important stakeholders throughout an organization, each of whom had a different project for the team. Up to this point, the team has been time-slicing between these stakeholders. It is stressful work, constantly switching gears. The last time we were there, we started to look at the value the team was delivering to each group. This is where the surprise came.

I was hoping that by building a simple financial model for each stakeholder's project we might be able to find a way to build a proportional schedule for the various stakeholders. Each project would get some proportion of the team's time based on relative value. I was also hoping to eventually roll these values down to the level of individual items on the backlog. I didn't get that far.

What did happen? Well, we did a rough guestimate of the various values of the projects based on the team's understanding. There wasn't anything too surprising that came out of that. We used that now-prioritized list and spoke to the stakeholder (let's call him John) for the highest value project on the list. We sat down with John for about two hours to build a simple spreadsheet financial model.

His project was about adding automation to a fairly long manual process that was used to build stuff for paying clients. We started out by doing a value stream analysis. We wrote out all the steps in the process and it turned out to be about 20 steps. I'm going to keep the numbers simple but representational. Those twenty steps took, on average, 8 weeks to complete. There was very little wait time in the process. But there were lots of opportunities to turn manual operations into automated operations (mostly through the use of computer models rather than physical models).

We also looked at the value for each client request (say $25000) and the number of jobs finishing each month (about 20). This leads to the very nice big number of $500,000/month revenue for the current process.

For each step in the process, we also assigned a time cost in days. This was the average amount of time each step took. By doing this, we were able to assign a dollar value to time reductions in each step. My client had plenty of business and would easily be able to take on more jobs from its clients if only it could do the jobs faster. So by reducing the overall cycle time and completing 21 jobs each month, the company could gain another $25000/month in revenue.

We then looked at all the opportunities for automation in the process and came up with a new time cost for each step. When we did this (and we tried to be conservative), we discovered that we could reduce the cycle time to half.

Doing the math was easy, but it made a huge impact on me. This particular project would lead to a doubling of revenue from $500k/month to $1M/month. The ROI (not counting time value of money) was enough so that the six months of development time that would be needed to buld the automation would be paid for in less than a month!!!

When we looked at the other projects in the team's queue, we saw that none of them would come even close to one tenth the value of this one project.

This huge difference in value makes it clear that the organization has a responsibility to get this one project done asap and likely to the exclusion of any progress on the other projects. The team does have operational responsibilities as well that must be done to keep the business moving, but the priority of new project work was blindingly clear.

Posted by Mishkin Berteig at 11:35 AM | |

July 17, 2006

Personal Scrum - Another Story of Applying Agile to Personal Life

Early today, Pete Deemer (who presented at the May 2005 Scrum Gathering - notes from his presentation are about 3/4 of the way down the entry), posted his experiences of using the Scrum framework, with adaptations to manage his personal life. He has graciously consented to sharing his story here.

Pete Deemer wrote:

I wanted to share with you an experiment I've been running for the last several months, in hopes that it might spark some interesting conversation. It's the use of a modified version of Scrum for managing my life, and through trial and error it's become quite useful in helping me to do a better job accomplishing goals and filling my life with things that make me happy.

It started several months ago when I realized that my life bore some striking similarities to a dysfunctional software development project. Which is to say it was filled with a lot of unclear direction, goals that weren't being met, responsibilities and obligations going unfulfilled, and important "maintenance" that was being put off again and again – with a net result that "the product" (in other words, the experience of being me) was not all that it could be.

So I set about seeing how Scrum could be applied to improve matters. Here's what over several months I've found worked well for me.
Sprints last one week, and Sprint Planning takes place Sunday nights. I begin by making an estimate of the time I will have available to put toward my goals of the week – typically, this is about 10 hours (or about 1 hour per day during the week, and 2 hours each weekend day). My life backlog has at the top of it a recurring list of items that I consider "must-haves" every week – these are the things that I consider necessary for "the good life" for myself or those around me. I actually have them grouped according to the various personae that comprise "me" – husband, father, son, citizen, learner, body, and so forth. Organizing it this way helps me ensure I don't overlook an important part of who I am, as I think about what I wish to do in the week; it also allows me to aim for a balance among these different directions. So, for example, under "body", my standing backlog items might include "take vitamins on 5 mornings", "do yoga on 3 mornings", "get 8 hours of sleep on 4 nights", etc.

The criteria for an item to appear on the backlog is two-part. First, it must be important for "the good life" (now there's a topic that deserves its own posting if ever there was one). Second, it must be something that might not otherwise happen. So, for example, I don't need to put "brush teeth" or "go to the bathroom" on the list (or at least I haven't yet). I began with things that were chore-like (such as taking my vitamins), or which were enjoyable but required forethought and so I tended to miss them (like organizing an outing for my daughter and me). Over time, though, I found it useful to include anything that met the basic criteria above. For example, I love playing computer games; but I was finding that when life got busy, it would be one of the things that got squeezed out. Now it's an item on the backlog: Play an hour of computer games. It might seem a little odd to in a sense "make a date with oneself to do something that's akin to goofing off", but if it's goofing off that matters, it should be on the backlog.

Each of the recurring items on the backlog has a time estimate associated with it, and these become quite accurate over time, since they come up every week.

Once I've gone through the recurring backlog items, I move onto the non-recurring backlog items. These are either one-off things I need to do ("plan family vacation") or represent small progress against big goals ("complete 1 chapter of mandarin textbook"). I generally only have enough of my budgeted time remaining to commit to one or two of these items, but frankly, that's one or two more than I was committing to before.

Once I've made my commitment, I print up a sheet that lists the tasks and time remaining, and I post it in a very visible place in our house (kitchen wall). I'll sometimes talk through it with my wife for a few minutes, as a way of making the commitment even more visible and "real".

Then, just before bed each night, I'll do my equivalent of the standup meeting -- looking at the task list, marking tasks that have been completed, and mentally orienting myself to what I'd like to do tomorrow.

Then, when Sunday rolls around, there's usually a little scramble to complete some tasks, but Sunday morning is actually a great time to do this. My "Sprint Review" on Sunday evenings consists of looking over the tasks from the week, and giving myself a pat on the back for what I was able to accomplish, and if there are things I wasn't able to accomplish thinking about why. This leads into planning for the week ahead. In thinking about the week that's passed, I can adjust some of the goals for the week ahead. For example: if I've been feeling dragged out, I might adjust several of the items on the recurring portion of the backlog (increasing 8-hour nights of sleep from 3 to 4, and swimming from 2 days to 3); or if I have a busy work week ahead, I'll cut back my time budget, and make some calls about tradeoffs.

One of the things I've found is that for this approach to be successful, unbudgeted time must still be preserved. In other words, the time you allocate to personal scrum must be only a fraction of the free time you have available. Happiness depends in part on being able to decide on the spur of the moment to do nothing, or do something completely silly and unproductive, and do it without any guilt at all.

One of the areas where the approach falls flat is "non-standard" weeks – for example, going on vacation, or having guests visiting, or other situations where budgeting time in this way is undesirable or
difficult to do.

Overall, this approach has had a positive effect on my life, and the experience has been similar to that of teams I've worked with in adopting scrum: greater sense of clarity of direction, repeated satisfaction of accomplishment, greater confidence in setting personal goals, and a greater sense of contentment and peace around living up to one's responsibilities and opportunities.

I'd love to hear about others' experiences with other Scrum- or Agile-based life management techniques.

Posted by Mishkin Berteig at 07:26 PM | |

June 08, 2006

Interview with Alistair Cockburn - Agile and House Renovations

Alistair Cockburn is the author of several important books in the agile software development literature including Agile Software Development and Crystal Clear : A Human-Powered Methodology for Small Teams (Agile Software Development Series). I had heard that he had a story to tell about using agile methods and principles on a house renovation project. I contacted him by email and he agreed to an email interview.

AA: Could you please provide me with a 3 or 4 sentence blurb about yourself?

Alistair: Armed with a B.S. in Computer Engineering (note the "engineering" in the degree ;-) and M.S. in Computer Science, I spent 8 years designing high-speed, custom computer graphics hardware, largely at Evans & Sutherland, the next 8 years in IBM Research researching the way people specify and test communications protocols, and the next 15 years consulting around object technology software and methodologies, starting at the IBM Consulting Group in 1991.

I got my doctorate from the University of Oslo in 2003 on the basis of my interviews with projects in the early and mid 1990s. It was on "People and Methodologies in Software Development." I was really proud about getting the word "people" into a doctoral dissertation in the Informatics / Computer Science field.

These experiences led me to help write the Agile Manifesto in 2001 and the PM Declaration of Inter-Dependence in 2005. More about my personal side is exposed in my answers to the infamous "Proust Questionnaire" and on my website, Alistair.Cockburn.us.

AA: How did you apply agile methods to your home renovations?

Alistair: Many people argue about whether house construction it is or isn't like software development. I have been making extensions to my house for several years. You can imagine that I would like to make a house extension incrementally, using a venture-capital funding model, and in a close collaboration with both the architect and construction contractors, exactly following the agile model.

In our first conversation, the architect suggested creating a "master plan" of all the desired changes, then doing the work incrementally. I declined, because I was pretty sure that we would change too much for the initial plan to have meaning by the half-way point, and it would end up being a waste of my money. As it turned out, I was correct.

We ran each idea as a stand-alone project, but were careful to ask at each key moment, "If we were to extend in [some particular way] next year, how would that affect our decision now?" Surprisingly, we found no cases where the future choice affected the present decision.

Our first project was to put a basement under our house. (I have fun with this ... people tell me that it is normal practice to build the basement first; then I get to say that we agile folks like to sequence features in business-priority order, so who knows, the basement may get put in last!). Anyway, it turned out to be easier than expected, because our house is built on short stilts (to provide an insulating air cushion over the ground). This probably wouldn't have mattered, because the construction people are used to putting basements under existing houses under normal circumstances.
Rather than excavate the whole basement, we decided to excavate only 1/3 of the basement. This gave us the basement entrance we needed, and left open the question whether we would extend the excavation or build a side wing in the next project. We learned that there would be no cost savings for excavating more than we needed now, even if we chose to expand the basement later. The XP community calls this the YAGNI principle, for "You Aren't Gonna Need It". We excavated only what we needed. Three years later we still have no plans to extend the floor space, either above or below ground. YAGNI is holding.

The next part of the "agile" story was watching the architect and the contractor work out how to hold up the house while they excavated. The architect looked underneath the house and launched into a dissertation on the various choices. The contractor cut in with, "Why don't we just run a giant beam right down the center and hold the whole thing up while we excavate?" Note here the application of the 11th principle of the agile manifesto: "Simplicity - the art of maximizing the amount of work not done - is essential." The architect adopted the suggestion, and after that, the architect, the contractor and the construction crew had excellent conversations that merged their best ideas with. To this day they always trade construction ideas back and forth along with how those might change the design of the house itself.

The next thing is illustrative of the relationship between construction and software development. On the first day of construction, they knocked a hole in the concrete wall where they were going to excavate, peeked in, and discovered that the beams under that part of the house ran perpendicular to those where they had looked under the house. This ruined their plan for the support beams, and showed that once again, civil engineering is ahead of software engineering. I find that it usually takes software teams a week or two to invalidate plans. These people were able to do it within two hours!

As we progressed I quickly noticed that the contractor kept changing his "fixed-price" bid for the project as new information appeared. I finally suggested we drop the "fixed-price" facade, and just work to time and materials. His reply surprised me: "If you are willing to carry the extra risk, that will be fine with us." I said, "I don't see any extra risk. You'll just change the price whenever something changes any-way." He said, "That's true but most people don't recognize that." In exchange for my accepting the "extra risk," he lowered his profit margin from 13% to 10%. We each felt we had benefited from this change.

With the new contract in place, his crew was able to do any number of other small projects for us, such as changing the kitchen counters, adding closets, and fixing the fence around the yard. Neither these, nor the other usual surprises, twists and turns on the project worried either of us any more.

I noticed with some interest that he and his crew held a daily stand-up meeting each morning to set their day's work goals. In this short meeting, they checked that they knew what they were working on, and had the materials to get it done.

The project came to a successful conclusion, and we gave a small bonus to the contractor and the workers. Unbeknownst to me, our prompt payments made us "preferred customers," which proved useful for the next projects.

We then did a second project, to sculpt the yard, move in stone slabs and do some general landscaping. Although this was considered a "minor" project, the contractor was delighted to help. He sent digging and moving crews to help when we needed it, and even operated machinery when his key men were ill. This was part of us being preferred customers, a roll-forward benefit from the first project.

We're on a third project, to add a fancy porch to the side of the house. At this point, we are glad not to have done a "master plan," because what we have in mind for the changes to the front porch are completely different from anything we had originally had in mind.

By now, there is trust and good communications between the architect, the contractor and us. The small wins with reflection, the venture capital funding model, the willingness to dance with the situation, are all paying off. The contractor passed along our preferred customer rating to his suppliers, so we got extremely fast service. He also took it upon himself to see that they give us good rates, so we saved money. Since we contracted by time and materials, it is natural to have the subcontractors do additional projects around the house as we need. The final bill for all this extra work has been much lower than it would have been had we contracted each one separately.

The point of this long story is to illustrate how the lessons from agile software development transfer to a completely different field. Incremental development, architectural changes, daily standups, YAGNI, time-and-material contracts, venture capital funding, customer involvement and steering, small wins, process miniature, and developing collaboration and trust - each of these proved useful.
(The above story is an extract from the forthcoming 2nd edition of "Agile Software Development", celebrating the 5th anniversary of the writing of the Agile Manifesto.)

AA: You have a great deal of experience using agile methods in a software context. How did you get the idea to apply agile methods to your renovation project?

Alistair: It is more the other way around: After interviewing successful projects for over a decade and seeing how incremental development and close collaboration make such a difference in project outcome, it would be hard for me NOT to apply agile methods to any project at all. I even tried it with conference organization (the Agile Development Conference in 2003 and 2004) – agile techniques didn't help us much on the first year (a conference is a one-pass, big-bang integration project if there ever was one), but they helped a great deal the second year.

Also, since we were spending our own money, the venture-capital funding model made sense.

The rest I just made up along the way, kind of as an experiment to see if it would work. I was surprised at the way YAGNI held up and pleasantly surprised by the really positive roll-forward of the close collaboration, communication, community, morale issues.

AA: Your family were also stakeholders in this project. How did they react to the lack of long-term planning, the lack of a master plan for the renovations?

Alistair: My wife has a harder time than I do with the notion of "build a little and then let's live in it and see what we need next" Her difficulty is not with completing one project at a time, as we did in the house, but in the garden, where I want to make steps and paths out of plywood and dirt and "feel how we use them" before committing to a design.

On the other hand, she is at least as good as me at taking last-instant advantage of serendipitous information. For example, we had an excavator ready to flatten a section of the yard, and he asked where he should put the dirt. I suddenly had the bright idea of building a mound in the yard. She saw it immediately, and in the next 30 seconds the two of us sketched out a first-cut redesign of that section of the yard based on the presence of a mound, sufficient for the bobcat operator to start moving dirt. (She then went and made a sculpture of the yard out of play-doh to serve as his spec!)

AA: Many agile methods include the concept of a timebox for planning and delivery which is used to provide formal feedback and adjustment points with stakeholders. How did you accomplish this feedback on your renovation project?

Alistair: Timeboxing didn't work for us, because we were subject to the really varying hours of the contractors – lots accomplished one week, nothing the next. We're small fish and they have bigger contracts to fulfill. So we had to / have to sometimes make do with leftover scraps of time.

However, we have an "on-site customer," so we have no trouble giving feedback. And since Deanna and I are willing to make adjustments in design really quickly, we can change direction in minutes. There were several times when they ran into some sort of obstacle, and we ran around for minutes or days (if the architect wasn't on-site at the time) drawing different drawings, checking prices and materials and designs, and then changing directions.

They had ordered tan planks of the Trex material for the porch, and it was sitting on the ground ready to be nailed in place. Neither Deanna nor I really liked the color. I was online looking for aluminum railings, and ran across a Trex site that listed many more colors than they had told us were available. I printed out the sheets, ran downstairs and showed everyone, and we changed to a burgundy color that day. It delayed the schedule a whole day.
With respect to financing, we were paying time-and-materials, so we could stop or delay the work at any time. (We still haven't figured out how speed work up, of course!)

AA: What was the biggest challenge you had to overcome in adapting agile practices to this project and how did you overcome the challenge?

Alistair: None come to mind. We used agile practices from A to Z easily and profitably.

AA: What aspects of agile methods did you _not_ apply to this work? What thoughts do you have about applying these missing methods to future work of this sort?

Alistair: Test-first design doesn't apply, as far as I can tell. Timeboxing didn't apply, in our case. I can't think of anything else.

AA: What part did trust and truthfulness play in your renovation project?

Alistair: Lots, all described earlier in the project story. We're inviting the architect and the contractor to the open-house barbecue, because they are interesting people and we like them. We get preferred treatment from the contractor, who passes that on to his network of specialist contractors.

He sometimes has to warn his specialist contractors that we're unusually frank. We expect them to counter our ideas with their ideas, and vice versa. We ask for hourly prices up front (and if he thinks those prices are too high, he'll bargain the rates down for us) and tell them to expect changes in direction. He likes all this and helps the other contractors recognize we're not the usual buyers that they have to protect themselves from.

AA: How would you sum up the most important things you have learned from trying this?

Alistair: Collaboration, open communication, feedback. Work incrementally, so that the feedback within and from each increment can improve all of those on the next round.

Try to remain open-minded when adverse events drag you out of your good mood.

Keep looking for ways to improve collaboration, communication, feedback, then everyone's best ideas have the best chance of coming forward. With everyone kicking in their best ideas, you'll get the best ideas possible for the project.

---

David Anderson has a brief blog entry called Construction time Again that claims agile doesn't work with house construction.

James Shore has also weighed in about "That Damned Construction Analogy".

And I have to admit that even I have written extensively that The Construction Analogy is Broken.

Seems we're all wrong, but that's good as far as I'm concerned!

Posted by Mishkin Berteig at 11:56 PM | |

May 31, 2006

The Human Touch

If you are given a problem to solve, how much does the presentation of that problem matter to your ability to solve it? Imagine that it's a simple problem... imagine that it is presented in two different ways, both of them simple. It turns out that presentation differences can still make a huge difference. In fact, there is a way to present problems that makes them substantially easiers to solve: make them people problems.

In The Tipping Point: How Little Things Can Make a Big Difference, by Malcolm Gladwell, we are given a very concrete and suprising example of this. Here it is quoted in its entirety:

Consider the following brain teaser. Suppose I give you four cards labeled with the letters A and D and the numberals 3 and 6. The rule of the game is that a card with a vowel on it always has an even number on the other side. Which of the cards would you have to turn over to prove this rule to be true?

Go ahead and take a few moments to figure that out before continuing on to the answer, and keep track of how long you work on it...

The answer is two: the A card and the three card. The overwhelming majority of people given this test, though, don't get it right. They tend to answer just the A card, or the A and the six. It's a hard question. But now let me pose another question. Suppose four people are drinking in a bar. One is drinking Coke. One is sixteen. One is drinking beer and one is twenty-five. Given the rule that no one under twenty -one is allowed to drink beer, which of those people's IDs do we have to check to make sure the law is being observed?

How long does it take you to figure that out?

Now the answer is easy. In fact, I'm sure that almost everyone will get it right: the beer drinker and the sixteen-year-old. But, as the psychologist Leda Cosmides (who dreamt up this example) points out, it is exactly the same puzzle as the A, D, 3, and 6 puzzle. The difference is that it is framed in a way that makes it about people, instead of about numbers, and as human beings we are a lot more sophisticated about each other than we are about the abstract world.

Now unless you had heard about this before, I suspect you were pretty suprised. I know I was! I always considered myself to be a very good abstract thinker/problem solver. In fact, I considered myself to be well above average in that regard for a number of reasons: I was always very good at math without every memorizing a single formula (I always made them up as I went along as long as I remembered the _idea_ of the formula), I was an excellent programmer in a number of different computer languages including assembler, Miranda, Java, Prolog, Pascal, and Objective-C, and finally, I'm always solving problems by moving the problem to a new level of abstraction - solving the meta-problem first.

So what does all this have to do with agile work methods? Quite a few things actually:

1. Obviously, if you can frame a problem as a people problem, it will be easier to solve... and most problems start out this way!

We tend to try to abstract problems, make them more generic or general purpose in the hopes that they can be communicated more precisely and can be solved in a way that will accomodate contingencies we haven't thought of yet. But all the effort we put into abstracting the statement of the problem ends up costing us doubly: in the initial abstraction and in the difficulty of solution that results. So if you have a team that is solving a people problem, make sure to keep it a people problem when you give it to the team!

2. If you have a problem that is given to you in an abstract form, try to convert it to a people problem before trying to solve it.

In all likelihood, the moment you do the conversion, you will quickly see the solution. It may even feel like the process of de-abstraction is a problem-solving process. You may have to make really odd connections to make the problem a people problem but it will likely be worthwhile.

3. Dealing with people rather than abstractions on a day-to-day basis will always result in a more effective interaction.

Sending printed documents, writing emails, manipulating symbols are all interesting ways to communicate, but fundamentally, you are communicating with other people. If you can make that communication as direct as possible - phone, video conference, in-person - then there will be far less effort involved in understanding the communication, and far more effort can be allocated to high-bandwidth communication. This obviously has special relevence for teams: get people in the same room as much of the time as possible.

---

In the software world, there is one technique that I give teams and that is the use of Personas to assist in solving a software problem. The place I first encountered Personas is in the excellent book The Inmates Are Running the Asylum by Alan Cooper. This book presents some of the basics of the Interaction Design discipline.

The bare essense of the Persona is to create a fictional person who represents a user or actor or stakeholder or customer of whatever it is you are building. This fictional person should have a name and all conversation about the thing being built should be couched in the personal language of these Persona's names. A Persona should also have a short history, a photo and some description of their needs, goals or desires. All of this helps to frame everything about a software project as a people problem... and thus makes it much easier to discuss and solve.

Posted by Mishkin Berteig at 11:12 PM | |

March 22, 2006

Facilitating Groups to Self-Organize

Yesterday I co-facilitated a meeting with another Agile coach. Near the end of the meeting, one of the participants made a comment to the effect that I probably didn't imagine when I was growing up that I would be a meeting facilitator. Strangely enough, in a way I did!

I also had a phone conversation this morning with an individual who is interested in reviewing one of the courses that I facilitate. Part of our discussion reminded me of the story of how I got interested in this sort of stuff.

---

When I was a boy, I was very interested in science and technology. I read lots of books about biology, electricity, robots. I also had the pleasure of playing with discarded video equipment that my dad would bring home from work. By "playing" really I mean "breaking". I also disassembled adding machines, reel-to-reel tape players, stereos, etc. Aside from Lego though, I wasn't very good at re-assembling. Eventually I really got interested in math as well and then computers. The story of how I got interested in math is also the story of how I got interested in education.

One weekend, when I was in Grade 2, probably seven years old, I went on a trip with my dad to visit my grandpar

Posted by Mishkin Berteig at 12:18 PM | |

January 04, 2006

Scrum Saves the Day For Media Student

Scrum is one of the Agile Methods that can be applied in many different fields of work. Last year, I was able to present the basic Scrum framework in a two hour session to a class of media students at Keyano College in northern Alberta. They used Scrum for their class project - a documentary video. One of the students really took to Scrum, and used it in his next class to save another group project... and get the best mark in the class! Full story follows...

Note: names have been changed.

I just wanted to let you know how and why the scrum format was useful for me this year in New Media 1000.

The largest assignment (a whopping 40% of our mark) this semester was a "Reverse Storyboard", where we took screenshots from the film "Run Lola Run", reworked them following the same compositional guidelines, and then created a narrative from our reworked screenshots. This new narrative was fleshed out, storyboarded, scheduled, and shot.

I was a team leader for a group of 4 students (myself and 3 others), and initially our group was struggling to keep focused and on track. Our storyboard was late and miniscule, and our planning was substandard. The group (myself included) was blaming this misadventure on "schedule conflicts".

I decided to implement the scrum format (at least in part) to keep our group on the right course. Despite all of the students in the group having different schedules, a 10 minute meeting was manageable every day. Our group sat down, discussed, and planned out a week by week (and somtimes bi-weekly) shooting schedule with iterations as key goals to achieve every week.

According to the assignment [specifications], the film was to be broken down into six sequences, together totalling around five minutes in length. We created a separate Adobe Premiere (shudder... yuck...) file for each sequence, and each student was accountable for the bulk of the hands-on editing on at least one sequence, but the planning for each sequence was covered in the scrum meetings. The remaining sequences were picked up collectively; worked on by multiple group members at a time.

I was the ScrumMaster, and would email the group the "minutes" every day after class, adding questions at the end of the email to spawn group discussion about the work.

The scrum meetings helped us keep specific goals, (our iterations) in focus, and helped us organize ourselves into units for production, i.e - Joe and myself would shoot the scenes that only involved one of us, Joe, Lara, and myself would shoot the scenes that involved two of us, etc. This worked well for filming and for production, as Nancy, our fourth member was very restricted for time and could only film for about one hour a day, three days a week.

Nancy was an interesting group member. She was very biased and uncooperative, and had no faith in the power of editing, as she had never worked on a video before (none of the group members, save myself, had). I don't want to site specific instances, but consistantly throughout the filming and editing process, she seriously hindered the group, and was a constant source of agitation for us all. Despite this frustration, the scrum meetings served to diffuse many of the issues she caused, providing a forum for group discussion and enabling us to speak our minds without sounding too aggressive or seeming to individually attack her (often counterproductive and nonsensical) ideas.

We ended up getting the best mark out of the entire class, a 29.5 out of 30.

Without the scrum format I can only imagine what kind of chaos would have ensued. Thank you Garry and Mishkin for providing me with such a useful tool for group organization.

Take Care,
Jason.

Thanks Jason (named changed) for the great story! If you are interested in learning more about Scrum and how to apply it to unusual types of work, Berteig Consulting Inc. offers public training for individuals and in-house training for teams.

Posted by Mishkin Berteig at