Agile Advice

November 09, 2007

Agile Contracts

One of the Certified Scrum Trainers, Chris Sterling from SolutionsIQ, recently posted a good set of links on Agile Contracts. Hopefully these links will help you understand how to "sell", set up and execute on agile contracts. Here are the links:

Chris wrote:

Mary and Tom Poppendieck have great presentations and a workshop on this topic. Here is a URL to a Powerpoint presentation from them:

http://www.poppendieck.com/pdfs/AgileContracts.pdf

Also, here is some data from a workshop:

http://www.poppendieck.com/agilecontracts.htm

And Alistair Cockburn has a great page on Agile Contracts here:

http://alistair.cockburn.us/index.php/Agile_contracts

Martin Fowler has a page on “Scope Limbering” here:

http://martinfowler.com/bliki/ScopeLimbering.html

Hope these help.

Thanks Chris! Here are a couple more links:

Leading Answers - Agile Contracts - blog entry with some good references.

Contracting Agile Projects - by the Cutter Consortium

I'm not an expert on agile contracts myself. I would be interested in hearing from people if they have any stories about actually using (or failing to use) contracts in an agile environment.

Posted by Mishkin Berteig at 07:17 AM | |

October 23, 2007

Scrum Rules Cheat Sheet - Updated!

A few weeks ago, after my last update of the Scrum Rules Cheat Sheet, I decided that it might be a good idea to ask Ken Schwaber about what I had developed... He immediately asked if I had checked it against the rules listed in his book Agile Project Management with Scrum. Of course, I hadn't. In fact, although I've read the book, I neglected to read the appendix in which the rules are contained. So, I read it and updated the cheat sheet. I found that there were a few rules that I was "assuming" because I work with Scrum so frequently. As well, there were a few rules that I actually didn't remember. The cheat sheet is now getting to the point where I would like to break it into two pages, but then it wouldn't be a cheat sheet anymore... so with smaller font size... presenting, the new and improved Scrum Rules Cheat Sheet. Here is the original article about the Scrum Rules Cheat Sheet.

Posted by Mishkin Berteig at 08:19 AM | |

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 | |

September 06, 2007

Four Methods of Perfecting Agile

Most organizations start doing agile (or Scrum or lean or ...) imperfectly. Someone introduces a few practices or a manager gets a team some training, or a person starts using agile terminology. And things might improve, particularly with the use of iterations. One of the core ideas of agile methods is to have frequent delivery of valuable results. In fact, this core idea can be used to drive the improvement of an agile process. How? Here are four methods of perfecting agile by expanding the definition of done.

Perfecting Agile

Let's suppose you already understand the benefits of agile. With these benefits in mind, you would like to improve the organization's ability to deliver working, valuable results at the end of every iteration so that you can get better at realizing those benefits. The primary way to do this is by expanding the definition of done. You can imagine this like so:

On a regular basis, the team/organization find ways to bring work done in either the preparation stage or the close stage into every iteration of the agile portion of the project. By moving the work from these "bookend" stages into the iterations, you reduce the amount of time spent in those stages and simultaneously create a more complete delivery every iteration. The "definition of done" is now expanded to contain the results or value delivered by the work that was taken out of the startup and shutdown stages of the project. By expanding the definition of done, each iteration delivers a more "complete" increment of value, and there is less work done before or after iterations in order to plan or deliver. This gradual process allows the team to get better at doing agile.

---

There are four methods for transferring work from the start and end of a project into the iterations of a project.

Expand the Agile Team's Skill Set

In some ways, this is the simplest and most common approach to expanding the definition of done in the agile portion of a project. By training, coaching, mentoring, re-assigning or hiring, a team's capacity to do work is expanded and used to expand the definition of done. As a simple example, a software developer might learn to use an automated unit testing framework and therefore expand the definition of done to include some amount of unit test coverage of delivered code. In general, training, coaching and mentoring existing team members should be preferred over adding people to the team since the addition disrupts the team's development and can increase communication overhead among team members.

Expand the Agile Team's Authority

Sometimes, a team is not able to do part of the preparation work or close up work because they are not authorized to do so. This may be a policy, a unspoken assumption or a bureaucratic procedure. By giving the team (or some person on the team) the authority to do this work, the team can find ways to do it every iteration instead of having to work through another non-team individual. Again, a simple example here is a situation where a technical person is given permission to talk directly to an end user in order to reduce the need for up-front requirements gathering and analysis and reduce the need for end-of-project user acceptance testing. The obvious challenge to do this is the question of trust (or lack thereof).

Automate an Existing Manual Process

Automation is often given far less than its due consideration. This is primarily be cause automating a process is an investment of work in and of itself. Fortunately, it is often easy to measure the ROI or savings involved with automation. In many agile environments, heavy automation is critical and a huge enabler for very short iterations. Automated testing, automated translation, automated build processes, are all common areas of improvement. Agile teams should always be looking for opportunities to automate their own work. In this way, the automation work itself is transformed from a separate project to a responsibility of the team.

Remove Wasteful Processes

There are some parts of the project preparation work and the project close up work that are pure waste! There is no independent value to these activities, nor is there indirect value to them. An excellent example of this sort of thing is an approval process that _always_ grants approval ("rubber stamping"). One insurance organization I worked with as they were converting to an agile approach discovered that their "second stage" approvals always allowed proposed projects to proceed. Since they often incurred a 4-6 week delay for this approval process, it became obvious that they should "get rid of it". Now, what they actually did is made it so that it became a parallel review process rather than a gated approval process; this was so that the true purpose of the activity could still be met: to help stakeholders understand the projects that were being worked upon. Here, there is no need to take this approval process and somehow work it into every iteration. An agile approach tends to increase the visibility of the work anyway, so it may be discovered later on that the review process can also be done away with.

---

Agile is often implemented in a limited fashion when it is first adopted by most teams and organizations. The four methods of expanding the definition of done can help a team or organization get better at doing agile and therefore reap more of the benefits of agile. These methods are simple: expand the agile team's capacity, their authority, have them automate manual processes and remove wasteful activities from the process.

Posted by Mishkin Berteig at 03:32 AM | |

August 30, 2007

Agile Retrospectives and the Plan of Action

Bas Vodde has published a good article about making goal oriented action plans for agile projects. It is a nice piece of the puzzle on how to do effective retrospectives. It also nicely ties into the "Learning Circle" Reflection/Learning/Planning/Action steps.

Posted by Mishkin Berteig at 04:59 PM | |

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 01, 2007

Agile Estimation and Pairing

I just read a recent article on PMHut called "Schedule Questions: Pair Programming and the PNR Curve". There is much in this article that is important for agile project management... and much that should be avoided at all costs!

Estimating Projects

The bulk of the article is an explanation of the PNR curve (Putnam Norden Rayleigh curve). The explanation is sufficient and can be checked against other web articles about software estimation. The basic idea of the PNR curve is to find an ideal number of people with which to staff a project based on an estimate of overall project size (e.g. 72 man-months).

Take a moment to go read Fantasy Estimation (the comments here provide good additional material).

It should be clear now that any initial sizing estimate based on units such as man-months is ridiculous. So what is our alternative? What about an agile approach to estimation and planning?

Agile Estimation

Well, at a minimum, in an agile approach to estimation, we need to resolve some of the problems identified in "Fantasy Estimation". So, we:

1. Get the whole team that will be doing the work to do the estimation
2. We weight estimates based on team maturity, knowledge of tools, knowledge of the business domain and the physical proximity of team members to each other
3. We adjust our estimates of work remaining based on our results for work completed

The great thing about an agile approach is that it allows all these things to be done and to be done well. Scrum has a specific set of "Drag Factors" that can be used to weight the team's estimates. And using a team's past estimates vs. "actuals" is possible on an iteration by iteration basis... and this is possible because every iteration the team is doing the "same thing": delivering an increment of valuable results (working software, edited video, organizational change, whatever is contributing to the project goals).

The other thing that agile methods allow is to make a distinction between estimation for planning and estimation for commitment.

So. It's cool to learn about the PNR Staffing curve and the thinking behind it. It's a little scary to see it being applied in an agile context when we have tools that are much better.

Pairing and Estimation

At the end of the PMHut article, the author, Mike asks a question:

What about pair programming? When using pairs on a team we could either:

1. Continue as is, use the model to determine optimal team size and then encourage pairing to increase efficiency.
2. Treat a pair as one hyper-effective person, so count pairs not individuals and increase team sizes accordingly.

This second option seems counter intuitive to agile, we strive for small teams to reduce communication channels, so I’m not convinced by this idea. I would be very interested to hear people’s thoughts on agile staffing curves. So, lots more questions than answers in this post, please let me know if you have any research or thoughts on the matter.

I wrote in response:

Mike, I feel like the options you present in your question at the end actually miss the true point of pairing… which has to do with communication. I have never seen pairing done in such a way that two people always work together as a pair. Rather, pairing is promiscuous: people switch pairs frequently throughout a day, iteration or project. This switching has two communication effects: 1) the human interaction and gradual diffusion of information as people switch pairs 2) helping everyone understand all parts of the work as a result of frequently working on many different things. From an estimation standpoint, I expect that neither of your two options is quite right. Rather, the third option is to continue as is with existing estimation and then encourage pairing to increase communication. Increased communication shows up in a number of different ways, not just efficiency: risk mitigation, accelerated individual and team learning etc.

I would like to expand on this just a little. To me, pair programming or pair work of any kind has always been able to provide a number of benefits to projects. Problem avoidance is one benefit (lower defect rates, better code quality through constant inspection, spotting each other). Better communication is another benefit. Increasing the Truck Factor is yet another benefit.

None of these benefits have any direct bearing on estimating a project at the start, particularly since most projects sacrifice quality for schedule. From an agile perspective, since planning estimation is not commitment, it actually doesn't even really matter! Get a conservative estimate for you project using whatever method you like, then start working and get a commitment velocity and see what the team can really do.

Posted by Mishkin Berteig at 10:04 AM | |

July 23, 2007

Designing Truly Collaborative Spaces

While it may look like Agile teams all work in big empty “common rooms", the truth is that people need more than that. Elements like light, air, traffic flow, noise, refreshments and comfort are not negligible: high productivity teams still consist of people, not robots, and these hard working people can be enabled or discouraged by the spaces in which they work.

While it may look like Agile teams all work in “common rooms", the truth is that people need more than this. We forget that the classic XP teamroom layout was called “CAVES and commons” and it explicitly recommended that people have access to some personal space (caves), as well as the common space. After so many years of using professionally designed work spaces, teams sometimes “throw the baby out with the bathwater” when they start over from scratch with their own designs. Elements like light, air, traffic flow, noise, refreshments and comfort are not negligible: high productivity teams still consist of people, not robots, and these hard working people can be enabled or discouraged by the spaces in which they work.

Today I published an article on this topic, addressing a common issue with new teams: what should our collaborative space look like? The article gathers the wisdom of dozens of teams, as collected by experienced Agile coaches Joseph Little, Scott Ambler and Mishkin Berteig. The article suggests looking at the status quo for clues as to what a team needs, as well as imagining what tools their future collaborative process will use: projection, flip chart, continuous integration server, whiteboards, etc. The article looks at how much and what kind of space is needed, and reminds designers of facilities that teams need to have in or near their space.

You can read the entire article on InfoQ.com'a Agile community queue.

Posted by Deborah Hartmann at 10:23 AM | |

May 24, 2007

Scrum Rules

Recently in my ScrumMaster Certification courses, I have been ending the course with a list of the rules of Scrum. This list of rules is based on my understanding and practice and may not be 100% the same as that found in the Scrum books or in other Scrum practitioners' models. Nevertheless, I just recently checked it against some other online reference material and it seems like a reasonable list of rules. I am interested in any feedback or variations or disagreements...
[Updated: 20070922]

Without further ado, here they are, categorized into Required Rules, Basic Rules and Optional Rules, plus a downloadable PDF version.

Required Rules to Start – the “Agile Skeleton”:
- Full-Time ScrumMaster Identified and Team Members Available to Do Work
- Team Agrees to Demonstrate Working Software in No More Than 30 Days
- Stakeholders Invited to Demonstration

Basic Rules of Scrum to Implement As Soon As Possible:
- Full-Time Product Owner (with Expertise and Authority) Identified
- Product Owner Works With Team and All Other Stakeholders
- Product Backlog Created and Managed by Product Owner
- Daily Scrum Meeting with 3 Questions (Completed? Will Complete? Obstacles?)
- Daily Scrum Meeting Same Place and Time and Less Than 15 Minutes
- Regular Sprint Length (no more than 30 days)
- Sprint Planning Meeting to Create Sprint Backlog of Estimated Tasks
- Sprint Burndown Chart
- Team Room with All Needed Equipment and Supplies
- Retrospective Meeting for Process Improvements
- Definition of “Done”
- Commitment Velocity Calculated (from Sprint Backlog Estimates)
- Team Size 7 +/-2, Maximum of 12
- Cross-Functional Team Including ScrumMaster and Product Owner
- Team Self-Organization - Team Members Volunteer for Tasks
- ScrumMaster Tracking and Removing Obstacles
- Team Safety – No Interruptions to Team's Work During Sprints
- No “Break” Between Sprints
- Sustainable Pace - Timebox Effort, Not Just Schedule
- Quality is Not Negotiable - Defects Go on Top of Product Backlog

Optional Rules of Scrum to Implement Depending on Context:
- Test Driven Work and Continuous Integration
- User Stories as Product Backlog Items (As a I can so that )
- Project Burndown Chart
- Release Burndown Chart
- Planning Velocity Calculated (from Product Backlog Estimates)
- Scrum of Scrums for Multiple Teams
- Canceling the Sprint Early
- Financial Modeling for Product Backlog
- Sprint Backlog Tasks on Big Visible Chart on Wall
- Backup Product Owner Identified
- Team of Volunteers - Self-Selecting
- Rotate the ScrumMaster Duties

---

And here is the downloadable version of the Scrum Rules Cheat Sheet [pdf].

Finally, you can purchase a poster-sized version of this from Cafe Press AgileAdvice Shop for $22.99.

Posted by Mishkin Berteig at 03:01 AM | |

March 05, 2007

A Better Iteration Structure

In my coaching work, I have often been asked a question about the planning process for iterations, that until just a few days ago, I would actually brush off!!! I didn't even realize I was doing this, it is only in retrospect that I see this. This question is simple: "how does a team plan for the improvement efforts that come out of the retrospective when they are supposed to be working at maximum velocity when implementing tasks directly related to the items in the work queue?" Or, more simply, "we don't have time for process improvements."

The source of the problem shows up in the normal* structure of an iteration. This structure is as follows:

Step 1: set a goal by selecting work from the top of the work queue.
Step 2: plan the execution of that work by doing a task breakdown and task-level estimation.
Step 3: do the work according to the tasks (this is the bulk of the time in the iteration).
Step 4: do a demo to review the work - use this demo to adjust the work queue if necessary.
Step 5: do a retrospective to review the "how" and come up with action items to make the work more effective next iteration.

Since iterations follow one after another, this structure when rolled up can be re-written in the following manner:

Action (step 3)
Reflection, Learning (step 4)
Reflection, Learning, Planning (step 5)
Planning (step 1 and 2)

Now if we look at the purpose of the steps in comparison to the type of learning activity taking place, we see that there is a big disconnect between the planning that happens in step 5 (the retrospective) and the planning that happens in steps 1 and 2 at the start of the next iteration. Not only that, but reflection and learning are separated into "what" and "how" so are done twice for each iteration.

Frankly, this causes a lot of confusion: I see it in my coaching when teams try to accommodate the two types of planning, and I see it in my training when I teach the structure of the iteration.

---

So what is to be done? Simplify the structure of the iteration. Instead of thinking of the iteration as a linear block of time that starts with step 1 and ends with step 5, think of it as a cycle that is dominated by Action, and punctuated regularly by Reflection, Learning and Planning. Now, instead of four separate meetings, there is a single meeting every iteration that combines the wrap-up of the previous iteration with the start of the next. Let's call this the Iteration Transition Meeting or the RLP Meeting or the Adapt Meeting... (suggestions welcome!)

The agenda for this meeting is very simple and contains the essential elements that exist in the "old" style. It starts with Reflection where the facts of the Action are examined: what did we build? how did we build it? how did we feel about what we built? etc. This moves fairly quickly to the Learning component where we try to understand what the facts are telling us: what went well? what needs improvement? what insights can we glean? what new questions are open to us? and of course, what did we learn? Now we are prepared to treat Planning holistically, with no "hidden" activities. We examine our Work Queue, re-arrange it, put new items on it, etc. and do our normal task breakdown and estimation. The difference this time is that both direct business tasks and process improvement tasks are included in the same planning activity. This makes task level (commitment) velocity more truthful!

I will admit that this is not something that I have tried yet. I have seen it done accidentally when people start to ignore the action items from the retrospective in the old iteration structure and instead include them in the task planning. When it happened, I thought it was "messy" because it broke the separation between "what" and "how" oriented activities. Now I think that this might be the best way to do things.

Anyone out there willing to give this a try? If so, I would love to spend some time with you working on it - helping, experimenting, and learning from it.

I should mention a couple important points that didn't fit in the above narrative. First, this insight happened as a result of discussions over the past week with my father, Garry Berteig who is using agile methods and the learning circle in his classroom environment. Second, Garry has been doing what I just described in his classroom environment; the main difference is that Garry provides a great deal of the Planning to his students by way of the progression of assignments/activities.

---

One other cool thing: I'm in Frankfurt as I write this on my way to Chennai to deliver a three-day Agile Project Management / ScrumMaster Certification course. I haven't done international travel since I went to Beijing last summer, and this is the first time I am going outside of North America for work! Fun!

---

* Normal here means Scrum and XP for the most part. Lean doesn't have this structure and as for other agile methods, I don't know them well enough to say if this is normal or not.

Posted by Mishkin Berteig at 04:16 AM | |

February 22, 2007

Strategic Plan

Okay, this is only marginally related to agile, but I thought it was interesting nevertheless: How to Write a Detailed Strategic Plan. The main connection to Agile Work, is that you need to have a clear performance goal in mind towards which you are working. This may be a great way to clarify your thoughts about such a goal.

Posted by Mishkin Berteig at 11:43 AM | |

February 12, 2007

To Be or Not to Be Agile

by Paul Klipp

For a decade now, agile processes, of which the best known is probably eXtreme Programming, have been gaining wide acceptance among developers, but many customers are still in the dark. Agile sounds good, but what does it mean? This is a quick and dirty preview of what you can expect when you choose an agile process.

At it's core, an agile process is designed to address a long-standing problem with traditional development methods: scope-creep. Most traditional processes begin with a thorough description of the desired product and then code until it's done. The weakness of these approaches is that in the event of a change in the business need or a reevaluation of the plan, much work can be lost and deadlines can easily slip out of control, and costs with them. The traditional way to address this problem is with change documents. A change document basically is a way of telling the customer what it will cost to make a change to the plan after development is underway. Agile processes are designed to do away with the cost of change so that the client is free to evolve the system under construction toward the ideal end goal, even if it is a moving target.

That's a tall order and skepticism is understandable.

Here's how it works.

As the client the first thing you want to do is to verify that the project has a positive ROI. I assume that you know why you want the software, what need it will serve and what value it will provide. What you need is a cost estimate to decide whether it's worth moving forward or not. The first round of planning provides that, but keeps things very rough and flexible.

As the project manager I help customers define the top level requirements and then the developers make rough estimates of the time needed to build the core components of a release. A release in an agile process is the first planned deployable version of your product. It's the first version that provides enough value to justify using it. Here is the first major difference between agile and traditional development. Using a traditional approach, you get your software when it's all done. Using an agile approach, the team builds many working versions of the software, and you get to choose when a version offers enough value to use, so you start enjoying benefits sooner.

If, based on the rough estimates, the client decides that the ROI is positive and chooses to proceed, I begin planning the first release. A team consisting of developers, a project manager, testers, and a customer who all collaborate on every phase of the process. Developers provide estimates and solutions, the project manager makes sure that the project runs as efficiently as possible and everyone has the information they need to do their job, testers help to write acceptance tests and they run both acceptance tests and unit tests, but the customer has the most important job of all. The customer writes the user stories, acceptance tests, answers developer questions during the development process, and decides when an iteration (a working version) of the product provides enough value to deploy. To be clear, I should explain that I use the word client to refer to the company or individual who commissions the software product. I use customer to refer to the team member (who typically works for the client) who is responsible for these very specific duties described above.

The release plan begins with a system metaphor and user stories. The system metaphor is a simple analogy that describes how the system will work. For example, Lunar Logic Polska recently created a purchase request system for which the system metaphor was an online store. That metaphor served two purposes. It allowed the developers to make intelligent choices when confronted with vague details in user stories and it provided much of the vocabulary for the project. Kent Beck has deprecated the system metaphor concept in XP, but I still find it useful. When it's not appropriate, other tools can be used to create a shared vision for the team.

User stories are described in more detail in my other articles, but they are basically short statements of functionality, just a title and a sentence or two, that describes what the product does. The project manager works with the customer to create the user stories in plain language. The details are filled in as needed during development by dialogs between the developers and the customer.

Once all of the stories for a release are written (the customer can add or remove stories between any iterations), developers estimate the time required for each story. They use best case scenario estimates. By consistently using best case scenario estimates, the developers set a standard for estimating that is easy to understand and apply. If a story is too complex, developers will work with the customer to reduce it to smaller stories. For some user stories, the developers might break the function into tasks defined in development stories that are attached to the user story. I have been experimenting for a few months with Mike Cohn's idea of planning poker and using story points to reflect complexity rather than time estimates and my team has generally found this to be a better approach.

The customer then takes the stories with the estimates and prioritizes them. I like keeping the priorities simple: high, medium, and low. There might be dependencies that aren't captured yet, but that's why the customer participates in creating the iteration plan. For some projects we use the DSDM MoSCoW system for priorities (Must have, Should have, Could have, Won't have).

Using the user stories and developers' estimates, we create an release plan. We decide how many iterations to do and how long each iteration should be. An iteration is a concept that deserves more description. An iteration is an agile way to achieve two main purposes: to produce usable product fast and to keep the code simple. It also helps to adapt to change. An iteration can last from one week to three months depending on the scale of the project. I prefer to keep them to a month at most. Each iteration produces a usable product. The exciting thing about iterative development is that the customer retains the right to change direction, change teams, or pull the plug and still have value to show for their money. As I wrote in a previous article:

"The beauty of iterative development combined with continuous integration is that if we approach a piece of software with the intention of working until all features are done (traditional approach), then at no point in the project is there usable code except at the end. Whereas with iterative development, the client can pull the plug at any time and have a working product, even if not fully-featured. For example, halfway through a large, waterfall or RAD (Rapid Application Development) style project we might have had a working administrative interface but not working user interface, or no user authentication system; in other words, a fundamentally flawed and unusable product. Halfway through an agile Project (at the end of any iteration) we have a product which, though lacking some intended features, actually had all the essential components of a software tool finished, tested, and ready to deploy if desired. The customer is not married to the project and the developers can't hold the project hostage until the bitter end; If it concludes early, the investment is not a sunk cost."

Iterative development also means that there are logical places to stop, reevaluate, change stories, and change the direction of the entire project if necessary, without causing any significant disruptions to the process.

An iteration plan assigns stories to an iteration based on the resources dedicated to the task and the time limit set for the iteration in the release plan. During development, developers work through stories in order of priority, occasionally asking the customer for clarification. The first thing the developers do each day is to discuss the plan for the day and get feedback from other developers on how best to approach the day's stories. Then, each developer begins a story by first planning the work necessary to implement it, and then writing unit tests to test the desired functionality of the code they plan to write. Writing unit tests before writing code forces the developer to clearly think thorough what needs to be done and the best way to do it. It also gives him a distinct goal - write the simplest code that will pass the unit tests. As he finishes each story, he integrates the code on the integration server and runs unit tests to ensure that his update hasn't broken any other functionality. When a story is complete, the developer notes the time taken to complete the story (we use this to refine our velocity calculation) and announces to the team that the story is complete, attaching a screen shot or video that illustrates this new function. The customer is welcome to offer immediate feedback so that story functionality can be tweaked early on, while the code is still fresh in the developer's mind.

As work progresses, I track actual time against estimates and thereby arrive at the team's "velocity." Knowing the velocity of a team on a project allows me to evaluate their future capabilities rather than second-guessing the estimates as would happen in a traditional method.

Meanwhile, the tester is working with the customer to write acceptance tests. More about this component of the customer's job can be found in my articles regarding the role of the customer. The tester is responsible for leading the team of QA testers who run acceptance tests on closed stories and verify that unit tests are passing. They produce regular reports of test failures that the developers use to refactor as they progress.

At the end of the iteration, which takes place at precisely the predetermined time, the testers run unit tests and acceptance tests and when everything passes, the working product is tagged in cvs. The customer now can decide whether to deploy the product of this iteration or to wait.

The iteration planning cycle then repeats. The customer can add or reprioritize stories and then a new iteration plan emerges. It is not at all uncommon for customers to have a much clearer idea of what they want as they see a project evolve. Iterative development accounts for this fact and gets working software into users' hands as fast as possible so that course correction is not delayed.

This has been a very brief overview of an agile process, but hopefully it illustrates how by using agile techniques, companies like Lunar Logic Polska are able to fulfill for their customers the ideals enshrined in the "Customer Bill of Rights" (http://www.c2.com/cgi/Wiki?CustomerBillOfRights):

Customer Bill of Rights

* You have the right to a plan, and to know what can be accomplished, when, and at what cost.
* You have a right to get the most value for each programming week.
* You have the right to see the progress in a running system, proven to work by passing tests that you specify.
* You have a right to change your mind, to change functionality, and to change priorities without incurring exorbitant costs.
* You have a right to be informed of schedule changes in time to choose how to reduce scope to restore the original date. You can cancel at any time and be left with a useful working system that reflects your investment to date.

If you know exactly what you want, and you know your needs won't change, and you are prepared to work with a software vendor to create a comprehensive document describing every aspect of the software you want created, and you are willing to commit to not making any significant changes in plan, and you trust your vendor to deliver exactly what you expect on time, then an agile process may not be right for you. If any of these statements do not apply to your project, then nothing will mitigate your risk and improve your level of control over your software project like a well-implemented agile process.

copyright 2006 Paul Klipp

Posted by Guest at 08:37 AM | |

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

The Agile Zealot's Handbook

This is great! I often call myself an Agile Zealot to my clients. (Usually, they smile... and if they don't I tend to have a short relationship with them!) So here it is, the Agile Zealot's Handbook.

And, since I've got a dead horse lying around waiting to be beaten up some more, I've re-written it (the Agile Zealot's Handbook, not the dead horse) to be non-software oriented. Presenting... the new and improved... non-software oriented... readable by anyone... Agile Zealot's Creed:

VALUE
IF you don't repeatedly deliver results
that produce actual value
for a real customer
into your real world environment
frequently enough to respond to change...

TECHNIQUE
IF you're not paying constant attention to technical excellence
with simple, effective tools, processes and reuse
driven by uncompromising dedication to quality
and the discipline to test everything...

LEARN
IF you're not deliberately going
through stages of planning, acting
reflecting and learning
as frequently as you are delivering results
over and over and over...

TEAM
IF your team is not empowered to self-organise,
does not sit together and engage in face-to-face communication,
does not include your customer
and all the necessary skills to make its own decisions and take immediate action...

THEN YOU HAVE COMPROMISED YOUR AGILITY

(and good luck to you... you'll need it!)

Posted by Mishkin Berteig at 08:41 PM | |

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 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 | |

December 13, 2006

8 Team Room Tips

Here are eight tips for making a great team room.

Light, Air, Nature
An appropriate amount of natural light, air circulation and live plants are excellent ways to make a space suitable for human occupation. The lack of these things can subtly but surely slow down and demoralize a team.

Layout
People need to be able to face each other and work beside each other. They also need a semi-private space to have discussions or make phone calls. The walls of the space need to have large areas that can be used for whiteboards.

Ergonomics
It's just not worth it to have a high-performance team hampered by a poor workstation setup. Good chairs, tables at an appropriate height, and the flexibility to allow individual ergonomic needs to be accommodated all help.

Privacy
Every member of the team needs to be able to get away for short amounts of time. Some organizations provide separate mini conference rooms or “hoteling” spaces. Others allow staff to keep a private cubicle away from the team room.

Personalization
The area of space that a person occupies needs to be flexible and personalized. People need pictures, toys, plants, and other incidentals to help them make a space their own.

Visibility to Outsiders
Other people in the organization need to be able to walk by to see and hear what is going on with the Agile Work team. Open doors, windows or a “bullpen” formation of cubicles all allow this.

Convenience
The space must be located so that washrooms, coffee, printers and other common services are easily accessible. It should not be set off and isolated far away from everything else.

Noise
The team will be noisy. Make sure that other people outside the team room are far enough away or isolated in some way from the noise. It can be hard to balance this with convenience and visibility.

Posted by Mishkin Berteig at 07:37 PM | |

December 11, 2006

Question from a Reader

A reader has asked:

I was wondering if you have any white papers or best practices on how to implement the agile methodology in a “product” company where we do more implementation of our product , not really new development. We have some development phases where we customize our product but we don’t necessarily do ‘pure software development” like Greenfield projects….

Here are my thoughts...

The concepts of Agile Work apply to many types of work, not just pure software development. I have experience working on a number of different project types using Agile Work including implementations, software upgrades, infrastructure changes, and system decommissioning. The basic ideas are always the same: set a goal based on specific valuable results, use iterations to deliver small bits of value in short time periods, and allow the team the freedom to do the problem-solving.

For product implementations, just like new software development, the most common approach is to deliver small numbers of features per iteration based on the product being integrated into the existing systems.

Here are some lessons learned from three infrastructure related projects that I worked on.

Do any readers want to share specific examples?

Posted by Mishkin Berteig at 06:38 PM | |

December 07, 2006

Peformance Goals - The Wisdom of Teams

As I continue my enthralled read through "The Wisdom of Teams: Creating the High-Performance Organization" I am moved to share another core concept that deserves to be considered essential for Agile Work:

The Performance Goal

This concept and practice is an essential condition for a team to become a high performance team. The Performance Goal is a specific, measurable, challenging goal that is given to and/or adopted by the team. It is a statement or description of a goal that answers "why?" and "what?" questions, but specifically avoids answering "how?". It is not a description of activities, it is a statement of desired results. The team is left with the full authority to answer "how?" and implement it.

This concept is essential for setting the initial boundaries of self-organization. By defining "what" and "why", the team is left free to be creative about the solution. The Performance Goal is also essential to building team accountability (as opposed to individual or externalized accountability). Every action, plan, mistake and success are oriented around the Performance Goal.

From the book:

The hunger for performance is far more important to team success than team-building exercises, special incentives, or team leaders with ideal profiles. In fact, teams often form around such challenges without any help or support from management. Conversely, potential teams without such challenges usually fail to become teams.

I would also like to point out a great blog entry I found that shows some of the other side of dealing with teams and present some cautionary words about the potential pitfalls of working in teams.

Teams as a Double-Edged Sword

---

In an Agile Work environment, the starting point for a performance goal is simply the delivery of valuable work at the end of their very first iteration. This is often a substantial challenge to a team and an organization. For some teams that have worked for a long time in a "waterfall" or phase-based project environment, it can be almost unthinkable that valuable results could be delivered in one tenth or one twentieth of the "normal" amount of time.

However, simply delivering value at the end of each iteration is probably not going to sustain the development of a high performance team for very long. Rather, the overall objective or goal of the project has to be important and compelling. Much work these days is _not_ important and compelling. In fact, many people become cynical about work because they are stuck doing a high proportion of work that is bureaucratic or due to chaotic circumstances.

As a reminder, the books "Good to Great" and "Built to Last" both discuss the importance of challenging, important goals. The wording is different, but the concepts all map to the idea of a Performance Goal. In "Good to Great" it is the "Hedgehog Concept". In "Built to Last" it is the "Big Hairy Audacious Goals" (no kidding!). I imagine this concept comes up in many other good books about team and organizational effectiveness. I would love suggestions on other good books to read about this! Please write them in the comments.

---

I frequently work with organizations where a team has been formed up, told to use agile methods, and then also told how to do their work. Really great examples of this are things like: "we want you to self-organize, but you have to build this huge system using J2EE." The the problem with this is simply that it may in fact be ten times less expensive to build the system with Ruby. However, someone has decided (possibly for defensible reasons) that J2EE is the technology platform that must be used. In this circumstance, someone external to the team has stepped over the boundary of "why" and "what" and also included some "how" in the team's goals. The team is not even allowed to consider the possibility that something might work just as well and be much less expensive. Not only that, but the stakeholders haven't even really stated "why" the system is being built and so the team can't evaluate technology choices. There is no standard around which to self-organize. I admit that I am using a simplistic example here, but the pattern is something that I have seen over and over again.

Posted by Mishkin Berteig at 11:44 PM | |

November 28, 2006

Planning vs. Commitment

In Scrum, there is some confusion around the various types of estimation that are done. Product Backlog Items are estimated and Sprint Backlog Tasks are also estimated. These two estimates, despite some similarities, are used for very different purposes.

Scrum advocates estimating the Product Backlog Items (Work Queue) using relative points. Each item is given a number of points that represents its size relative to the other items in the backlog. The team does this by identifying a small, well-understood backlog item and giving it, quite arbitrarily, 2 points of effort. All other items are estimated relative to this item.

For the Sprint Backlog Tasks, the estimation is usually done in "ideal hours". This is because tasks tend to be relatively fine-grained and in the context of developing software, the team typically breaks backlog items into tasks that take less than a couple of days of real effort. Again, there is a strong "relative" estimation component here where the team might look at tasks that are simpler and easy to implement and estimate those first, while the rest are estimated relative to those simple ones.

These two types of estimation are used for different purposes. Product backlog estimates in points are used for planning purposes. Task estimates in ideal hours are used for team commitment purposes.

Points -> Planning

When the project starts, an initial Product Backlog is created to be at least a skeleton of all the functionality that needs to be built. As described in a number of places, including both of Ken Schwaber's books, the items at the top of the Product Backlog are at a more detailed level (and therefore smaller in effort) than those items at the bottom of the backlog.

To plan out the project, the team must estimate all the backlog items using points. The team guesses how many items on the top of the backlog it can do in its first sprint. Then, taking drag factors into account, the Product Owner can take the number of points estimated for the first sprint and divide that into the total number of points in the backlog to find out how many sprints the work might take. As the team goes along, this can be redone based on the number of points completed in the previous sprint.

At no time are the points used by the team to determine how much work they will commit to in a sprint. The team's capacity for planning purposes is measured in points/sprint, but this is not used to constrain the team's commitment. Instead, the team uses its estimates at the Task level.

Digression: Bananas -> Commitment

"Bananas"? Yup, bananas. A different word than points, and a word that has no connection to actual effort. The problem with estimating in Ideal Hours is that people think that there should be some predictable relationship to real hours. This is both false and unnecessary. Tasks in the Sprint Backlog can also be estimated in relative units and since the work "points" is already used for Product Backlog Items, I would like to introduce "bananas".

The team estimates the tasks in relative bananas. Now, when the team completes its first sprint, it can measure how many bananas it estimated at the start of the sprint, and how many remained at the end of the sprint. The difference is the team's velocity which is to be used for commitment purposes. You can't use velocity for planning purposes because the team hasn't broken the whole Product Backlog into tasks, only the backlog items that it is doing in the current sprint.

Based on velocity, the team can make an informed commitment at the start of the next iteration: never take on more bananas than your velocity allows.

---

I have deliberately used the nonsense term "bananas" to talk about the units of effort for tasks. I could have used "ping pong balls", "elephants", or "nebulous units of time" (NUTs). The point is, that these units can never be converted directly into man-hours or any other unit that might accidentally be used for comparison or performance evaluation purposes. One team's velocity cannot be compared to another team's velocity. Even if both teams use "bananas", there are quite a number of factors that would prevent comparison: what tasks are used to baseline, the skills of the teams, the organizational and environmental obstacles, the definition of done, the mood and amount of sleep of the person working on the task, etc. etc.

Posted by Mishkin Berteig at 11:27 PM | |

November 24, 2006

How to Avoid Context Switching

Given the huge interest in the article by Dmitri Zimine about context switching, and despite a couple of good articles about how to determine iteration length, there has been no empirical method described, only reasoning processes. This article describes a simple method to quickly determine iteration length by experimental means.

Step One

Start with an iteration length that feels right. Use the two articles below to try decide a reasonable length. In software development, this should be no longer that four weeks. In larger volunteer communities it might be as long as three months. In a work environment where you have to deliver daily, your iteration length might be two hours.

Step Two

Build your Work Queue, and plan your first iteration. Mark the tasks that come out of your iteration planning meeting so that you know that they are tasks that were planned. As you go through this first iteration, track all the interruptions you get by writing up a task for each interruption. Each interruption task should be marked so that you know it was an interruption. If you are using note cards on a visible task board, I like to have "normal" tasks on white cards and interruption tasks on fluorescent orange cards to help them stand out!

Step Three

At the end of your iteration, determine which interruption tasks could have been deferred. In other words, determine which were truly urgent and needed to be handled in the already short time of your iteration, and which could have been put on the Work Queue, prioritized, and therefore deferred to a later iteration. This will require collaborating with your Queue Master and possibly other stakeholders.

Step Four

Count how many non-deferrable interruption tasks your team had in the iteration. For this experimental method, you can assume that this is going to be your normal number of interruptions. Divide the length of your iteration by the number of non-deferrable interruptions. For example, if you had a ten day iteration, and two non-deferrable interruptions, you would have a result of five days. Also consider what was the maximum reasonable response time for these non-deferrable interruptions. The lower of these two values becomes your experimentally determined iteration length. But you are not quite done!

Step Five

Do it all again to verify your iteration length. Note that because of your shortened iteration length, you hopefully will have far fewer non-deferrable interruptions. After your second (shortened) iteration, you can adjust the iteration length shorter if necessary... but don't adjust longer (for now).

---

I've worked with enough teams to know that for a substantial portion of them, this method would result in very very short iterations. In the software world, a team is often asked to work on a project and support their previous project. This support work tends to mean dealing with various bugs in deployed software. This is one reason why I have become such a strong advocate that quality is not negotiable.

I worked with one team that did something similar to this method (although not as rigorously) and we decided that we needed to try an iteration length of two days. This was painful for the team, but they badly wanted to build trust with their stakeholders. Their interruptions were causing them to constantly fail on their commitments. By switching to these two day iterations, they were able to defer the bulk of their interruptions and meet the commitment they made as a team in the iteration planning meeting.

---

Articles about iteration length:

Mike Cohn's article: "Selecting the Right Iteration Length for Your Software Development Process"

Mishkin Berteig's article: "The Pros and Cons of Short Iterations"

---

Now that you have gotten to the end of the article, I can admit something to you: this article is badly named. It should be named "How to determine how often to context switch so that you can meet your commitments and build trust with your stakeholders."

What this article doesn't help with is the pain of context switching. The teams that I have see that use short iteration lengths all find ways of making context switching less painful. Automation, good tool choices, workspace arrangements, etc. all play a part in this. But there is no secret ingredient to make context switching painless. Sorry!

Posted by Mishkin Berteig at 07:55 AM | |

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 p