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 peak over there is the highest of them all, let's go climb that one."

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

---

Joel said:

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

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

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

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

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

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

---

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

Posted by Mishkin Berteig at 04:13 AM | |

November 14, 2006

Process Facilitator "Smells"

I have now trained over one hundred people in my Agile Project Managmenet / ScrumMaster Certification course. I'm starting to see and hear some of the results of this training. There are a couple specific "smells" that I have become aware of.

Fortunately, I've been able to provide coaching to some of the organizations that have sent people to my course. There are quite a number of good things that happen, but there are a couple of things that seem to be "natural" misunderstandings.

1. Spectating
   I put a lot of emphasis on the idea of a self-organizing team in my course. There are a number of exercises, an hour-long section, and many other points during the course when it comes up. With all of this emphasis, it seems that a few people have come away from the course with an extremely hands-off approach to the Process Facilitator role (ScrumMaster/Agile Project Manager). I think this is a natural and probably good reaction to the heavy-handed command & control approach that these people come from. However, there are a few things that should be considered minimum levels of engagement (listed below).
2. Problem Solving
   There is also a great deal of emphasis put in the course on removing obstacles. I have seen several cases where it becomes the habit of the Process Facilitator to start solving every problem. This can happen in day-to-day work, and also in the retrospectives. Again, this seems to be a natural consequence of the desire to get in there and be of value. However, if the Process Facilitator writes down all the "things that need impovement" from the retrospective and then says "Okay! I'll take care of these things." then you know that the Process Facilitator has gone too far.

Appropriate Process Facilitator Engagement

Here are a few ideas on an appropriate level of engagement. Finding the right balance of enagement is not easy and there is no exact formula to follow. Partly it depends on your personality and skills as a Process Facilitator, partly it depends on the capabilities of the team, and partly it depends on the constraints of your work environment. Nevertheless, there are some types of engagement that you can persue with confidence. Here are a few concrete guidelines:

• Team Membership
  If you aren't saying "we" when referring to the team, you aren't engaged enough. The Process Facilitator is a member of the team.
• Colocation
  Most of your time should be spent sitting with the team. If the team isn't colocated, then you should be spending most of your time physically visiting each team member.
• Obligations
  The Process Facilitator is a catalyst. You must track all the obstacles and "needs improvement" things that the team raises, and then make sure that they get fixed... without going in and fixing everything yourself. Ultimately, your job is to work yourself out of a job.
• Assertiveness
  The organization that the team is working in will be creating some of the obstacles that the team is facing. Being assertive is critical to helping the organization face and then overcome some of these obstacles.

Posted by Mishkin Berteig at 01:49 PM | |

November 12, 2006

More on Scaling Agile

One problem with having multiple teams working on the same project will be the tendency to compare the teams' performance. Why is this a problem?

Why Not Compare Team Performance?

One of the main reasons is that the teams need to be collaborating not competing. There can be a small amount of friendly competition that might come naturally, but as soon as management starts paying attention to differences in team performance, the competition starts to get serious.

In the case of multiple teams working on the same project, the goal should be to maximize overall performance, not individual team performance. Too much competition can lead to unintentional or deliberate sabotage: failed communication, incomplete communication and downright dishonesty.

Motivating Teams without Comparing Them!

As Mary Poppendieck has written, measure up [pdf]. In a single-team situation this means that individuals are measured and rewarded based on team performance (their sphere of influence). In a multi-team environment, that means that the group of teams should be measured as a group and compensated as a group. This will encourage all teams to work towards the success of the overall project. I personally believe there is some room for individual-based compensation, but the way it is handled needs to be done so that it does not encourage sub-optimal behavior.

As well, each team can keep track of their velocity. Some coaches recommend using "ideal hours" or some other units to determine velocity (velocity = estimated work remaining completed / iteration). The trouble with doing this with multiple teams is that there will be a very real tendency to want to compare each team's velocity. Since velocity is a useful measure for team capacity, it is important to still have a way to measure it. One simple way to do this to prevent comparison is to use different units for each team. Team One might be measuring velocity in Estimated Ping Pong Balls Completed / Iteration... Team Two in Estimated Bananas Completed / Iteration... Team Three in Estimated Bogo-MIPS Completed / Iteration... etc. etc.

Motivating Collaboration

First off, management must make visible commitments to eliminating barriers to collaboration. For example, it is a great sign of commitment to re-organize office spaces so that all the teams are sitting near to each other. Every time the Process Facilitator identifies an obstacle that relates to collaboration (tools, process, physical environment, etc.) management should get right on it and fix it.

An ongoing investment in team-building training, workshops and exercises is also helpful. This type of investment helps people gain the skills necessary to work effectively with other people. Again, individuals need to see and believe that management cares about and values teams.

Finally, one of my pet peeves: when a project is over, keep the team together! Do not break them up and redistribute your "resources" to other efforts. The value of those people working together is substantial. The value of those people working together as a high-performance team is incredible! In a multi-team situation, it is reasonable to take teams from the overall group and re-distribute their efforts... but just don't break up the individual teams.

---

Miscellaneous Notes on Scaling Agile:

Twelve is still the maximum recommended size for a single agile team. Seven is really the sweet spot. A team larger than twelve people just takes too long to get into the Performing stage of team development. If you feel like your project needs more than twelve people actively involved, then you probably want to split into two or more teams... and then you have "scaled" agile.

If you have three teams of five people (or some similar configuration of people just over the 12 person limit), then they will work as a very close-knit group and a lot of the time will act as if they were a single team. They will probably plan iterations and do demos and retrospectives together.

Twelve teams working on the same project at once is about the maximum number before communication overhead is slowing everyone down too much. This is largely a factor of trust: with 150 or fewer people involved in an effort, it is possible for everyone to know everyone. More than that many people and it is no longer possible. Trust is just not an option anymore and bureaucratic controls take over.

If for some reason you need to do something in a small amount of time and you think it's going to take more than twelve teams of twelve people...? Break the effort into smaller chunks. Divide and conquer. Division can be across functional areas, structural areas or time.

Although I have heard of agile methods being used with groups larger than this, I haven't heard any success stories :-)

Check out my earlier introductory article on Scaling Agile in a large project situation.

---

Dean Leffingwell has an article about practices needed for scaled-up efforts at the Agile Journal. I glanced through it, but I admit that after I disagreed with his very first point (Intentional Architecture), I started to pay less attention.

He claims that refactoring of large systems is not possible (or at least infeasible). The odd thing is, most large projects that I have been involved with are being done exactly because an old system is not refactorable. A large telecom system, a large insurance system, a large data warehouse and a large GIS system are all being done with scaled up agile methods exactly because the old systems that are currently in place have become ossified to the point where they must be replaced.

These old systems were originally built with phase-based development approaches. At some point, people stopped refactoring because they were not given the space to do so. This drop in code quality turned into technical debt. The technical debt accumulated to the point where it was unbearable (maintenance costs, cost of change, etc.).

The problem with intentional architecture is that it goes back to the old assumption that you can do a good design for a system without the constant feedback from review, deployment and use done on a very short cycle time. Over and over, we are faced with the painful consequences of this attitude, and that is one of the key reasons we started to work with agile methods in the first place.

---

Martin Fowler makes a good case that scaling agile is the last thing you should do. I don't disagree! Scale your agile teams at your own risk!

It's nice for me to be able to say that I've worked on some agile projects over $10,000,000 in size, but the fact is that the cost could have been reduced substantially if the team size was lowered and the deadline extended. It is (relatively) simple to do a cost/benefit analysis of cross-team-coordination-overhead vs. the time value of early delivery of more functionality... although I've never seen anyone do it! If you know of an example of an organization doing this in a realistic way, I'd love to hear about it!

---

Are there other ways of supporting cross-team collaboration that you have seen?

Posted by Mishkin Berteig at 09:13 AM | |

November 07, 2006

Scaling Agile Projects

More and more, organizations are applying agile methods to large projects or efforts that require more than a single team. There are three dimensions or concerns of coordination. It is critical that all three be addressed, but there are many ways of addressing them. Here I will simply list these three types of coordination and make some simple suggestions of how to implement them.

I have now had the opportunity to work with several clients where they are applying agile methods to projects with budgets that are greater than $10,000,000. All of them are using multiple teams to work on the same overall project/program. Out of this experience (along with some good reading along the way), I have come to understand that the following three types of coordination are the essential ones:

Value

In order to maintain the "early and frequent" delivery of value that agile methods propose, it is important that the work of the effort be coordinated to maximize early delivery of value. From this perspective, there are often many cooks in the kitchen. I have seen a "Product Owner Team", a "Customer Team", and a number of variations of this type. In order to do the coordination work effectively, it is still necessary to make sure of two things:

1. Maintain a single Work Queue that prioritizes the work and from which all the teams select items.
2. Have a single person in the "buck stops here" role who can make final binding decisions about work priority and content.

These two items have some implications for the organization.

First, the teams must be organized to be generalist: each team should be able to handle any item on the Work Queue. Not every team is going to be equal in abilities and this can be accomodated in a number of ways. My favorite so far comes from an excellent agile coach Dave West who suggested that teams bid on the items in the Work Queue at the start of each iteration. This should be done in a collaborative fashion so that it isn't just a simple low-bid-gets-the-work, but rather the teams learn from each other and have an opportunity to adjust their bids.

The second implication is that the customer or product team (Queue Master) must have the availability to support multiple teams in a timely fashion. Ideally, there are individuals on each team who can make judgement calls about features, functionality, constraints etc. on the work and provide quick answers to questions. This is not always easy since the people doing this often have a special area of expertise and it is difficult for them to work outside this area. Just as team members are asked to become generalizing specialists, so must the people who are responsible for determining value in a project.

Process

An agile process endeavors to provide a minimally structured way to do three things: deliver value early, then learn about what is high in value and deliver that more, and finally, learn how to deliver value more effectively.

That third activity, learning how to deliver value more effectively, is facilitated by the Process Facilitator. The Process Facilitator keeps a visible list of obstacles and works collaboratively with the Team and the Stakeholders to resolve obstacles on the list.

In a multi-team environment, there may be a single Process Facilitator working with each team. Like with the Work Queue, it is often necessary to have a single Record of Obstacles for the entire project.

Technique

People develop skill and knowledge in the use of their tools. Most types of work have a special vocabularly that only makes sense to other people also doing that work. For example, the field of computer programming has programming languages, integrated development environments, build tools, testing tools, algorithms, and a host of other techniques. The field of film-making has cameras, film, directorial techniques, lighting, story structure, it's own esoteric vocabulary, and other techniques. Likewise for construction, law, medicine, drama, education, etc. etc. etc.

In a large Agile Work project, teams need a way to coordinate their technique to produce integrated, consistent and compatible results. As well, individuals on the teams may discover or create new ways of doing things that would be valuable for the other teams to know about and use.

The most effective way of coordinating technique across teams is for strong members of each team to gather regularly to review the way work is being done. This "technical support group" can look at tools, reuse, automation, patterns, vocabularly and any other "how to" aspects of the work. It is critical that these people are actively involved in work being done on a delivery team so that efforts of the technical support group do not become academic or "ivory tower".

In certain environments, it may be useful to have this techincal support group become a team with a clear allocation of time apart from the regular delivery teams. In this case, this technical support team would have its own Work Queue that consisted of requests, ideas, concerns, and opportunities presented by the regular delivery teams.

---

I have seen all three aspects of coordination implemented in large multi-team projects. Some of the common challenges include:

1. Generalist Teams.
   It is difficult enough to create cross-functional teams where people are willing to become generalizing specialists. While it is important to create generalist teams, most organizations should expect to set up non-ideal specialist teams (sometimes by line-of-business) and support their development into generalist teams.
2. Technical Coordination.
   Often organizations have a design or technical review group composed of the "experts". These people are often isolated from the actual work being performed by the teams. It is difficult, yet critical, that these people actually be involved in day-to-day work on the teams.

Posted by Mishkin Berteig at 09:15 AM | |

September 20, 2006

Recipe for Effective Meetings

I was running late for a meeting. Frustrated over being late, the meeting itself that looked like a waste of time, and overall number of meetings we have, I got an enlightment:

Meetings are a penalty for the lack of effective [face to face] communication.

Meetings are overhead. Trash. Wasted time, multiplied by the number of participants. They grow in length and numbers and the process becomes Meeting Driven Development.

But in a real world software organization we do have meetings, and no chance to eliminate them in any foreseeable future. The best we can is keep them under control.

A simple recepie of effective meeting:
* Own a meeting
* Define the goal, and expected outcome.
* Publish Agenda
* Come prepared
* Keep it short. Consider timeboxing.
* Close the meeting explicitly.

Comments on the bullets:

Coming prepared made easier when the goal, agenda, and expectation are set and known in advance. But still takes a commitment, discipline, and some training. If you see the participants didn't do their homework, stop and reschedule the meeting. It doesn't pay to continue the meeting; so you better send a strong message and the next time it will certanly be better.

Why timeboxing? Look at those people! When they come to an air conditioned board room, dive into those nice executive leather cheers, and got ready to a nap, buddy, good luck with your agenda! To keep the energy level high, keep the meeting short. Timebox it to 30 minutes, and say so. Keep a timer. Stand up. Make everyone physically participate - write on a white board, take notes, walk, move! Don't steal the whole meeting (oh, is it Dmitri saying that? who can believe!?)
Sometimes the meeting subject should be resolved and finished no matter what. Even then an incremental iterative approach to meeting pays off.

How to know when the meeting is done? How to know if it went well? The answer to this is a goal and expectations posted with agenda, and restated first thing in the beginning of the meeting. Write them down on the white board, have everyone look at it throughout the meeting.

Define the type of the meeting. Is it a brainstorming session? Is it a presentation? Is it an open discussion, feedback generation exercise? Are you gonna consume this feedback or throw it away? Decide, and define.

In closing, recap the goal, outline results, next actions, assigments. If the meeting was effective and productive, say so. Make your mates feel well (even if they missed their nap).

The final bullet:
* Foster communication beyond formal meetings. Remember that "Meetings are a penalty for the lack of effective communication."

---

Originally posted on Software Frontier

Posted by Dmitri Zimine at 06:53 PM | | | TrackBack

September 15, 2006

How to Prioritize a SCRUM Backlog

A prioritized list of work items is a key artifact of any Agile development process. Take a SCRUM Project Backlog or eXtreme Programming User Stories as examples. Armed with such lists, the development team will be working on the most important tasks at any given time.

The problem, however, is that assigning priorities to real tasks on a real projects doesn't follow a simple recipe. The act of prioritizing is the art of prioritizing. And as with any art, there are always tips and tricks. I will share a few from my experience.

Before We Plunge
I assume that a "collection" of items and a "time estimation" are already done. We have produced the list is of items with rough estimations waiting to be prioritized. I recommend a brisk borders between "Collection", "Estimation" and "Prioritization" stages. Have the "collection" and "estimation" sessions officially "closed", switch to "prioritizing". Don't let the talk to drop back until we have the priorities done.

Backlog Prioritization

The default strategy a project owner tends to take is "everything is important". As a SCRUM master you will try and convince him to use priorities, and explain that the Project Backlog "is a prioritized list so that the item on the top is the single most important one, with items below that being successively lower priority."

But how to do it in reality? Let's get a feeling: for the lack of a real project backlog, try to prioritize a vegtables in a grocery store. It is obvious that Oranges (10 lb) beats Potato (20 lb). But should onion (3 lb) go before tomatos (5 lb) or just after? What about lemons and garlic (1 lb)? Man, it just feels silly. Frustrating. Makes no practical sence. Discriminates the whole prioritizing session. Doesn't work for me.

This is my approach: In assigning priorities, usually ranged from 1 to 5. Why 5? Just cause I've got 5 fingers on my hand, and got so used to it.

On the first round we quickly go through the list and a project owner assigning the priorities from 1 to 5 as he feels. Don't think too much on computing exact priority to an item: use intuition. When in doubt, give it 3, and move on. Make it fun, and move it fast. We are not going for precision for now.

The result of this quick round is already good enough: look, we got some priorities! So many projects around work with no priorities AT ALL. We are light years ahead of our competitors! Cheer up! Great start!

The second round: refine. Compare equal priorities, escalate more important items, put down tasks that appear less important. Not sure? Appears equal? Fine, keep them. Try it out and you'll find that adjusting the original rough draft is easy. Few mintues later we are looking at a refined prioritized list that makes sense.

The final touch: count estimated time per priority, write them down on a whiteboard. It will look something like: Prio 1: 3 weeks, Prio 2: 12 weeks, Prio 3: 6 weeks, and so on. This simple math exercise is often incredibly revealing: a collective oh... sh.t are often heard. We brought to our conscious mind how much time we are going to spend on what we named "important". But how much time we actually have? This conflict usually triggers another burst of thoughts, and some final jiggling of priorities.

At this point our list of items is prioritized just fine to use it for planning the iteration. And it doesn't take much time to do: we did prioritize lists of 20 items in 10 minutes.

Final tips

It is funny that some product owners, in spite of my "5 fingers" reasoning, reported that they can't work with more then 3 categories. Fine, I let them feel in a driving seat and give them 3 gear transmission: 1st, 2nd and 3rd.

The advanced technique to tackle less reasonable Product Owner who tends to say "everything is important". Give them one "1", a limited number of "2", and as many "3" as they want.

If there are about 20 items, 1-5 priorities work efficiently. * If it is more then 25 items, you are in trouble. Consider bucketizing.

Do the exercise of [re]prioritizing regularly, at least once every iteration, before or (preferably) during the iteration planning.

Cross-posted from Software Frontier

Posted by Dmitri Zimine at 11:12 AM | |

September 11, 2006

Agile Team Launch - a Howto Guide for Managers

Starting off on the right foot is just as important as it ever was. However, with Agile Work, this takes on a significantly different meaning than it does in other methods as the emphasis of what is "right" is also significantly different. This is a short guide on how to successfully launch a team using Agile Work.

0. Do what you need to in your organization to get a project and its budget approved. This usually involves some sort of business case, project charter and approval process. This may sound obvious, but the organizational support that this provides is essential.

1. Management must have a basic understanding of the method and in particular the roles: Queue Master, Process Facilitator and Team. This can be accomplished in a number of ways: reading, attending a workshop, or bringing a coach in to do a brief presentation. By "management" is meant at least the person sponsoring the launch of an agile team.

2. Individual people must be identified to fill the Queue Master and Process Facilitator roles. At first, these people should be assigned to these roles full-time and relieved of their previous duties. Ideally, the people filling these roles are volunteers from a pre-selected group of appropriate candidates.

3. The Queue Master and Process Facilitator must both get some initial training. For this, the following books are recommended for both roles: Agile Estimating and Planning (Robert C. Martin Series), User Stories Applied: For Agile Software Development (Addison-Wesley Signature Series), and Agile Project Management with Scrum (Microsoft Professional). Unfortunately, all of these books are software-specific and if you need to apply Agile Work in a non-software environment, there will be some effort in translating the concepts and practices. You may need more specific training depending on the criticality of your pilot project.

4. Form up the team. Getting this right is not easy: the team needs to remain relatively small (5 people is about right), but at the same time include people with all the skills necessary to deliver the whole project. You need people who are good at the various technical skills needed, the people skills needed, the problem-solving and analysis skills needed, and the administrative skills. All these people need to be part of the team right from the start. Again, for emphasis: do not start the project before all these people and their skills are dedicated to the team and they have been relieved of their previous duties. Forming the team includes logistical concerns such as where the team will sit, making sure they have the right equipment for their work, etc.

5. If you are trying agile for the first time, don't consider using a distributed team or off-shore resources. Nor telecommuters. This type of stuff is better left for once your organization has more experience with agile methods.

6. Provide initial training to your team. Include the Queue Master and Process Facilitator in this training (they are considered part of the team). Also include any significant stakeholders in the results of the project. Give them, at a minimum, a one-day introduction to agile.

7. The Queue Master creates an initial Work Queue. The rest of the team should participate in this process. The creation of this Work Queue must be timeboxed. I advise that it should only be given 1 or 2 percent of the overall project time. Decide before you start on how long will be given to this. The end result of this is a Work Queue that has some number of work items defined, understood by the team, valued, costed, and prioritized. The Work Queue does not have to be "finished". It is more important to hold to the timebox than to get the Work Queue "right". Remember that the Work Queue will continue to be refined as the team progresses in its work. Do not under any circumstances create the initial Work Queue in the absence of the team!

8. Run a brief project workshop. In this workshop, the team answers basic questions about the nature of the project run with agile methods such as:
- what is the length of our iterations?
- what are the team's core hours (when do all the team members commit to working together as opposed to working on administrivia)?
- what other teams/groups do we need to work with?
- are we missing any critical skills (now that we have seen the initial Work Queue)?
- what are the priorities of the project (quality, scope, time, budget, experimentation, etc.)?

9. OPTIONAL ITEMS:
- Consider doing a workshop on corporate culture and agile methods to help the team understand some of the challenges it will face and where it can find support
- Consider doing some initial team building exercises. Particularly if people on the team haven't worked together previously, this can help the team to get over some initial hurdles.
- Consider getting junior members of the team some additional training on the techniques, technologies or tools used in the team's work. This can be arranged so that it is done simultaneously with some of the team's early iterations.
- Consider engaging a coach or mentor for your Process Facilitator. This coach can be someone inside the organization who has extensive experience with agile methods or an external consultant who comes for a limited time to help your Process Facilitator.
None of these optional items should unduly delay the start of the first iteration.

10. Start your first iteration. There should be little or no delay or waiting between the creation of the team and the start of the first iteration. At this point the Process Facilitator is responsible for the process, the Queue Master is responsible for the value delivered, and the Team is responsible for delivering results.

Posted by Mishkin Berteig at 11:36 AM | |

September 06, 2006

The Product Owner Role

I've been researching the requirements and variations on the Product Owner Role for a client that I am assisting. Here is a small collection of links and notes.

Updated (Originally posted Nov. 18, 2005).

Being an Effective Onsite Customer or Product Owner - great description of the ideal Product Owner.

Agile Product Owner Boot Camp - nice little bit in here about collaboration.

Certified Scrum Product Owner Course - don't know how good this is, but might be useful.

Here is my suggestion for a definition of the Product Owner role:

The Product Owner holds the final authority for determining the value, priority and details of all work done by an Agile team. The Product Owner wields this authority by virtue of a deep knowledge of the goal and end results desired as well as a respected position among all the stakeholders.

The Product Owner role is also known as the Queue Master, the Customer. People who have done the Business Analyst and Product Manager roles are often good candidates to fill this role.

Posted by Mishkin Berteig at 11:02 AM | |

September 05, 2006

The Seven Core Practices of Agile Work

Agile Work consists of seven core practices. These practices form a solid starting point for any person, team or community that wishes to follow the Middle Way to Excellence.

Self-Organizing Team

Any group of people that wish to be an Agile Team need to take the initiative to determine for themselves how they are going to work (process) and how they are going to do the work (product). The term "team" really applies quite broadly to any size group of people that are working together towards a common goal.

Teams go through stages of development as they perform their work. The most important result of team development is the team itself, and not the specific skills and abilities that the individuals learn.

If the team is part of a broader organization, that organization must give the team the authority, space and safety to learn to be self-organizing. The organization's leadership is responsible for determining the "why?", some constraints on "how?", and then letting the team respond to the need as best as it can.

Also Known As: Whole Team (Extreme Programming), Cross-Functional Team (business management).

Deliver Frequently

Agile Work uses short fixed periods of time to frame the process of delivering something of value. Each of these iterations or timeboxes is structured so that the team or group actually finishes a piece of work and delivers it to stakeholders. Then, the team builds on what has previously been delivered to do it again in the same short amount of time.

The sooner that valuable results can be delivered, the more value can be obtained from those results. This extra value is derived from opportunities such as earlier sales, competitive advantage, early feedback, and risk reduction.

There is an explicit tradeoff: the shorter the time to delivery, the smaller the piece of value will be. But, like investing in one's retirement account, the earlier you start, even with small amounts of money, the better off you are in the long run.

Also Known As: Sprint (Scrum), Iteration (Extreme Programming), Timeboxing (generic), Time Value of Money (accounting).

Plan to Learn

Every type of work is governed by a Horizon of Predictability. Any plan that extends beyond this horizon of predictability is bound to fail. Agile work uses an explicit learning cycle tied in with the planning of work to accomodate this inevitable change.

First, a goal is required. This goal can be long-term. Teams using Agile Work then create a queue of work items to be done in order to reach this goal. Each iteration, some of these items are selected, finished and then the queue is adjusted. The changes in the work queue are based on external factors, and learning that the team does as it goes.

One of the most effective methods for the team to learn about how it is doing its work is the retrospective. After each delivery of results, the team holds a retrospective to examine how it can improve.

Also Known As: Inspect and Adapt (Scrum), Kaizen (Lean), Adaptive Planning (generic).

Communicate Powerfully

A team needs to have effective means of communicating, both amongst team members and also to stakeholders. To Communicate Powerfully, a team needs to prefer in-person communication over distributed communication. Synchronous over asynchronous communication. High-bandwidth over low-bandwidth communication. Multi-mode communication over single-mode communication.

The results of failing to communicate powerfully include wasted time for waiting, misunderstandings leading to defects or re-work, slower development of trust, slower team-building, and ultimately a failure to align perceptions of reality.

The single most effective means to communicate powerfully, is to put all the team in a room together where they can do their work, every day for the majority of the work time.

Some types of work do not lend themselves to this approach (e.g. creating a documentary video), but every effort should be made to improve communication.

Also Known As: Visibility (Scrum), Whole Team and Team Room (Extreme Programming), War Room (business management).

Test Everything

Defects are one of the most critical types of waste to eliminate from a work process. By testing everything, by driving all the work of a team by creating test cases to check the work, a team can reach extremely high quality levels. This ability to prevent defects is so important that only an executive level decision should be considered sufficient to allow defects into a work process. Quality is not negotiable.

In Agile Work, removing a defect is the only type of work that takes priority over any new features/functionality/production. If the end result desired is to maximize value, then removing defects is an important means to that end.

A team has an ethical duty to discover new ways to effectively test their work. This can be through the use of tools, various feedback mechanisms, automation, and good old problem-solving abilities.

Also Known As: Canary in the Coal Mine (Scrum), Test-Driven Development (Extreme Programming), Defects per Opportunities (Six-Sigma).

Measure Value

Since Reality is Perceived, it is important for an agile team and organization to have a clear method of describing and perceiving what is important for the organization. Measuring value is a critical method for describing and perceiving what is important.

A single metric can be used to drive all the measurement and goal-setting and rewards in an organization. All other measurements are secondary and must be treated as such: limited in use and temporary.

There are many things which are easier to measure than value. It is often easy to measure cost, or hours worked, or defects found, or estimate vs. actual... etc. However, all of these other measurements either implicitly or explicitly drive sub-optimal behavior.

Also Known As: Measuring Results (Scrum), ROI (business management), Economic Driver (Good to Great), Running Tested Features (Extreme Programming).

Clear the Path

Everyone in an organization using Agile Work takes responsibility for clearing the path, removing the obstacles that prevent work from being done effectively. Clearing the Path doesn't just mean expedient, quick fixes to problems, but rather taking the time to look at an obstacle and do the best possible to remove it permanently so that it never blocks the path again.

In the Agile Work method, the Process Facilitator is the person who is responsible for tracking obstacles and ensuring that the path is cleared. To do this, the Process Facilitator maintains a Record of Obstacles.

Clearing the Path is sometimes painful work that exposes things we would rather not deal with. As a result, it is critical that people build their capacity for truthfulness and work to develop trust amongst each other. Building a capacity for truthfulness is not something that can be done by using an explicit process.

Also Known As: Removing Obstacles (Scrum), Stopping the Line (Lean).

---

Remember also, that these practices must always be viewed and implemented in the context of the Agile Axioms. These axioms provide a check to ensure that the practices are not being applied blindly, but rather applied appropriately to the given situation.

Posted by Mishkin Berteig at 09:09 AM | |

September 04, 2006

Pair Problem Solving - Sudoku!

In a training course I recently delivered, I tried a new simulation exercise. Using the game Sudoku, I divided the class into two groups: a group that would solve the game in pairs, and a group that would solve the game solo. My hope was that I would be able to demonstrate some interesting aspects of working in an agile team, particularly around communication and problem solving.

The setup for the simulation exercise was fairly simple: print out the same Sudoku puzzle multiple times, give the group basic instructions about how to do the puzzle, divide the room (1/3 are solo, the other 2/3 pair up), hand them out flipped upside down, make sure people had pencils, and then let people work on the puzzles for ten minutes.

After ten minutes, everyone put down their pencils and we listed out how many spaces had been filled in for each solo/pair. Since some people did not know how to do the puzzle, there was a large variation in the actual times.

The interesting part came with the discussion.

One important observation was that a person who was experienced at solving Sudoku puzzles felt hindered by having to work with someone who wasn't experienced. It was difficult for the experienced person to take the time and explain every time why he was putting a number in a particular spot.

Someone else mentioned that she felt time-pressure and did not enjoy that.

These two observations together led to a good discussion about how agile methods timebox everything and therefore there is always time pressure. However, scope pressure is meant to be relieved somewhat so there should be time to help bring junior / new team members up to speed. The frustration we feel when trying to work with someone who doesn't know how to do the work is often because we feel time pressure - we are impatient. Agile methods use timeboxing as a counter-intuitive way of relieving the time pressure.

There was also some discussion about how problem-solving for Sudoku may be easier in pairs because it is easier to search the overall solution space. Some of the pairs tried putting numbers in randomly and then seeing if the placements resulted in inconsistancies. Although no one solved the puzzle in the ten minutes given, there was a feeling by the pairs that their approach may have been able to solve the puzzle fairly quickly. This is something to explore further!

One person working solo said that she had felt frustrated because she did not understand the puzzle. That immediately led to a pair piping up and saying that even though both of them had never done Sudoku before, they felt mutual support and therefore it was fun rather than frustrating.

---

The next time I try this, I would like to try solo, pair and trio work. I would also like to give better instructions: that the puzzle should be solved purely using logic, no guessing, that the puzzle has exactly one correct solution (and making sure I have it available for comparison). I would also like to give the class fifteen minutes instead of ten minutes to work on it. I will start collecting times to see if there are any statistically significant relationships between group size and number of cells correctly filled in.

Posted by Mishkin Berteig at 03:15 PM | |

August 29, 2006

Seventeen Tips for Iteration Planning

Agile Work requires a team to take work items from a prioritized list, break those items into small tasks and then execute those tasks inside of the timebox of an iteration. When first trying agile, many teams have trouble with the task breakdown done in the iteration planning meeting. Here are some hints and tips for making this critical part of the agile process more effective.

1. Work items are, among their other qualities, valuable to the customer or stakeholders. Think of these work items as being built out of many smaller pieces. You can imagine a toy model made out of Lego bricks. Each brick, by itself, is of no value. It is only when they are put together that they become useful. The tasks you create for each work item are often small enough that they do not have any value on their own.

2. The word "task" implies activity... but the tasks you create for your work items do not need to be activity based. Tasks can be effective if they are written as components or pieces of the work item you are building. Here is an article about creating good tasks.

3. Sometimes if the work item is not well understood, you might find that a "research" or "experiment" task is a good starting place. Try to be as specific as possible. When writing the task description, spell out what exactly is the goal of your research, and possibly list what options you are going to research.

4. When first starting out with Agile Work, many teams find it difficult to do a good job of iteration planning in the fixed amount of time allocated to it. Consider shortening your iteration length so you can practice this skill more frequently. (Remember to make the planning meeting shorter too!)

5. Make sure that everyone has index cards and a pen to write with! Team members shouldn't have to wait for a "scribe" to write down a task. In many ways this is a brainstorming session. The Process Facilitator can collect all the cards after the meeting is finished if they need to be recorded more formally.

6. Do a first pass by creating "big" tasks... then break them up into smaller tasks if you have time. Since this meeting is timeboxed, it is better to get all the work broken down into big chunks than to break down only a small part of the work into very fine chunks.

7. If the same task keeps showing up for all your work items, it probably shouldn't be a task... instead it should probably be a process step or constraint or condition of satisfaction for the work you are doing. For example, if you always have to write a document that follows a template to record what you have done for each work item, then writing that document can be shown as part of your task board.

8. It's okay for tasks to be _very_ small.

9. Share your tasks! If you write a task down without telling the rest of your team, they can't use your idea to generate more tasks, nor can they improve on your idea.

10. Generating tasks in the iteration planning meeting is a problem solving and creative process. This is where you do a lot of your analysis and design work. This is where you struggle through options and choose _how_ to build/do your work.

11. Consider creativity technique such as light-weight brainstorming for generating lots of ideas quickly. Any technique you use should be streamlined for quick results.

12. Don't worry about administrative stuff while you are generating tasks. For example, if you normally put task cards up on a wall, wait until after the meeting is over to do this. Likewise, if you normally enter them into an electronic tools, wait until the meeting is over to do this.

13. Make sure you have scrap paper or a good whiteboard convenient for notes and drawings so that you can quickly model your solution for the work item. (Check out Agile Modelling for a discussion of this in the software realm.)

14. Remember that it's okay if you end the meeting with an imperfect list of tasks. You will make corrections throughout the iteration. It is more important to maintain the discipline of the timeboxed meeting length, than to get the tasks right up front.

15. The whole team must participate: everyone's experience, skill, expertise and insight are needed to do the best job of generating tasks. Just because it won't be a perfect list doesn't mean you can do a shoddy job of it!

16. You need quick access to information about the work items you are planning. You also need quick access to other relevent information. A computer with a web browser open to Google is a great tool to have at hand.

17. If you don't have anyone on your team who has lots of diverse experience and expertise, then consider inviting someone like this as a guest to help you out. It is much more difficult to do the necessary problem solving if you new to the medium in which you are doing the solving. Such a guest would need some time before the meeting to be prepared.

Posted by Mishkin Berteig at 10:44 PM | |

August 24, 2006

What's Causing All These Problems?

Yesterday, an important and interesting story passed through the scrumdevelopment yahoo group. It seems that a team was experiencing substantial pain using Scrum. This story shows an interesting and effective method of addressing that pain during a retrospective. Pete Deemer, who is Chief Product Officer of Yahoo!’s 700-person Research and Development organization based in Bangalore, India, tells the story:

I wanted to share an interesting experience I had today.

I was doing a retrospective with a team that's about 2 months / 3 sprints into scrum. Coming into the retrospective the team seemed to be feeling pretty low – they had yet to hit their sprint goals, and were seeing other unpleasant things -- and comments like "IF we keep using scrum" were coming up in their conversation.

Over the first hour or so of the retrospective the team came up with two lists: "what's working" and "what's not working". The "what's not working" list wound up being about 17 items, almost twice the length of the "what's working" list. Most of the discussion centered around the things that were not working; it was an imposing list, made all the more so by the fact that it was a lot longer than the other one, and we spent most of the time talking about it. Once the lists were complete, the group spent a moment or two staring quietly at them.

Then, I tried something I hadn't done before. I suggested the team go through both lists, and mark each item as either "C" (caused by Scrum), "V" (made visible by Scrum, ie would be happening with or without Scrum), or "N" (not related to Scrum, ie the weather, etc). Then we tallied them up.

Under "what's working", the score was C=7, V=1, N=2.

Under "what's NOT working", the score was C=5, V=12, N=2.

We stared at the results for a minute. Then one of the junior members of the team volunteered, a little tentatively: "so it looks like Scrum is actually CAUSING the good stuff, but the bad stuff is mostly just things it's MAKING VISIBLE. [pause] That's exactly what we want, isn't it?". The rest of the team nodded and murmured in agreement. In an instant, the group's understanding of its situation went through what felt like a polar reversal.

It was a really wonderful moment!

For a process facilitator using any agile method, this is an important tool to be able to use. It is simple, and gets to the heart of the unspoken concern that many new teams have that agile is causing all the problems. In fact, most often, agile is simply exposing all the problems that are part of the organization, the environment, the team dynamics, the technology being used, or even the people on the team.

---

About Pete Deemer:

Pete Deemer is Chief Product Officer of Yahoo!’s 700-person Research and Development organization based in Bangalore, India. In this role, he oversees product development and innovation for products in both the US and Indian markets. Pete served previously as Yahoo!’s US VP of Product Development, guiding product development practices company-wide, including the adoption of Scrum. He has served in executive roles at CNET, Ziff-Davis / ZDNet, International Data Group, and was Publisher of the Let’s Go guide series. Pete has an honors degree from Harvard University, and served for a number of years served as a lecturer at the University of California – Berkeley’s Haas School of Business and UC-B’s Graduate School of Journalism, teaching classes in product development and strategy.

Posted by Mishkin Berteig at 07:36 AM | |

July 07, 2006

Agile Work Artifacts - Delivered Final Results

I've written a few previous entries about the artifacts of Agile Work: the Work Item List (or Backlog), the Iteration Tasks, and the Record of Obstacles. But I've left the most important for last: the actual delivered final results.

No agile process is worth the name if it doesn't deliver valuable results at the end of each iteration. In software, this means delivering running, functional, usable software every iteration. In documentary video, this means delivering a watchable, understandable story that communicates something about the topic every iteration. In construction, this means building a part of an edifice that can actually be used every iteration. In comic book production, this means creating a story told with pictures that is reproducable, comprehensible and engaging every iteration.

The other artifacts are all in support of this critical piece of the method. Only iterative delivery of valuable results allows effective learning and adaptive planning to take place.

Posted by Mishkin Berteig at 07:52 AM | |

July 03, 2006

Agile Work Artifacts - Record of Obstacles

The Process Facilitator has only a few key responsibilities. One of those is to remove obstacles that are preventing the team for completing its work quickly, effectively and with high quality. The team's primary tool for tracking this work is the Record of Obstacles. Like the Work Item List, this is a fairly simple artifact.

The Record of Obstacles is a list where each entry in the list has three bits of data: a short description of the obstacle, the date the obstacle was identified, and a checkmark if it has been completed.

This list can be maintained on index cards, a whiteboard or an electronic tool such as a spreadsheet or wiki. The Process Facilitator maintains this list and all additions to the list go through this person. The primary source of items for the Record of Obstacles is the team's status meeting where each team member identifies any obstacles preventing them from doing their work. Additional obstacles may be revealed at the retrospective, or during the regular course of work.

The Process Facilitator should do his or her best to resolve an obstacle immediately. Lean manufacturing has an extreme example of this called "Stop the Line".

Ideally the Record of Obstacles is highly visible to all members of a team. This is so that everyone is aware of the current status of the obstacles listed.

Although this list is not normally prioritized, it is useful to do so if the list of un-resolved obstacles is lengthy. The Process Facilitator is responsible for prioritization of this list.

Posted by Mishkin Berteig at 09:33 AM | |

June 14, 2006

Agile Work Artifacts - Tasks

I recently described the Work Item List. The second type of artifact used in an Agile Work environment is the Task. At its most basic, a Task is a simple description of how to do some bit of work towards completing an item in the Work Item List. However, there are some important things to remember when using Tasks.

What is a Task

Normally, an item from the Work Item List is broken down into multiple Tasks. These Tasks are all the things that need to be done or built to get the item into a deliverable state.

In general, the process of creating a bundle of Tasks for a given Work Item is a design or analysis process. It is a problem-solving process. The Tasks themselves represent the solution: the building blocks of the structure of the Work Item. Tasks do not normally represent the problem solving or analysis process.

Here are two contrasting (somewhat contrived) examples of Tasks generated for a "Home Office Addition" to make this clear:

Example 1 Bad:

• determine requirements for home office
• design home office layout
• check home office layout with client
• choose furniture and decor
• build home office
• install furniture and decor
• unpack books and files into home office

Example 2 Good:

• 300 sq. ft. maple hardwood
• 4' x 7' custom desk
• Aeron chair
• red leather sofa
• 16' custom bookshelves
• 22" double French doors
• 8' 4-panel vinyl triple glaze bay window
• 36 2x4x10' metal studs
• ... drywall
• ... other building materials and furniture and decor

Generating Tasks

The whole team works together to come up with the Tasks for every Work Item being worked upon during the iteration. The majority of the Tasks are determined during the timeboxed iteration planning meeting. Sometimes, the iteration planning meeting is not long enough to get all the Tasks defined. Sometimes new Tasks are discovered during the course of the iteration. Either way, it is fine to make changes to the bundle of Tasks as the work proceeds.

Special Tasks

Due to the timeboxed nature of the iteration planning meeting, a Team will sometimes find itself knowing that there is more analysis or problem-solving needed for a given Work Item. In this case, a special Task can be created to indicate that this analysis work needs to be completed. For example, the task might be labled "Finish analysis for Work Item 62", or it might say "Team meeting to finish Task generation for Work Item 62". Other ways of writing these Tasks include "Research...", "Solve..." or "Discuss...". Everyone needs to recognize that these tasks represent risk and uncertainty about how to get the work of the iteration complete.

Sometimes work needs to be done that is outside of the control of the Team. The Team should always try to find creative solutions to avoid this situation, but it is almost inevitable that Tasks will come up for which the Team does not have the expertise or the authority. These Tasks need to be treated very carefully since they can seriously hinder a Team's forward progress. The Process Facilitator should usually consider these Tasks as obstacles to be removed.

Working on Tasks

Typically, a single person takes responsibility for a single Task at a time. A person may end up working on other tasks for two reasons. First, if the Task he/she is responsible for has an unavoidable wait, then that person may go find someone else to assist until the Task is ready to be worked on again. Secondly, another person may have an urgent need for assistance and call other people away from their current Tasks.

Tracking the Work

In their most basic form, Tasks are assumed to all be roughly the same size or effort and small enough that they are only done or not-done. Therefore, tracking the work on the Tasks throughout the course of the iteration is kept very simple: how many tasks are remaining to complete in the remaining time of the iteration? There is no ambiguity: Team members report on completion of tasks to the Process Facilitator who updates a burndown chart to show the quantity of remaining work.

Gotcha's

Tasks must be written to avoid including wait time. For example, a Task that says "Get the parts delivered" actually includes three steps: make the request for the parts, wait for the parts to be delivered, receive the parts. Since it is often hard to predict how long a "wait" will be, it is important to break this down into two separate tasks: "order the parts" and "receive the parts" and then treat the wait time as an obstacle to be removed/minimized.

Posted by Mishkin Berteig at 09:34 AM | |

June 09, 2006

Agile Work Cheat Sheet - Retrospectives

I've created and published a new cheat sheet for Agile Work on running retrospectives. It's basic information, but it is a nice one-page reminder of two methods of doing a retrospective, things to consider, and how it fits into an Agile Work environment.

Posted by Mishkin Berteig at 01:00 PM | |

June 06, 2006

Agile Work Artifacts - the Work Queue

Agile Work requires only a very small number of simple "artifacts". The most basic is the Work Queue. This is very similar to the Scrum Product Backlog but there are some differences too. The Work Queue is like a carefully managed To-Do list. This article details the use of the Work Queue.

Basic Description

The Work Queue is a list of work to be done by a person, team, organization or community. The list consists of brief descriptions of what to deliver, not how to do it. The list is prioritized so that the item on the top of the list is the single most important thing to get done, with items below that being successively lower priority. All items on the Work Queue contribute directly to an overall goal. The person holding the Product Owner role manages the list.

Place in the Process

The place of the Work Queue in the process is very simple. The Work Queue is initially created after the overall goal is determined. Ideally, it is created before work towards the goal is started, but often Agile Work will be adopted for an ongoing effort, in which case work has already started. The Work Queue is constantly maintained by the Queue Master so that it maintains the above mentioned qualities. One or more of the items from the top of the Work Queue are selected to be worked on. As an item on the list is completed, it is removed from the Work Queue. The number of items on the list that are being worked on simultaneously will depend on the capacity of the people doing the work. If iterations are being used to plan work, then the Work Queue is updated every iteration.

How is it Created/Managed

The Product Owner is responsible for creating and managing the Work Queue.

The initial creation of this Work Queue is a simple process: based on the goals to be attained, and based on an other factors that are relevent, the Product Owner drafts an initial version of the Work Queue. The time spent on creating this initial version should be minimized using three techniques:

1. Keep the Work Queue small by recording only high priority items that need to be done immediately. Don't add items that are uncertain or will be done far in the future. (See "The Horizon of Predictability" for more information about this.)

2. Keep the Work Queue simple by focusing on point-form high-level descriptions of the items in the list. Don't worry about any details about how the item will be accomplished, who will do it, when it will be done, dependencies with other items, or technical or conditional details.

3. In advance, allocate a fixed amount of time to draft the Work Queue... and don't spend any more time on it than that. Get the assistance of the Process Facilitator to keep on track. The list doesn't have to be perfect or complete... you only need enough on the list to allow the work to start.

Ongoing management of the Work Queue consists of removing completed items or items that are no longer needed, adding new items as they are discovered, merging or splitting items as more is learned about them, and reprioritizing items. All of these tasks can be performed at any time. As well, the Work Queue should always be in a state of readiness such that the top items are ready to be selected for work.

The Product Owner is responsible for answering any questions that may arise about the work as it is progressing. If someone doesn't know what is meant by an item, then work on that item should halt until the Product Owner can clarify.

At no time is the Work Queue "frozen" or finalized. It is changing throughout the entire time that people are working towards the goal. Items that are completed are removed from the list, and do not need to be archived or recorded anywhere else, nor is it necessary to save versions of the list as it is changed.

Gating/Queuing

The Work Queue is a queue of work in process (WIP) that is built up in front of the people who are doing the work. As such, it is advisable to keep the list short. The Product Owner acts as a gate to the list: only those things that reasonably contribute to the goal and which are relatively immanent in implementation should be added to the Work Queue. If someone suggests something be added to the Work Queue, the Product Owner must, of course, take that under advisement and collaborate with the suggestor, but is not obligated to add the suggestion to the list.

The Product Owner can manage the size of the Work Queue by deciding how many iterations of future work are allowed on it. In other words, the number of items on the Work Queue is limited to how many can be accomplished in a fixed number of iterations. As the Team takes a number of items off the Work Queue, space is freed to add an equivalent amount of work back onto the Work Queue. The specific number of iterations chosen for this will vary depending on your circumstances.

Differences from the Scrum Product Backlog

The Work Queue does not require two things that are part of the Scrum Product Backlog: item estimates and item values. Adding this information to the Work Queue can be useful in many situations, but is not an essential part of the list.

As well, the management of the Work Queue is different from the Scrum Product Backlog in that the Product Owner is not obligated to put every suggestion that comes their way onto the list.

Advanced Use of the Work Queue

Consider adding the following information to each item on the list:

1. An estimate of effort. Make sure that these estimates are created by the whole group of people who will be doing the work.

2. An estimate of value. The Product Owner needs to be responsible for determining value, but the whole group of people doing the work and all the other stakeholders need to understand how that value was determined.

3. Cycle time tracking. When an item is added to the list, record the date/time it is added, then record the the date/time it is completed and removed from the list. The use of cycle time can assist in making a work process more efficient.

Posted by Mishkin Berteig at 04:24 PM | |

June 05, 2006

Good Intro to the 3 Questions in the Daily Team Status Meeting

Jeff Sutherland has written a very good summary article of the benefits of the three questions asked in a team's daily status meeting.

Posted by Mishkin Berteig at 04:13 PM | |

June 02, 2006

Cueing Agility - Creating a Supportive Environment for Agile Teams

In Blink : The Power of Thinking Without Thinking by Malcolm Gladwell, there is a chapter that describes a number of fascinating experiments. These experiments show how we can be influenced by very subtle cues in our environment. This is a very important lesson for us to apply in our work environments and in particular in our agile work.

In one experiement, researcher John Bargh designed a scenario to test how sensitive we are to written cues that are structured in a way that we are not consciously aware of being cued. Bargh created two lists, each composed of five words per list item. Of the five words, four were chosen to form a sentance, and the fifth word was selected so that it would not fit with the other four. Then the five words were jumbled.

For example:

rang phone peace the loudly

The people who came as subjects of the experiement were given one of the two lists and told to go through their list as quickly as possible and un-jumble the sentances.

Unbeknownst to the participants in the experiment, each group of five words also contained a word that was selected to suggest a feeling or attitude. In the first list, each group of five words contained one word that would suggest impatience, rudeness and aggressiveness. The second list contained words to suggest patience, politeness and calm.

All the subjects of the experiment were also given additional instructions to come to a particular office once they had completed their lists. At the office they were to receive final instructions. At the office, each participant encountered the experiment administrator deep in conversation with another person. Neither the administrator nor the other person acknowledged the just-arrived subject. Now the real purpose of the experiment was tested: how long would the subjects wait before interrupting the ongoing conversation?

The results were astonishing: those people who were cued with the list containing words suggesting impatience, rudeness and aggressiveness

eventually interrupted - on average after about five minutes. But of the people primed to be polite, the overwhelming majority - 82 percent - never interrupted at all. If the experiment hadn't ended after ten minutes, who knows how long they would have stood in the hallway, a polite and patient smile on their faces? (p 55)

Gladwell gives several more similar examples in his book. I strongly recommend reading this book to see just how powerful this cueing or priming effect can be.

---

For organizations, teams and even individuals, this effect can be harnessed. The most obvious ways include using posters, screen savers, banners etc. to constantly impress people with positive messages about teamwork, effectiveness, creativity and other values and qualities that might be deemed valuable. This should obviously go hand-in-hand with a conscientious removal of all negative messages.

For agile teams, there are some particular values that should be emphasized: truthfulness, courage, creativity, teamwork, trust, cooperation, hard work, learning, adaptability.

The message can also be communicated in more subtle ways - and this is actually likely to be more effective! Incentives, the power of exemplary behavior, and the physical environment itself all can contribute strongly. In Built to Last : Successful Habits of Visionary Companies by Collins and Porras, there is a whole chapter dedicated to the idea of "Cult-Like Cultures" where everything in an organization is focused around that organization's core values. The authors found the following four characteristics of successful, visionary companies:

• Fervently held ideology...
• Indoctrination
• Tightness of fit [for employees]
• Elitism

(p 122)

---

Interestingly, agile methods do tend to require "buy-in". In order to fully feel comfortable in an agile environment, people need to understand and fully accept a small number of very important beliefs:

The Agile Axioms

(These are the generic, non-software version of the Agile Software Manifesto.)

---

See also: Optimizing a Team Room

Posted by Mishkin Berteig at 11:26 AM | |

May 31, 2006

The Human Touch

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

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

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

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

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

How long does it take you to figure that out?

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

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

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

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

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

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

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

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

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

---

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

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

Posted by Mishkin Berteig at 11:12 PM | |

April 24, 2006

Link: Eight Barriers to Effective Listening

On the Retrospectives Yahoo Group, Michael Webb posted a link to his article Eight Barriers to Effective Listening. This article provides practical advice on how to improve communication. Since one of the basic practices of Agile Work is to maximize communication, this article is essential reading!

Barriers to Effective Listening

Just in case you don't go follow the link from my introduction, here is a bit more info to help convince you:

As a process facilitator, one's responsibility is to remove obstacles. This is a list of obstacles to communication and includes for each barrier a strategy to overcome the barrier. Therefore, anyone who is a process facilitator (agile coach, scrummaster, etc.) should look this over and incorporate it into their skill set.

Here is the list of the eight barriers to effective listening:

• Knowing the Answer
• Trying to be Helpful
• Treating Discussion as Competition
• Trying to Influence or Impress
• Reacting to Red Flag Words
• Believing in Language
• Mixing up the Forest and the Trees
• Over-Splitting or Over-Lumping

Mr. Webb ends his article with a very nice self-referential comment:

We can make a difference in the world by learning to listen better and by telling others about better listening. But only if they listen.

Update 20070911:

Interestingly, I believe there are two more barriers to effective listening:

1. Distraction! I know that I have a hard time listening if I am tired, if I am worried about something, if I have sensory overload from another source, or (to my embarrassment) even if I just have my email open while talking on the phone.

2. Poor communication tools! It is much easier to listen effectively if I am face-to-face with the other person. Any type of technology that is used to communicate between two people becomes a barrier to effective listening: email, telephone, chat, etc.

Here is an interesting online quiz/presentation about the barriers to effective listening. In this presentation, there are seven barriers to effective listening listed:

• Content of the message
• Appeal of the speaker
• External distractions
• Emotions
• Clarity of language
• Selective perception
• Inappropriate feedback

Posted by Mishkin Berteig at 10:50 AM | |

April 21, 2006

Agile Adoption Stages for Teams

We know that teams go through identifiable stages of development: forming, storming, norming and performing (1). What exactly does this look like for an Agile team?

Forming

Here the team is typically innundated with three sources of new information: the Agile process and practices, the nature of the project and the other people in the team. This can be overwhelming and people will react in diverse ways: calm wait-and-see, rebelliousness, passive-aggressive, excitement, etc. If the team has an effective coach or mentor shepherding them through this, then feelings will tend towards excitement. The reality of learning so much at the same time will make the first few weeks of the team's time together quite exhausting. People will be actively fighting old habits, and people around the team will be asking lots of questions. Retrospectives will usually show that the team is impressed with their own teamwork and communication and will also show some disappointment with specific agile work practices.

Storming

After only one or two iterations, the team will transition into the Storming stage of development. Because Agile methods "front-load" the learning and the crisis, this forming stage comes fast, but it is also relatively mild. (Front-loading the learning means that all the problems that an organization has that hold it back from delivering quality work quickly are made visible in the first couple of iterations.) People are not used to a project being in crisis right at the start. It is critical for a coach or mentor or manager to be aware of this effect and expecting it. Again, for emphasis: an Agile project is in crisis immediately!... and this is perfectly normal and healthy. If the organization and the team are able to find means of dealing with this early crisis, then the project will continue and build larger and larger successes. On the other hand, if the organization or the team try to ignore or hide the problems, then very quickly work will revert to the old way: bureaucracy or chaos.

Norming

After about four to eight iterations, the team will reach a fairly comfortable place: the basic agile processes and practices are understood, the organization and the team have removed some basic obstacles to getting work done (and consciously left some obstacles in place in all likelihood), and everyone on the team has a basic level of comfort with their role. The challenge at this stage is to avoid falling into the trap of complacency. Although comfortable, this level of performance is probably not all that much better than the old way. There will be real advantages: regular delivery of work, good communication between stakeholders and the team. But there will be many obstacles still to be removed, and the team has a long way to go in its development. If the team becomes complacent, then it is critical that a catalyst be introduced to incite the team to further development. Often, this can be as simple as a systematic and intensive program of capability building. As team members learn and practice new skills: process skills, technical skills, people skills, strategic skills, business skills... and as they become more and more aware of each other's capabilities, they will also become more and more aware of areas for improvement. Incentives need to be provided to help team members focus dilligently on self-improvement and team improvement. The iteration retrospectives become critical to help with this process... the tricky bit is that this is the stage when people start to think the retrospectives are no longer necessary!

Performing

The transition into the Performing stage for an agile team is gradual and happens over a fairly extended period of time. The definition of "getting to done" will gradually expand to allow the team to go from zero to full delivery of the end results every single iteration. There will be a temptation to split up the team and use these experienced team members to seed new agile teams - resist this temptation! Breaking up the team at this point destroys the value of time and effort invested in the team. It is much more effective to start a new team from scratch. The essence of a performing agile team is not the transferrable knowledge about agile processes and practices. Rather, the most important result of the team-building process combined with the agile process is the team itself.

Posted by Mishkin Berteig at 11:57 PM | |

April 12, 2006

Follow the Principles and Adjust the Practices

In "Built to Last : Successful Habits of Visionary Companies" Jim Collins repeatedly emphasizes that long-lasting successful companies have a very single-minded focus. But that focus is not stupid or blind. Rather, Collins uses the phrase "Preserve the core / stimulate progress". This is also the essense of agility.

Follow the Principles

What exactly are the principles? The foundation starts with Trust and Truthfulness. "Truthfulness is the foundation of all human virtues." Everything we do with agile should be about truthfulness (visibility, transparency) and building trust.

With this as a strong foundation, we can look at the Agile Axioms:

---

We are Creators
Reality is Perceived
Change is Natural

---

All of the other principles and practices associated with Agile Work flow from these basic assumptions about the world. We can't prove that the above three axioms are "true". But they either resonate with us or they don't. If they do, then it will be easy to use these axioms as a checkpoint for all the activities we engage in using Agile Work, wherever we apply it.

We are creators... therefore we derive our sense of value from our ability to create. If our creations are accepted by others, our team, our stakeholders or our community, all the better. But fundamentally, this is inherent to us as human beings. However, sometimes this natural drive is suppressed or repressed. In order to activate it, we need to work in empowered teams.

Have you ever experienced inspiration or "flow" or joy when working with someone else? Perhaps you were solving a problem. Perhaps you were playing a musical instrument - jamming - and got into a fertile groove. Perhaps you were teaching your children and created the light of understanding in them. Perhaps you built a beautiful set of bookshelves for your home. Or maybe you told a joke that created a brief moment of genuine levity in a group of friends. We are all constantly creating!

This basic principle then means that Agile Work methods and practices should not be imposed. Taught to us, perhaps... given to us as a template, perhaps... but once we understand the practices and are familiar with them, we should immediately be given the freedom to use the learning cycle to be creative with the process and practices of Agile Work itself. If we do not participate in creation, we become dis-empowered and that eventually leads to resentment or apathy.

Reality is perceived... therefore we need to work hard to build a common perception of reality if we are to work together effectively. We need to amplify our learning. We can't assume that our own understanding of a situation is going to be shared by others. At the very least we need to check: "do you see this?"

Let's recognize that in some way or another we are all blind:

Again, the learning cycle comes into play. The guidance, detachment, love, courage and search we go through all help us to build a common understanding of reality. This allows us to see new ways to apply the Agile Work principles and practices that make sense not only to our context, but also to everyone else participating in the work.

Change is natural... therefore instead of fighting change, we need to anticipate it, adjust to it, embrace it, and be gracious or even enthusiastic. Not only does change happen to us, but we also instigate change. If things get to boring, whatever the circumstance, we find ways to change things. We rebel at stasis and ennui.

Each practice and procedure done in the context of Agile Work must be explicity and implicitly accomodating of change. If a procedure can't tolerate change it will either lead to a dissonance or conflict... or if we are embracing change, then we will modify or discard the procedure. Our creative nature loves to create, but if we become too attached, too "in love" with our creations, we will support them past their point of relevance.

Our latest greatest idea will be good for a while. But eventually change will make it irrelevent.

---

So we see that all three Agile Axioms are also interrelated.

Our creations will be washed away through change and if we are lucky or wise we will perceive the change in reality - be truthful to ourselves and others - and allow a new creation to take the place of the old one.

When we perceive a certain truth, and try to share that with others, we will be asking those others to change their own perceptions. This change can be difficult and may even require the destruction of a mental model created with love and care over a lifetime. Sensitivity to this loss and encouragement to build a new creation will help build a shared perception... as long as we too are open to new perceptions!

Adjust the Practices

And of course, all this foundation of creation, perception and change must be connected to the practical day-to-day reality of our lives. Our family lives, our work lives, our social lives, our volunteer lives, our intellectual lives, our emotional lives, our spiritual lives... our whole lives.

The Agile Work practices are simple to state:

---

Manage Ourselves
Deliver Frequently
Adapt our Plans
Communicate Powerfully
Test Everything
Measure Value
Remove Obstacles

---

These practices provide a starting point. A basic set of activities that will assist you, your team or your organization to advance quickly towards whatever goal you have set for yourselves. The way these practices succeed is by making sure that the Agile Axioms are always remembered and their implications accepted. These practices will set up a virtuous circle by building trust and allowing truthfulness. More trust and truthfulness will allow a fuller and more nuanced expression of the practices...

But if these practices become canonized, if they become a rote process imposed and followed blindly, then it means that we have lost sight of the Axioms. We have forgotten to check our practices against the context of creation, perception and change.

The reason we follow these practices is because we believe that we are all creators, that we can learn from our diverse perception of reality and that change is a force of growth. We don't believe these Axioms because we blindly perform these practices.

---

This is all available as a nicely formatted pdf: Agile Axioms - a Brief Exposition.

Posted by Mishkin Berteig at 01:45 AM | |

April 06, 2006

Prioritizing requirements

The topic of prioritizing requirements came up in a recent meeting. Often the customer will say that all the requirements are top priority and are unwilling to place priorities in individual items.

The reason that we care about priorities is that we are going to implement the requirements in priority order. The most important things get built before the less important items. So, how do you handle the case where the customer says everything is top priority?

What I've found is that customers often think of priority and the order things get built as two separate items. If you explain that we can't build everything at once and need to decide which things to build first, the customer is usually more than willing to help with that. They're satisfying our need for priority but aren't thinking of it as setting priorities.

If you are using the XP technique of writing requirements on story cards then one technique for getting them prioritized is to hand the stack to the customer and explain that you will implement them in the exact order in the stack. If they wish to change the order of items then this is their chance to do so. It's helpful if you stress that the current order in the stack is fairly random.

I've found that when I do this, the customer will usually split the stack into two piles. One that really has to be done first because those cards are most important and then a second pile of less important cards that could be done in any order.

Cross-posted from Mike Bowler's blog.

Posted by Guest at 05:30 PM | |

March 31, 2006

How the Process Facilitator can Help the Team Handle Out-of-Scope Work Requests

Sometimes an agile team is innundated (or maybe just slightly distracted) by requests for individuals on the team to do work for people or groups outside the team's official stakeholders. This can happen, for example, in a corporate culture that promotes the exchange of favors. This past weekend at our Agile Coach's gathering, Deborah Hartmann shared her method of detecting, exposing and discouraging this unofficial work.

The mechanism is actually very simple: track the work in the team space using cards and a variation on the burndown chart.

The Cards:

During the team's status meeting, or any other time that a team member mentions doing some of this outside work, immediately request that that person write it down on a task card. The task card should be visibly distinct from normal task cards: either a different color or a different size or in a substantially different location. The task should also get an estimate in the same units you are using for the other tasks.

For each task identified, contact the person who requested the extra work. If the person who is doing the work has made a committment to the requestor then let the requestor know that the team has accepted the work but that there is a consequence: the team may not get all its other work done on time. As well, the requester should be informed that in the future, all extra work for individuals on the team must be prioritized by the team's product owner.

Encourage the team to reveal this work by mentioning it at the start of the status meeting, in any iteration planning or retrospective meetings, or in any one-on-one meetings you have with team members.

The Burndown Chart:

Now that all the extra work is reflected in cards with estimates, the burndown chart can track this work too. The key difference is that it is tracked as a separate part of the work. If there are 80 units of normal work remaining, and 20 units of this extra work remaining, then the burndown chart will have a mark at 20 and a mark at 100. The mark at 20 should be made in a different color (I recommend red) so that it is highly visible. One ends up with a burndown chart that looks something like this:

The Product Owner:

It doesn't take much more than a single iteration for the Product Owner to get the message loud and clear: this extra work is eating up the team's capacity! The Product Owner now sees the consequences of not being the go-to person for all work items.

Deb's experience with this was that by the next iteration there were no further requests of the team for unofficial work, and the team's capacity to do work for the Product Owner took a nice leap upwards.

Posted by Mishkin Berteig at 11:26 AM | |

March 20, 2006

Methods of Prioritization

In Jean Tabaka's new book, "Collaboration Explained : Facilitation Skills for Software Project Leaders", she describes several methods of collaboratively prioritizing a list of items (for example a project's work item list). The methods she suggests are excellent, and I would strongly recommend the book. However, there are a couple variations and additional methods that I have used successfully that I would like to share.

1) Round the Group prioritization:
group size 3-8
item list size < 15

Items are written on cards and placed in random order linearly either vertically or horizontally.

The members of the group each take turns placing the items in the order they think is the proper priority order. While doing so, each person moving the cards is welcome to explain their reasoning. However, the other group members refrain from commenting on the new prioritization.

This continues around the group as many times as it takes to find a stable order.

2) Ping Pong Balls:
group size 1-12
item list size > 15

(Thanks to Ken Schwaber for this method)

A fixed number of ping pong ball units are given to the group. The ping pong balls represent units of one dimension for prioritization such as value, risk or cost.

The group discusses how to allocate ping pong balls to each item in a dynamic fashion until everyone agrees that the allocation makes sense.

For very large lists, this is easiest to do in a spreadsheet with fewer people involved.

3) Variation: 2-stage multi-voting with voter freedom
group size 5-20
item list size < 50

This is identical to the public multi-voting system Jean describes with the following changes:

First, there is no restriction on how votes are allocated to items. A person can put multiple votes on a single item and can withhold some or all of her votes.

Second, after everyone has "finished" voting, the facilitator calls for everyone to step back and think about the results. Some discussion is allowed about the consequences of the results. Finally, everyone is given an opportunity to move their votes.

For large groups with large lists this can be somewhat awkward as people might forget where they voted. In this case, and if anonymity is not required, each person can use small post-it tabs with an identifying mark on them so that they can easily be moved around in the second stage.

Posted by Mishkin Berteig at 01:25 PM | |

March 12, 2006

Work Item Backlogs as Queues - Agile vs. Lean

A recent discussion on the Scrum Development list (Start of Discussion) provides a good follow up to my parting words in The Art of Obstacle Removal about agile practices themselves becoming obstacles. I have excerpted a small amount of the discussion and added my own comments here.

In the agile community, most of us have bought into and adopted the Agile mental model. But that mental model has assumptions embedded into that may not be correct under all circumstances. Part of that mental model includes the efficacy of the work item backlog as a tool for tracking, prioritizing and communicating work to be done in the future.

I will be the first to say that Agile is far better than waterfall in almost every situation (the exception being the mythical project with stable requirements, business environment, technology and team).

That said, let's look at backlogs from another perspective: if a backlog was the only thing you delivered to the customer, would they pay for it? If you spent even just a few hours coaching a business representative to build a backlog, but there was no team to implment it, would that person really find value in the backlog itself? Would they be able to deliver ROI just from a backlog? I think the answer is a clear "no".

---

That set of questions may seem silly, but from a lean perspective, they are among the most important questions. Is an artifact/process value-added or non-value-added?

Since the backlog is clearly not a value added artifact/process (pause for effect)... it is waste!

When one is doing agile effectively, the backlog may in fact be one of the larger sources of waste! If the team has a stable velocity, there will come a point when the backlog becomes the constraint on the overall cycle time going from idea to ROI. If the backlog is large/long, and as Mary Poppendieck said if there is more than ...maybe two or three
sprints of work.... in there, then it may be time to find ways of constraining the size of the backlog. I have two suggestions:

Capacity of Team(s):

Find a way to increase the capacity of the team so that the backlog size reduces and then goes into a steady state. This may mean augmenting the staff.

Gate Backlog Items by ROI

(This is just theory to me at this point.) Make it a condition that all backlog items must have a positive ROI. In other words, the cost of building the backlog item needs to be less than the value delivered, taking into account time value of money. Don't let items onto the backlog unless this positive ROI can be demonstrated.

I believe the lack of this second discipline (assigning ROI to work items) is one of the main reasons that most agile methods such as Scrum allow an unlimited backlog size: there is no realistic way to gate the work that gets onto the backlog!

---

Until teams get to Agile nirvana (stable velocity, continuous delivery of business value, high-performance cohesive teams), having an unlimited backlog seems like a very reasonable thing: it's not the constraint or the primary source of waste. However, eventually the backlog will become a primary source of waste and it needs to be treated in a disciplined manner.

With a stable and well-functioning team, what other ways might there be to reduce the size of the backlog so that cycle time is substantially reduced?

Posted by Mishkin Berteig at 03:31 PM | |

March 10, 2006

The Art of Obstacle Removal

One of the best ways to go faster is to remove the things that slow you down. This "obstacle removal" is an integral part of many agile methods including Scrum and Lean. Sometimes it is obvious where an obstacle is. There are a few small things that can be done easily to go faster. But to get going really fast, we need to have a deeper understanding of obstacles... and the Art of Obstacle Removal.

What are Obstacles?

An obstacle is any behavior, physical arrangement, procedure or checkpoint that makes getting work done slower without adding any actual contribution to the work. Activities that do add value to our work may be slowed down by obstacles, but are not obstacles in and of themselves.

Obstacles and Waste

Obstacles are the causes of waste in a process. There are many types of waste, and for every type of waste there are many possible sources (obstacles).

---

Types of Obstacles

Personal

Personal obstacles are related to us as individuals. There are several levels at which these obstacles can show up.

Outside factors in our lives such as illness or family obligations can become obstacles to our work at hand. These obstacles are hard to remove or avoid. Even if we would want to avoid an obstacle such as illness, it is hard to do anything about it in an immediate sense. However, as part of our committment to the group we are working with, we should consider doing things to generally improve our health. Good sleep, healthy and moderate eating, exercise and avoidance of illness-causing things and circumstances are all possible commitments we can make to the group. Likewise, we can make sure our personal affairs are in order so that unexpected events have the least impact possible. This topic is vast and there are many good sources of information.

Physical Environment

Obstacles in the physical environment can consist of barriers to movement or communication, or a lack of adequate physical resources. Sometimes these obstacles are easy to see because their effects are immediate. For example, if a team room lacks a whiteboard for diagrams, keeping notes, etc., then the team may not be able to communicate as effectively.

Other physical obstacles are not so obvious. The effects of physical environment can be subtle and not well-understood. Poor ergonomics take weeks, months or years for their effects to be felt... but it is inevitable. A too-small team room can lead to a feeling of being cooped up and desperation to get out... and eventually to resentment. Again this can take weeks or months.

Here are some guidelines on a good team room.

Knowledge

A lack of knowledge or the inability to access information are obstacles. A team composed of junior people who don't have diverse experience and who don't have a good knowledge of the work they are doing will have trouble working effectively. There may be barriers preventing the team from learning. Common barriers include over-work leading to a lack of time or mental energy for learning. With junior people in particular, there is a lot of pressure to be productive and that can often be at the expense of a solid foundation of learning.

Other times, knowledge-related barriers can be more immediate. If a critical piece of information is delayed or lost this can have a large impact on an Agile team that is working in short cycles. The team may be temporarily halted while they wait for information. Building effective information flow is critical to a team's performance.

Organizational

Bureaucratic procedures, organizational mis-alignment, conflicting goals, and inefficient organizational structures can all be significant obstacles.

One of the best sources of information about this is the two books by Jim Collins: "Good to Great" (Review) and "Built to Last" (Review).

Cultural

Sometimes the beliefs we have about how to work can become obstacles to working more effectively. These beliefs are often in place because they have been part of what we think makes us successful. Cultural assumptions can come from our families, our communities, our religious affiliation and our national identity.

In organizational culture, one thing I constantly see is a public espoused value of teamwork, but a conflicting behavior of individual performance reviews and ranking. This is cultural. It is also a barrier to the effective functioning of an Agile team. For corporate environments I highly recommend the Corporate Culture Survival Guide by Edgar Schein.

Dis-Unity

Dis-unity is one of the most subtle and common forms of obstacle. Competition, legal and cultural assumption of the goodness of "opposition" and habits of interaction including gossip and backbiting all combine to make united action and thought very difficult.

This is an extremely deep topic. There are many tools and techniques available to assist with team building. If you are interested in this topic, I highly recommend reading "The Prosperity of Humankind".

---

Removing Obstacles

The ability to identify obstacles and understand why they are causing problems is only the first step in removing obstacles. In Agile Work, the person primarily responsible for identifying and removing obstacles is the Process Facilitator. The Process Facilitator has several approaches available for the removal of obstacles. A process facilitator has similar responsibilities to a change agent.

Direct

Deal with the obstacle directly without involving other people. This can be as simple as getting up and moving an obstacle impairing vision, or as nuanced as running interviews and workshops throughout an organization to gradually change a cultural obstacle.

Command and Control

Identify the obstacle and give precise instructions for its removal to a person who will directly perform the removal. This can sometimes work if removing an obstacle takes a great deal of time, effort or specialized skills that you yourself do not posess. However, the overall approach of "command and control" is not recommended for Agile environments since it is disempowering.

Influence

Identify the obstacle and suggest means to deal with it to a person who has the authority or influence to get others to deal with it. This indirect method of obstacle removal can be slow and frustrating. However it usually has better long-term effects than command and control.

Support

Offer to assist and encourage the removal of obstacles that have been identified by other people. In many respects this is a very effective method. It can assist with team-building and learning by example. People are usually grateful for assistance.

Coaching

Train others on the art of obstacle removal including obstacle identification, types of obstacles and strategies for dealing with obstacles. Observe people's attempts to remove obstacles and give them feedback on their actions.

Creating a Culture of Obstacle Removal

Encourage and measure obstacle removal at all organizational levels until it becomes habitual. In many ways this is the essense of the lean organization.

---

Strategies for Dealing with Obstacles

Diagrams are a great way of communicating the essense of a concept. Feel free to share the following diagrams with anyone (but of course keep the copyright notice on them).

Remove

Remove the obstacle altogether. This method of dealing with an obstacle is usually the most immediately effective, but is also one of the most difficult methods.

The best way to actually remove an obstacle is to get at the root cause of the obstacle and change that. This type of change results in the longest-lasting and most stable elimination of an obstacle.

Move Aside

Take the obstacle and put it in a place or situation where it is no longer in the path of the team.

In a team's physical environment, this may be as simple as changing the tools that the team is using. For example, if the team is all in a room together, move computer monitors that are blocking team member's views of each other. If there is a useless checkpoint that work results have to go through, get management to eliminate it.

Shield

Build a shield or barrier to hide the obstacle so that it's effects no longer touch your team.

If a team is distracted by noisy neighbors, put up a sound barrier. If a team is unable to see their computers due to late afternoon sunlight, put up window shades. If a manager is bothering the team with meetings or tasks unrelated to the work of the team, then put yourself between the team and the manager (or get someone in upper management to do that).

Shielding is excellent for immediate relief, but remember that the obstacle is still there and may become a problem again if the shield cannot be maintained.

Transform

Change the structure or form of the obstacle so that it no longer affects effectiveness.

In general, this method requires a great deal of creativity and open-mindedness. This is one that works particularly well on people who are obstacles: convert them into friends of the team!

For example if the team needs approval of an expert who is not part of the team, this can cause extra work preparing documentation for this person and long delays while the expert revies the documents. If the expert becomes part of the team, then they are well-informed of the work being done and can give approval with very little overhead.

If done well, this can be a very long-lasting method of dealing with an obstacle. Make sure that the transformation is true and that it takes hold... and beware that the obstacle doesn't revert back to its old nature.

Counteract

Find an activity that negates the effects of the obstacle by boosting effectiveness in another area.

As a coach or Process Facilitator, this is what we spend our time in early in a team's adoption of Agile Work: we get them to work in the same room, use iterations and adaptive planning, we focus them on delivering work valued by the stakeholders as defined by the Product Owner. All these things are enhancing the team's ability to get work done without actually directly dealing with any obstacles.

Watch out for barriers avoided this way to come back and bite you later on.

---

Removing Obstacles and Learning

Organizational learning, as well as adult learning have a strong relationship to obstacle removal. Organizational learning can be either single-loop or double-loop learning. Adult learning can be either normal or transformative. We can approach obstacle removal from a surface level where we only deal with the immediate symptom, or we can work at a deeper level where we deal with the symptom and its chain of preceding causes. One effective method for examining the deeper causes is the 5-why's exercise.

---

Obstacles Inherent in Agile

Agile methods do not perfectly eliminate all obstacles. Some obstacles that are inherent in agile methods include overhead due to planning meetings at the start of iterations, the use of a dedicated process facilitator. As well, the use of iterations can become a barrier to certain types of work items: repeating items, investment in infrastructure, one-off tasks that are not directly related to the work at hand.

At some point, our teams will have matured to the point where agile methods are no longer necessary and we can pick and choose what parts of agile we use.

---

Go Forth and Demolish Obstacles!

As a Process Facilitator, coach, ScrumMaster, manager, change agent or stealth agile advocate, you have the ability and the knowledge to make a big difference in people's lives and in the success of the organizations they work within. Removing obstacles is one of the most important duties you have.

---

Do you have stories about obstacles you have removed or seen removed that have made a big difference? We would love the hear the anecdotal side of this as well!

Posted by Mishkin Berteig at 01:10 PM | |

March 08, 2006

How to Deal with Repeating Tasks? A Question for the Audience

Most agile projects that I have worked on have had very little repetition in them. Each day brings new work, new problems. Each iteration is working on something different. So what happens if there are tasks that repeat? What if you have to do the same thing every day or every week or every iteration? How does this fit in with agile work methods?

In some agile methods, there are certain things that are already repetitive such as the iteration planning meeting, the daily status meeting and the retrospective. These things are process overhead. As overhead goes, they're not too bad! Agile methods usually treat them as a special kind of work: they are not work that shows up in the work item backlog nor in the task backlog for an iteration.

In our lives we have to deal with many repetitive tasks: cleaning the fish tank, mowing the lawn, renewing our vehicles license plates, brushing our teeth. Many of these things are "just there": you know you have to do them, you do them and you don't bother tracking how much time they take, nor specifically scheduling them.

In Agile Work, with one of the disciplines being to "Eliminate Waste", there is some tension between our normal approach to repetitive tasks and the high-visibility approach of agile.

We could put all our repetitive tasks on the backlog. For example, if we have a weekly status meeting to report on progress to management, this could be put on the backlog. The problem is, that the meeting doesn't provide any value to the organization and the backlog is really meant for valuable items.

We could have a separate mechanism for tracking repetitive tasks. This might be a calendar, it might be a per-iteration checklist.

We could find ways to automate or eliminate the repetitive tasks. This works very well in an IT environment or in an environment where machines could do the work. But it can't work for repetitive communication tasks where the details are constantly changing.

We could leave them essentially invisible...

I'm curious though: have any of you been on projects where you have had to explicitly deal with this? What did you do? Did you distinguish between value-added and non-value-added repetitive tasks and if so, how?

Posted by Mishkin Berteig at 05:32 PM | |

March 02, 2006

Five Signs of Trouble in an Iteration

During the course of an iteration, an agile team is able to track it's own progress through the use of burndown charts. The team and the process facilitator can use the burndown chart to watch for signs of trouble. As a coach, I find the following five burndown shapes are common indicators of trouble.

But let's first show the idealized "normal" burndown. This burndown shape shows that the team is on-track to get to done exactly at the end of the iteration. The work remaining has had a constant slope down through the course of the iteration.

Now the warning signs:

1. Too Much Work

In this burndown, the team sees that it has likely selected too much work for the iteration. The process facilitator and the product owner need to work with the team to decide how to change the scope so that the team can get done. One might be tempted to add people to the team to get the work done faster, but this is rarely successful.

2. Not Getting Done

Frequently, when a team is just starting out with agile work, it commits to slightly too much work. It is hard to detect this at the beginning of an iteration. Instead, it is only near the end of the iteration that it becomes apparent that the team isn't quite going to make it to done. The process facilitator must work with the team to determine the root causes of this and change things so it doesn't happen again.

3. Early Learning

When a team is starting the iteration, it can discover new things about the work it has committed to accomplishing. This can include dependencies, new tasks, extra components that need to be built, etc. This discovery process is normal, but needs to be monitored closely. If the burndown doesn't start going down again after about 15% of the iteration is over, then there is likely trouble brewing.

4. Unresolved Obstacles

Sometimes the team will run into an obstacle that will completely stop their progress. Although the process facilitator is responsible for dealing with obstacles, it may be impossible for an obstacle to be fixed quickly. If the team finds that all the work it committed to for the iteration is dependent on someone who is sick or on vacation, that can lead to an unresolvable dead halt. This may be an opportunity to cancel the iteration.

One interesting example of this was observed by a coach I work with frequently, Deborah Hartmann. She was away from her team for a few days and when she came back, she observed this "flatline" burndown. After poking around a little bit to try and find the obstacle, someone finally described what had happened. At the time of the flatline, a Vice President in the organization had come into the team's area, looked around, and loudly declared something to the effect of, "I don't know why you guys are doing this project. It's totally worthless!" Suffice it to say that the team was seriously demoralized. It wasn't a technical obstacle, it wasn't a procedural or bureaucratic obstacle, it wasn't even a cultural obstacle. It was just a serious blow to morale. Of course, to fix this, the actual sponsor of the project had to be brought in to assure the team that it was actually an important project and that there were people in the organization who needed the work that the team was doing.

5. Scope Creep

This last case is rarer for an agile team if the team and the product owner have been educated well about the rules. Nevertheless, it can happen. The product owner, or some other stakeholder, pushes the team to add scope to the iteration. The process facilitator is normally responsible for preventing this from happening. If despite this it does happen, the burndown chart makes the consequences of this scope creep.

---

Special Quiz Section!!!

What are the possible explanations for the following burndown shape? I have heard/experienced at least six different possible reasons. Leave your answers in the comments.

---

Update: at Agile Chronicles, there is a short article about this topic which mentions one more burndown chart pattern that is a bad sign: the "Late-Breaking Decline".

Posted by Mishkin Berteig at 01:34 PM | |

February 19, 2006

Three Concepts for Value Stream Mapping

One of the first tools to use when looking at process improvements for any type of work is a value stream map. This tool can usually be used to find substantial and immediate improvements to process efficiency even before considering any Agile Work practices. There are only a few basic concepts to understand before jumping in...

Value Stream Mapping Basic Concept One: Touch Time and Cycle Time

Touch time is the amount of time people actually spend working on a task: building, thinking, breaking, writing etc. but excluding the time they break for coffee, writing emails, waiting for answers to questions etc. Cycle time is the overall time people are working on a task from the moment they take responsibility for that task to the moment they hand off their results and no longer have responsibility.

Value Stream Mapping Basic Concept Two: Value Added and Non Value Added

Value added tasks are those that actually add value to the end result. The opposite, non value added, is also known as muda or waste.

Value Stream Mapping Basic Concept Three: Be Brutal, Be Conservative

Be brutal and conservative when deciding the touch time vs. cycle time for an activity or when trying to decide if an activity is value added or not. Typically an organization starts out with about 80% of all of their processes being waste of various sorts. Look at your value stream map and try to classify about 80% of it as non value added or cycle time overhead.

Value Stream Mapping Process Step Template

Here is a nicely formatted template you can use for tracking your tasks in a value stream map in three formats:

---

OpenOffice.org
Value Stream Map Process Step Template

---

Microsoft Excel
Value Stream Map Process Step Template

---

Adobe PDF
Value Stream Map Process Step Template

Posted by Mishkin Berteig at 08:56 PM | |

February 17, 2006

Timeboxing: A Critical Agile Work Practice

When you think of the show "Saturday Night Live", you probably think of things like "funny" or "stars". You probably don't think that this show epitomizes the idea of timeboxing.

A timebox is a fixed amount of hours or days in which to accomplish something. Iterations are timeboxes. When you say to yourself on a trip: "let's see how far I can go in 8 hours of driving", you are giving yourself a timebox. When you write an exam in school, you might have a three hour timebox. For complex work, timeboxing is a way of limiting the amount of time on something in order to prevent excessive effort or spending. As a weekly show, Saturday Night Live does this to a "T" (Thanks to Alex Sirota of Newpath Consulting for pointing this blurb out to me!):

To go from blank page to a live, 90-minute telecast every week, the process begins with a Monday afternoon meeting in Michaels' office, where writers and performers meet the week's guest host. Ideas are batted around, and the material that seems funniest is developed at writers' keyboards over the next few days. On Tuesday and Wednesday, writers refine ideas, often with little or no sleep, and as the host grows accustomed to the anarchy his/her opinions and ideas are given more consideration. By Wednesday afternoon's meeting, the writers may have as many as fifty sketches, perhaps 40 more than will actually air. Most will be rejected by Michaels or the host, and the few that remain may be rewritten. On Thursday, some skits go through a dry rehearsal, and by Friday all the skits are usually prepared, with sets and stage instructions.

Saturdays begin with a run-through that may be as long as two and a half hours, after which Michaels and the show's writers make "semi-final cuts." At 8:00 PM, there is a dress rehearsal in front of a live audience, and this show may be as long as an hour and fifty minutes, leaving up to twenty minutes of "final cuts", which are decided largely on the basis of what the audience seems to find funny. Then, at 11:30 Eastern Time -- live from New York, it's Saturday Night. (http://www.nndb.com/people/621/000024549/)

---

For the people involved in creating Saturday Night Live, there is a great deal riding on getting the show done on time. They have a slot and if for some reason they should fail to get ready in time, they would have a serious problem on their hands. This pressure is one of the main factors for timeboxing to work.

In other types of work, it may be necessary to artificially create the pressure to meet the timebox deadline. You can schedule demos, make public commitments or set in motion other work that will fail if you fail to meet your timebox.

It is also critical that your timebox be set to a good size: too small and you won't be able to get anything done, and too large and there will be no pressure to work until you are nearing your deadline. This is closely related to the horizon of predictability.

Posted by Mishkin Berteig at 01:18 AM | |

February 14, 2006

Daily Status Meeting Disfunction

There are many ways that the daily status meeting for self-organizing teams can be done incorrectly. One of the most common, particularly early in a team's adoption of Agile, is that people report to the Process Facilitator. Why is this bad?

The daily status meeting is meant to be an opportunity for the team members to report to the team on their progress and obstacles. If the team members are reporting to the Process Facilitator (or the Product Owner, or the project manager or the executive who just happens to join the meeting) then those people are going to change what they report and how they feel about the meeting. It will no longer be as open, nor as useful to the other team members.

Although this might seem like a subtle point, it is actually quite critical to the overall effectiveness of the team. A team which is seeking approval from leadership or management will not be nearly as focused on success as the appearance of success. There will be a tendency to report work done even if it isn't really, to minimize obstacles and impediments, and to look for assignment of work from the manager/Process Facilitator/team lead.

In order to overcome this disfunction, the Process Facilitator may have to make some changes to the meeting: make it closed to observers, start the meeting every day by encouraging people to report to their teammates, move the meeting to be around the task board for the iteration. It may even be necessary for the Process Facilitator to do odd things like standing behind the person who is currently reporting so that that person does not look at the Process Facilitator.

More details about the Daily Scrum from the Scrum methodology.

Posted by Mishkin Berteig at 05:35 PM | |

January 25, 2006

The Pros and Cons of Short Iterations

My first experience with any process that was similar to an Agile approach was in a startup ten years ago. We did 3-day-long iterations on a software project with a three person development team. That experience, followed by its antithesis, shaped the rest of my life. And yet, short iterations aren't always the best way to go.

A short iteration length for a given type of work will depend on the horizon of predictability for that work. In software development, anything five working days or less could be considered short. In daily newspaper publishing, fifteen minutes or less could be considered short. As a rule of thumb, "short" simply means that it is possible to fit two or more iterations in the length of the horizon of predictability.

Pros of Short Iterations

- deliver work fast: the first potentially shippable features are available after only a very small amount of time
- people keep focused on the goal(s) for the iteration; there is no chance to get distracted
- very tight learning feedback loop allows for quick discovery of optimal solutions

Cons of Short Iterations

- intensity of work can lead to burnout
- strategic thinking can be hard to fit into the "schedule"
- overhead tasks that must be done every iteration take a larger proportion of the time in the iteration
- waiting for resources or people outside of the team can make it more likely for work to span iterations

Guidelines: Choosing Iteration Length

1. Start by understanding the horizon of predictability in your environment. This is the maximum length for your iterations. In most IT organizations, this is somewhere around four weeks, whereas in web environments, it is usually much shorter.
2. Consider your constraints for delivering potentially shippable work units. Also consider the team size and the communication overhead that results. These two factors can guide you to determine a minimum iteration length. Identifiable overhead should not account for more than 25% of your time.
3. At the start of a work effort with a team new to Agile Work, consider erring towards shorter iterations. Shorter iterations can shock people into discarding bad habits by changing people's mental model of how to work effectively. Teams with successful agile experience may consider longer iterations.
4. Consider your ability to automate overhead work tasks and testing tasks. If you can develop a highly automated environment, shorter iterations are possible. If on the other hand, manual efforts will be required (no pun intended), consider a longer iteration length.
5. Consider the overall amount of schedule/funding. For a team to learn the domain and stabilize their velocity, consider trying to fit eight or more iterations into the overall schedule. The first three our four iterations include a lot of learning about the team, the process and the domain.

Some people recommend other methods of choosing the length of your iterations: How Long is a Timebox.

What We Did Way Back When...

The three day iteration length was largely determined by how frequently the sales folks could bring in potential customers for a demo. Every time we demoed, we were using working software. We would do a fairly complete walkthrough of the software and gather feedback. We would balance the feedback with outstanding features and make a call about what to add/change over the course of the next iteration. This constant involvement of customers and the requirement to have always-working software set my expectations for software development in a way that my experience up to that point had not even hinted at. When I went to my next job (which was at Sun Microsystems), I was appalled by the long cycle time to produce working software and the almost complete lack of customer involvement in the process. I vowed never to work that way again...

... and became a consultant and an agilist :-)

Posted by Mishkin Berteig at 01:39 AM | |

December 15, 2005

What Happens When a Team Doesn't "Get to Done" in an Iteration?

At the start of the iteration, a team commits to a goal and a certain amount of work. Burndown charts help a team to monitor their own progress against that goal. The team works together in a room with a process facilitator and product owner. Everthing seems to be okay, and yet, the team doesn't fulfill its commitment. What to do?

How Bad is This?

If the team is just adopting Agile Work methods, is a new team, and is on a new project, then this problem is common and to be expected as an early part of the team's learning. In other circumstances, this is a disfunction.

The severity varies greatly, but the worst thing that can happen is that the team gets in the habit of doing this regularly and therefore starts to believe that it is okay. It is not okay. One of the most important aspects of Agile Work is the closure of work completed at the end of the iteration.

This closure has all sorts of benefits: a feeling of accomplishment for the team, delivery of real value to the customer on a regular basis, better capacity planning based on actually completed work history, and accurate feedback from the customer on a regular basis. If the work is not completed, none of these benefits are possible.

Planning Failure

One way the team fails to get to done is simply through poor estimation and planning. There are several key practices to use in agile planning: tracking velocity, tracking availability, estimating work and iteration planning. In order to correct this type of failure, try the following simple iteration planning steps:

1. At the beginning of an iteration, the team records it's "velocity" for the previous iteration. This number is equal to the beginning estimated size of work for the iteration plus the original estimated size of any work added during the iteration minus any work left over. The team may also wish to record exactly how many person-days were worked in the previous iteration based on when people were sick, on vacation, in training, left the team or joined the team. (If it is your first iteration, you may want to use drag factors - the subject of a future article - or the team may just take a wild guess as to its velocity.)

2. The team then collaborates to put an estimate on each piece of work to be done. There are several systems for doing estimates including "Story Points", "Ideal Hours/Days", or "Ping-pong Balls". Sum these estimates up into a total proposed work size for the iteration. If the team determined person-days worked in the previous iteration, then estimate person-days available in this iteration taking into account the same factors.

3. If the estimated work to be done is greater than the team's velocity for the previous iteration (and optionally factoring in the ratio of person-days worked/available) then remove the lowest priority scope from the iteration until the estimated work to be done fits the team's capacity.

Obstacle Removal Failure

Sometimes a team will be unable to complete the work of the iteration due to an obstacle that was not cleared. Possibly the obstacle was not identified or only identified very late in the iteration. Possibly the Process Facilitator was irresponsible or incapable of removing the obstacle for the team. Or possibly the organization around the team was unable to remove the obstacle or forbade its removal.

The team must be certain of the nature of the obstacle. A brief pull-up or more in-depth retrospective may be necessary and thinking tools such as the "Five Whys" may be useful. Once the obstacle and its nature are understood, its consequences must be fully exposed to all members of the team and all stakeholders. In the full light of the obstacle's nature and consequences, the team and stakeholders can decide what to do: remove the obstacle, mitigate its effects, or live with it. Choosing to live with an obstacle should be seen as a last resort and even in this case resolving the obstacle should be put on the work item list to be revisited sometime down the road.

Regardless of the status of the obstacle, the team must adjust its planning for the remainder of the iteration or the next iteration in order to take into account how it was dealt with.

Failure to Abort the Iteration

Sometimes information comes to light that invalidates the work of the team for the iteration. The Process Facilitator, the team and the Product Owner must collaborate to decide if the iteration should be aborted early. If this new information is ignored for any reason, then a team may continue working on the iteration but not get to done.

Aborting an iteration is a healthy thing to do and is a legitimate part of being agile. It should not be considered a failure. Aborting the iteration can be a powerful means of communication and re-planning. It is meant to be done rarely and it is designed to send a strong message.

Posted by Mishkin Berteig at 03:30 PM | |

December 08, 2005

Essential Advice for Agile Coaches

As coaches, we have a great deal of responsibility. Through our words and actions we lead and guide our teams and apprentices as they encounter the new way of working that Agile requires. We are responsible for their success as well as the success of the endeavor they are working on. How can we ensure we are doing everything in our power to live up to this responsibility?

Pairing Spend time sitting with team members to learn what they are doing and appreciate their work. Maybe even find ways to help them out. This time will help you develop a personal connection with each team member. Doing this will also help you become attuned to the non-obvious obstacles that impede the team's progress.

Service Don't let anything get in your way of serving the team. Meetings, training, and other things can easily become excuses not to do the hard work of service. Make sure that you aren't sacrificing the team's well-being for your own.

Team Building Keep thinking about and encouraging team building exercises. Little things can often make a big impact. You don't need a full-day wilderness off-site to get a team to work well together. There is a huge difference between a bunch of individuals working towards the same goal vs. a team which is "in the zone" of super-productivity. As a coach, getting the time to spend as much time in this state of flow is your primary objective.

Experiment Aggressively experiment with new ways of doing things and encourage the team to do so as well. Every experiment that fails is just as important to improving as every experiment that succeeds. If every individual is experimenting with ways to improve their own work, then we can trust an evolutionary process to take place where better and better improvements are constantly being found.

Personal Development Constantly strive to develop personally in terms of behavior, knowledge, thought, and morals so that you can lead by example. "Truthfulness is the foundation of all human virtues" and so it is a good place to start. This personal development may require getting your own coach or even a therapist. Your own barriers to improvement can best be overcome with help from someone else.

Learning Actively seek new reading materials and research subjects that are related to agility. Expand your reading to organizational culture, community development, economics, the philosophy of science, sociology, as well as technical fields. This diversity of knowledge will allow you to see otherwise hidden opportunities.

Breakdowns Encourage little breakdowns to avoid the big ones... little ones are much easier to handle. Lots of little breakdowns can become opportunities for transformative learning, but letting them accumulate until they create a catastrophe usually just hurts. The small breakdowns are difficult enough.

---

That's a big list. I don't do all that perfectly, but that is the standard I am constantly striving towards. It is a standard of constant improvement, just like Agile Work itself.

Posted by Mishkin Berteig at 05:35 AM | |

December 06, 2005

Agile Work for "Flow Projects"

A "flow project" is a type of work where a team is working on many very similar, independent, small work items. This type of project is quite common in IT departments doing infrastructure work, maintenance work or support work. Agile Work practices can be applied to this type of project with just a little tweaking.

Self-Organizing Team

The basic principles of agile require that the team determine how it does its work without compulsion. One of the key mechanisms for this is the frequent reporting of individual status to the team. In a flow project, the normal three questions can become quite repetitive and so an emphasis should be made on elucidating obstacles. The process facilitator must be very aware of obstacles even if they are only implied. As well, a "stop the line" policy may be necessary to fully expose the urgency of obstacles. In this case, an individual declares a problem with the work item they are currently handling and everyone on the team stops to help until the problem is fully resolved. Strong medicine? Yes, but if you are working on several hundred or thousands of work items, this can lead to enourmous efficiencies as obstacles are removed, never to be seen again.

Iterative Delivery

Iterative delivery is normally used to take a very large piece of work (a project) and chunk it into consistently sized smaller pieces of work. This chunking is done in order to gain efficiencies that can be found by applying queueing theory. In a flow project, the work is already chunked into small and relatively consistently-sized work items. In fact, the work items are typically much smaller than "normal" iterations (1-4 weeks). This means that other aspects of queueing theory become more important, particularly the gating function and managing the queue sizes (more below). Iterations can still be useful, but now they are predominantly used as checkpoints for process improvement, and domain and technical knowledge-sharing. Releasing work completed may be done in a flow manner as each work item is completed.

Adaptive Planning

Adaptive planning, normally done between iterations, now takes on more importance and must be done continuously. The work must still be prioritized as with a normal agile project. However, as work flows through the team, work items are constantly being removed from the top of the work list. In some cases, a work item will have to be put through several stages before it is complete. Each stage must have its own queue of work items that are ready to go into that stage. The sizes of these queues of work must be managed so they never grow beyond a certain number of items. One way to manage this is to have individuals responsible for a work item from start to finish throught the process. However, due to specialization of skills or roles, this is sometimes difficult or impossible to do. Nevertheless, despite apparent inefficiencies, it is critical to manage the flow of work as a pull system.

Test-Driven Work

Also known as "build quality in"... If you need to go fast, one of the best ways is to never have errors or defects. And one of the best ways to do this is to create a test to ensure that your work is correct before actually doing the work. In a flow project, the conditions of success for each work item are often either the same or similar in a consistent manner. It is well worth it to invest a little time in developing an automated system to check the quality of work as the work is being done. In certain domains such as software and manufacturing, this is fairly easy to do with various tools. In other domains it can be more difficult. Nevertheless, get your team to investigate this problem and implement solutions even if they are only partial solutions. Having all of your work flow through your process without defects will prevent many occurances of the waste of rework.

Maximize Communication

The basic agile practice of maximizing communication applys almost without change to flow projects. Getting all of the team in the same room, having big visible charts to show the status of work and other tools to maximize communication are all important. In order to stop the line when an obstacle is found, it is necessary that everyone on the team is immediatly aware that they are to stop! If everyone is supposed to work intensly on removing an obstacle when the line is stopped, then they all need to be in close collaboration. Team-building techniques that encourage friendships, dealing with conflict, respect, and collaboration are all critical to going fast with a flow project.

Appropriate Metrics

In an agile project, the delivery of valuable results is the most important thing to be measured. However, in flow projects, an additional measurement is often very useful: Process Cycle Time. Reward the team for reducing cycle time while keeping quality constant or improving quality. This is one of the best ways to encourage creative methods of getting work done in a flow project.

---

Agile Work Axioms and Disciplines

The three Agile Work Axioms and Disciplines all apply to flow projects just as much as to "normal" agile projects. The only change is in their emphasis and target. For example, "We are Creators", now applies much more to the problem-solving aspect of trying to make the overall work go as quickly as possible. One goal of a flow project should be to automate as much of the work as possible. This automation work is definitely a creative endeavor even if the work itself doesn't offer much room for creativity.

Posted by Mishkin Berteig at 02:52 PM | |

More on Daily Status for Self-Organizing Teams

It's a little old, but I just found and read Rachel Davies article about variations on the daily standup. Personally, I like the extremely simple three questions defined in standard Scrum, but I can certainly understand that there might be circumstances where those are insufficient.

Note: I've added new sections to the recommended links page. The sections come from the Agile Work Cheat Sheet. The above article about daily standups is included in the Self-Organizing Team section.

Posted by Mishkin Berteig at 07:25 AM | |

November 11, 2005

Agile Planning

I recently read a great little article about agile planning by Martin Fowler. I find that one of the more difficult tasks to do early on in an Agile project is to get the team to as a whole, take responsibility for the amount of work taken into an iteration. Often, individuals will take on work that is role-specific (e.g. Dev work) without consulting the whole cross-functional team and the product owner.

I haven't read it yet, but I suspect that Mike Cohn's new book, Agile Estimating and Planning, might have some excellent ideas about all this.

Posted by Mishkin Berteig at 08:54 AM | |

November 10, 2005

Agile and Defined Processes

People who are organizationally minded, or who are risk adverse often have difficulty understanding the benefits and safety afforded by Agile as opposed to defined processes. This often manifests in a desire to standardize tools or processes so they become defined.

For example: an organization may wish to standardize on a spreadsheet template to use for iteration backlogs for all Agile teams. This seems innocuous. While I understand the desire to standardize, I believe even doing this would be detrimental to an organization. Some Agile teams may not use spreadsheets at all. In fact, using spreadsheets is considered a last resort used only if you have an extremely complex project. Generally speaking, user story and task cards along with a burndown on a white board are meant to be sufficient. Standardizing on spreadsheets would _impose_ process where it is not necessary and would be taking us all back along the path of a non-agile approach to projects.

In one instance where I have coached, we did in fact use a spreadsheet because we have up to 300 tasks per team per two week iteration. It would have been very difficult to manage all these tasks manually. Additionally, we customized our spreadsheet to work for our circumstances which are unique. Agile specifically encourages the values of simplicity and adaptability. I am perfectly happy to share our spreadsheet for other people to learn from, but the whole notion of standardizing the spreadsheets seems to be against agile principles. Think of it this way: would anyone be happy if an organization decided that everyone needed to drive the same car to work? Each person's car serves their own transportation needs. In exactly the same way, each team's spreadsheet/whiteboard/cards serves their needs… and not necessarily the needs of anyone else. It is true that everyone needs transportation, and in the same way an organization needs every team to track their user stories and tasks, but how exactly it is done should be left up to the teams.

Posted by Mishkin Berteig at 02:35 PM | |

November 08, 2005

Retrospectives

First, a link: Retrospectives.com. From the site, the Retrospective Prime Directive:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

Today I assisted a fellow-coach, Deborah Hartmann with a retrospective for a team that she is coaching. Deb is actually coaching two teams in a program and couldn't be with them both at the same time. She introduced me to a very simple yet pleasant and effective method for retrospectives. I am not sure of its ultimate source, but it was introduced to Deb by Michael Spayd. Here is the basic outline:

Materials: pad of largish PostIt notes, large pad of poster-size paper, marker, pens for everyone

Set up in a space where everyone can see each other and the poster pad.

Step One: get everyone's attention, organize around the table, turn off laptops, put cell phones on buzz, and state ground rules: no interrupting each other, and that this is not a discussion until you (the facilitator) say so
Step Two: display and recite the cardinal rule (above) and the purpose of the retrospective
Step Three: What Went Well?
- everyone takes three PostIts
- write down on the PostIts what went well (technical, team, organizational, process, general or specific)
- facilitator puts them on the poster in a way that they are not visible to the group
- facilitator reads them all out in random order with no comments
- facilitator gets the group to brainstorm (no criticism) on themes of what went well and writes them down for all to see
Step Four: What Needs Improvement?
- repeat Step Three
- vote on the importance of the themes and chose the three most important to discuss
- facilitate discussion to generate action items for making improvements based on the three most important themes

Posted by Mishkin Berteig at 07:36 PM | |

November 02, 2005

Iteration Progress Information Radiators

A fellow agile coach pointed me to this great little article about burndown/up charts. It has some nice drawings of alternatives to the basic simple burndown that most teams start with.

These alternative forms of burndown attempt to provide more information about the status and history of an iteration basically by providing a means to update the "baseline" estimates. The advantage of doing this is that it allows for easier discussion of when and why new work was discovered. As well, it maintains the existing advantage of a burndown with its clear focus on getting to done by the end of the iteration.

Posted by Mishkin Berteig at 01:03 PM | |

October 11, 2005

Is There a Single "Most Important" Agile Work Practice?

There are a few times that I have been involved with implementing agile pratices without management knowledge or direct support. In these cases it has usually been necessary to gradually introduce the practices. An unsupportive or apathetic environment cannot be changed instantly and big-bang introduction of agile tends to bring too much negative attention too quickly.

In reflecting on those experiences, as well as "normal" agile implementations, I have felt that there are some specific practices that can stand alone.

Self-Organizing Teams

The practice of a self-organizing team consists of frequent regular status meetings, face-to-face, reporting to the other team members accomplishments, work commitments and obstacles. Scrum has a very strict method of doing this on a daily basis but I have found it valuable to do more or less frequently depending on the team and its environment (generally any less than every second day is not enough). The team, or some assistant of some sort, tracks the barriers and works to resolve them quickly. Management, if it exists, must be contacted through trusted channels to assist with the removal of barriers. And stakeholders must be able to attend the status meetings or receive reports immediately after the meetings.

This single practice tends to have the ability to bootstrap the others. The identification and clearing of barriers provides a way for the team to practice all three Agile Work Disciplines (Empower the Team, Amplify Learning, Eliminate Waste). Reporting accomplishments to the other team members Amplifies Learning. Committing to work is empowering.

Some teams have done only this single agile practice and seen great improvements in productivity, morale, and stakeholder satisfaction. However, there are some pitfalls that must be acknowledged and dealt with.

Pitfall: Speculative Work

The team can tend towards speculative work if there is no strong representative of the stakeholders. This does not always happen since most people are sincere in their desire to "make a difference". However, if as a team you adopt only this practice and find yourselves doing lots of "what-if?" or "wouldn't it be neet if..." or "what exactly is our purpose?" discussions, then you need to find some external stakeholder support for your effort.

Pitfall: Failing to Deliver

In many organizations, failure to deliver is an endemic problem and a self-organizing team will break through and start delivering. However, failure to deliver can also become a cultural mindset for an organization or group. A self-organizing team must maintain a goal (not a plan) for itself, and that goal must include delivering something valuable. Again, finding an external stakeholder to support the team's efforts can help to avoid this pitfall.

Pitfall: No Barriers

Sometimes a team will get into a habit where no new barriers are being exposed. This can often happen when the progress in the work becomes steady and is recognizably better than it was before. The team falls into a "local optimum". In this case, the team needs a fresh way to view their work. This can happen in a number of ways: a crisis, an external observer, or a change in environment among others.

...

Do you have experience with successful but incomplete agile implementations? I would love to hear of other experiences and opinions about this.

Posted by Mishkin Berteig at 02:42 PM | |

October 10, 2005

Agile, the Adult Educator and Ethical Considerations

A review of Tara J. Fenwick's “Limits of the Learning Organization: A Critical Look” (article found in Learning for life: Canadian readings in adult education).

This article is a critique of learning organization literature (as presented in the works of Peters, Senge, Watkins, Marsick, Argyris, Schon and others). I chose to do a review of it because learning organization literature can and does inform the work of Agile practitioners. The writer, Tara Fenwick, offers a critique of this literature as an academic and practitioner in the field of adult education. Even though the language and tone of the article is judgmental and at times affronting to the corporate trainer audience, it is never-the-less challenging and valuable because she raises interesting ethical questions that can serve as cautions against potential trends that can distort agile practice. I will summarize her argument in the some of the areas most relevant to Agile practice.

Fenwick's summary of the model of learning organization found in the literature, is an organization that: “creates continuous learning opportunities, promotes inquiry and dialog, encourages collaboration and team learning, establishes systems to capture and share learning, empowers people toward collective vision and connects the organization to its environment.”

The following is a summary list of some of Fenwick's critiques:

Who's Interests are Served
Although the learning organization literature holds great promise for a more humanitarian and egalitarian workplace, it has the potential to distort learning “into a tool for competitive advantage” and in turn, exploit people as resources in the pursuit of profit. To explore this idea she asks a valuable question: “Who's interests are being served by the concept of learning organization, and what relations of power does it help to secure?” She argues that learning organization literature tends to serve the interests of educators working as trainers in organizations and managers interested in their own self preservation.

How Learning is Defined
Learning, in learning organization literature seems to be defined as that which benefits the organization, all other learning falls into the dysfunctional category. This perspective negates other ways that people create meaning and learn and potentially causes a person to become “alienated from their own meaning and block flourishing of this learning into something to benefit the community.”

Assumptions about Learners
The learning organization literature subordinates employees by seeing them as “undifferentiated learners-in-deficit”. Educators and managers are the architects of the learning organization while employees are busy “learning more, learning better and faster” trying to correct their knowledge deficit. In the learning organization workers become responsible for the health of the organization without the authority to determine alternative ways to reach that health. The fear of being left behind in a quickly changing market environment is used to create anxiety and fear as motivations for learning. All of these factors serve to put serious limits on the potential of people to learn in the work environment.

Diversity and Privilege Overlooked
Perspectives of race, class and gender -which research has shown affects the way people learn and collaborate- are lacking in the literature. Fenwick challenges the notion of achieving a democratically ideal situation for open dialog -that the learning organization literature calls for- when all people in the work place do not “have equal opportunity to participate, reflect, and refute one another” (for example because of the status of ones job, character, gender, class, age etc.)

Fenwick sheds a clear light on where the good philosophies of the learning organization are found wanting. The Agile community can benefit from asking some of the same ethical questions she asks in relation to our work. Her critique is a good challenge for Agile practitioners. It challenges us to:

• Continue to strive for higher levels of ethical excellence in our work
• To consider issues of power in our work
• To become conscious of how we use our own power
• To give thought to what voices are included / excluded in the creation of the learning organization
• Pay attention to how we motivate learners
• How to foster collaborative environments that are conscious of the privileging of some over others
• Think about who decides what is valuable knowledge and learning and how that affects the knowledge creation process

Reflecting on these issues will go a long way to contributing to the development of agile practice.

The full text of an old version of Fenwick's article can be found here.

Posted by Shabnam Tashakour at 09:35 PM | |

October 07, 2005

Agile Coach/Mentor Job Description (Process Facilitator)

Given the Agile Axioms and Disciplines then an agile coach or mentor should have some really specific experience and capabilities. This list constitutes a first attempt at a job description.

Experience:
- working in strictly timeboxed iterations with adaptive planning using some sort of prioritized work list
- working in a "test-driven" manner (e.g. writing a document for a client where the client specifies acceptance criteria)
- participating in frequent status meetings where the team members report to each other, commit to work and identify barriers
- building and maintaining big visible charts to show progress and status (e.g. the standard thermometer chart to show progress towards a numerical goal)
- fashioning appropriate tracking and performance metrics that encourage team work rather than individual competition
- helping other people to adopt and adapt all these practices

Capabilities:
- promoting collaboration in challenging circumstances
- searching for truth/a solution relentlessly
- honesty and trustworthiness
- a learning attitude (proactive and learning from mistakes)
- humility and assertiveness
- guiding people without controlling them
- detachment (ability to step out of a situation)
- an attitude of service without expecting recompense
- understanding of transformative learning
- conflict resolution as learning (not negotiation)
- encouraging creativity

Not Required:- technical experience related to the work of the team - the Agile Coach (process facilitator) should not be a performer on the team
- domain experience related to the goal of the work - the Agile Coach should not be a direct stakeholder in the results of the work

However, technical experience and domain experience can sometimes help...

Suggestions and ideas are greatly appreciated!

Posted by Mishkin Berteig at 12:33 PM | |

October 05, 2005

The Process Facilitator Role - Can it be Part-Time?

Victor Szalvay recently made a fabulous argument for the role of Process Facilitator to be a full-time role held by a single person for a team. His article, The False Efficiency of Task Splitting, uses terminology from Scrum (e.g. ScrumMaster or SM = Process Facilitator), but applies to any circumstance.

Posted by Mishkin Berteig at 02:09 PM | |

September 27, 2005

Tools Versus Capabilities Approach To Agile Training

Which approach is most valuable in training that fosters collaborative work for the purpose of optimizing the performance of an organization: a tools / methodologies approach or an inner capabilities approach? The typical orientation that most organizations take is often external and rule-based. This consists of creating methodologies, rules, boundaries, systems and processes to enhance collaboration.

These external approaches ultimately fail to have a lasting effect on people and the culture of the organization because they don't address change at the level of habits of mind. People then work in the new structure with the same patterns of behaviour. Behind this kind of surface approach to change are assumptions about human nature. At worst this consists of a belief that people are base (greedy, selfish etc.) by nature. At best that people are fundamentally good but cannot improve except through external measures. It is true that we need external systems and structures to give expression to our inner capabilities, to test, foster and develop them in action. However all the investment that companies make in tools, systems, methodologies are obviously not enough. We need both external and internal approaches to training people in collaborative processes. Systems and tools provide only a framework that then need to be filled in with character. At the core of Agile there are disciplines (such as Empower the Team, Amplifly Learning) without which the methodologies would have no life. The practice of the disciplines fostered by the development of inner capabilities infuses life into the Agile methods and at the same time the methods act on and reinforce the inner practice of the disciplines.

As Agile champions (coaches, facilitators, practitioners) we must invest energy on fostering -through modelling and coaching- the development of inner capabilities. The Agile community will benefit from an identification of core capabilities required and a deep exploration of how to foster their development in individuals, teams and organizations.

Although it is our nature to organize in groups and we may have much experience with collaboration, we nevertheless live in a culture of contest and individualism. Out of this culture comes a set of belief systems which are so deeply rooted in our lives that we are not fully conscious of them and their affect on us. These belief systems cannot change easily through the introduction of external structures alone.

Posted by Shabnam Tashakour at 12:44 PM | |

September 26, 2005

Wideband Delphi Estimation Technique

Here's an excellent introductory article on the wideband delphi estimation technique. Typically wideband delphi is used to estimate software development efforts, but can be used in almost any domain of work. This method might be applied to estimating effort for items in a work list at either a project level or tasks in an iteration work list. The way it is described, it sounds fairly heavy-weight, potentially taking several hours for a relatively small list of work items. However, it is worthwhile for process facilitators and product owners to be aware of these sorts of methods if problems with estimating occur in a project team. The wideband delphi model is related to the Delphi method.

[Update 2007/05/24]

Agile Work and Scrum use a very different method of estimating work that has one very important and incredible property: people don't have to get better at estimating for them to get better at committing to work!

The basic idea can be thought of as "commitment velocity". The method here is to use an arbitrary unit of effort that the team applies to estimating all tasks relative to each other. At the start of an iteration, the team can use any collaborative method (including wideband delphi) to come up with estimates for tasks. The team sums up the estimates for all the work of the iteration. Then, at the end of the iteration the team looks at the estimates for all the remaining undone work (if any) and subtracts that from the start of iteration sum. This is the Commitment Velocity. Now on their next iteration, they do their estimation work again, relative to the tasks in the previous iteration. If the sum of the estimates is larger than the Commitment Velocity, then the team needs to de-scope or find more efficient solutions to their work. This process usually converges after only three iterations (assuming: constant team composition, constant iteration length).

This method is taught in detail in my Agile Project Management courses, and there is a little bit more information here: Planning vs. Commitment. The agile estimation method of Commitment Velocity is an application of the Central Limit Theorem from statistics.

[Update: 2007/09/11]

Wikipedia now has an article on Wideband Delphi. The article points out some interesting potential problems with the wideband delphi method including corruption of the group doing the estimation and suppression of minority opinions. I know that in my experience as a coach, I have seen numerous occasions of both types of problem with estimation processes. The fact that wideband delphi is susceptible to these problems is more a factor of the human side of things than the method itself.

Interestingly, the wideband delphi method of estimation is very similar to the "Planning Poker" method of estimation used in many agile and scrum project environments. This method is also covered in the Agile Project Management courses.

Other links to wideband delphi:

Wideband Delphi Estimation Process

The ProjectInitiation.com website has a wideband delphi worksheet (MS Word) available.

Project Estimation: Wideband Delphi

Posted by Mishkin Berteig at 12:40 AM | |

September 06, 2005

Process Facilitator Role

I've been thinking a lot about the roles on Agile Work projects. Here is a possible "mission statement" or definition for the Process Facilitator:

The Process Facilitator is a person who is both experienced with Agile Work and trained as a facilitator. The Process Facilitator acts as a coach to the team to monitor the process, foster the understanding of the Agile Work Axioms, the development of the Agile Work Disciplines and adherence to the Agile Work practices. The goal of the Process Facilitator is to assist a team to become "performing" so that they are able to actively and independently persue continuous learning and improvement.

Also Known As: Scrum Master, Coach, and previously referred to as the "Process Owner"

Never Spread Your Facilitator Butter too Thin

Posted by Mishkin Berteig at 12:27 AM | |

August 25, 2005

The Role of the Process Owner

The following is an edited version of a post to the Scrum Development Yahoo! group made by Dave Barrett (CSM) (used by permission):

The ScrumMaster (Process Owner) role itself doesn't automatically imply any degree of authority, although at times it does help when you need a little clout to clear some impediments or to negotiate with other departments. More than that, the ScrumMaster role does carry a responsibility to provide some leadership to the team. Even a self-organizing team needs leadership!

So I would say that it helps if the ScrumMaster has a little bit of
seniority over the rest of the team, it also helps if the ScrumMaster
approaches the role as a coach and leader, rather than as a supervisor.

On paper it looks like the ScrumMaster only has a few tasks:

1. Chair the Scrums, and make sure they happen each day. (The self-organizing team's regular status meetings.)
2. Chair the Sprint (Iteration) Review and Planning meetings.
3. Produce the burndown chart. (An information radiator used to indicate the amount of work left in the product work item list and in the iteration work item list.)
4. Do the team's "paperwork" - publish the Sprint Backlog (product work item list) once it has been set and so on.
5. Clear impediments brought up during the Scrums.

In reality, the ScumMaster needs to do a lot of other things. There's all of the leadership stuff, keep the team happy, productive and motivated. There's the political aspect, keeping other groups and
departments happy and out of the team's hair. As the in-house "expert" on Scrum, you need to referee on points of procedure and theory. Often you need to champion Scrum within the organization.

Really, I don't see a huge difference between the roles of Project Manager and Scrum Master. Semantics mostly. Project Manager almost seems to imply a "command and control" approach, Scrum thrives best
without that. I wouldn't make a junior programmer a project manager, nor would I make him a Scrum Master.

Posted by Mishkin Berteig at 09:32 AM | |

August 23, 2005

Agile Offshoring References

Many people are trying out Agile Work in software development. The current industry climate is one that has focused business stakeholders' attentions on re-examining their core priorities. Where Agile optimizes on "Time to market", the offshoring "over-the-wall" approach to software development seeks to optimize on raw dollar cost.

What do you do if your organization is attempting both? There are some good resources on-line about this already, however I have yet to see good case-studies with published figures. Also, much of what's out there comes in the form of mini-articles that are no more than promotional ads for X proprietary "agile-offshore" solution. Regardless, some of the following may help avoid the worst problems of integrating two quite different approaches.

• Using an Agile Software Process with Offshore Development: by Martin Fowler
  
• A look at Valtech's approachfrom within the project. This calls itself a case-study, but no metrics are provided
  
• The sad and understandable ruminations of Jonathan Nolen on his blog, regarding Agile offshoring and his expectations of the project. These attitudes and cocerns are quite common - this is a good poster for the kind of feeling you might find from developers.
  
• Vincent Massol's presentation to Javapolis. No proofs or metrics, though some lessons learned are provided.
  
• A forrester research article on Agile Outsourcing. Note: this is only the abstract - the article is $350. (I should ask for a commission. :)
  
• Some practical advice on agile offshoring from a Thoughtworks fellow.
  
• Good points about customer proxies that are very applicable to offshoring with agile
  
• A very good summary of an ongoing conversation about fixed-bid contracts and Agile. It relates to the agile-offshore issue given that often projects are offshoring because of cost-sensitivity, and are thus fixed-bid.
  
• A look at criteria for choosing offshore partners based on Agile business readiness.
  
• Article by Scott Ambler on agile outsourcing.
  

Posted by Christian Gruber at 03:47 PM | | | TrackBack

August 18, 2005

Using Agile Work Practices to Develop a Seminar

I've been working on developing a Agile Work Seminar to introduce teams to agile work. I'm using some Agile Work practices to develop it.

Iterative Delivery and Adaptive Planning

The seminar is going through drafts. Each draft will actually be delivered to a team. The first time through all the material was done at a small software consulting company five days ago. As a result of feedback from the people who participated, a revision will be made to the seminar... and then it will be delivered again (probably the next time will be in early September). This process allows me to refine the contents and presentation of the material.

Over time, I will be able to use Adaptive Planning to modify the contents and qualities of the seminar as circumstances change.

Test-Driven Work

I have set up criteria for the presentation in the form of an outline and learning objectives. The outline describes the major topics that must be directly covered such as the Agile Axioms or Corporate Culture. I have also set up "soft goals" such as that the seminar must include theory, history, practice and criticism of Agile Work. My first iteration met the outline tests, but did not meet the soft tests explicitly. The next version will.

Appropriate Metrics

This is an easy one: the success of this project will be its acceptance in the marketplace by having teams willing to pay the price for this seminar and then recommending it to others.

The Other Practices

Because this is essentially a one-man job, the other practices such as Self-Organizing Team and Maximize Communication are not as applicable.

Posted by Mishkin Berteig at 08:32 AM | |

August 11, 2005

Agile Work Roles

There are three simple roles in Agile Work. All other roles, titles, duties or responsibilities are not part of Agile Work.

The Process Facilitator is responsible for the process used by the team. Normally, the Process Facilitator role is held by a single person who does not have any other duties.
- Keeps the team on-track by gently reminding the team of the process rules, e.g. having a completed chunk of work at the end of the iteration
- Facilitates process improvements, usually by doing a process reflection between iterations
- Coaches and instructs the team and individuals on the Agile Work axioms, disciplines, practices and how to apply them
- Works closely with the Product Owner to ensure that the quality Work Item List is maintained
- Focus on the "Clear the Path" practice of removing obstacles

Here is a short statement on the Process Facilitator Role. And here is a Process Facilitator Job Description.

The Product Owner is responsible for working with stakeholders to develop the Work Item List and understanding, maintaining and prioritizing it. Normally, the Product Owner role is held by a single person who does not have any other duties.
- Responsible for working with the team when the team has questions about items in the Work Item List
- Makes on-demand/immediate decisions about priority and meaning of items in the Work Item List

Here is a short set of links and another description of the Product Owner Role.

The Team Members are responsible for organizing and executing the work they have committed to doing.
- Extend themselves beyond their field of specialization
- Volunteer for tasks to complete the work (no one on the team or outside the team assigns tasks)
- Responsible as a team for determining how to complete work and then completing it

This new set of roles, along with other agile practices and principles, often results in a huge shift in responsibility. Decision-making and accountability is transferred from managers to the team. This change can be very difficult for managers who are accustomed to direction, delegation, control. Instead, managers must become facilitators and enablers.

Posted by Mishkin Berteig at 10:03 PM | |

August 10, 2005

Optimizing a Team Room

Some less-obvious hints for creating a team room that promotes collaboration and effective communication.

- don't underestimate the importance of plants and natural light for overall morale and health
- encourage the team both individually and as a group to personalize the team space: kid's art, photos, trinkets, food, special chairs/ergonomic stuff
- encouraging a playful atmosphere if your group is quiet and shy is easier in a bullpen and this in turn leads to better morale
- encourage the team to notice traffic patterns (both physical and communication) and optimize the space to account for these patterns
- play games in the team room during lunch breaks or after-hours and have the results of the games as part of the visual environment

Posted by Mishkin Berteig at 03:13 PM | |

August 06, 2005

Generalizing Specialists

The term "generalizing specialists" has come to mean an individual who has a particular area of deep expertise but also has experience in a large number of other areas that may not be directly related to their core area. This type of person typically has strong talent in their specialty but also has a generally strong talent for learning new skills and ideas quickly. The origin of the term seems to be in the software industry referring to programmers who can do other software-development related tasks.

In self-organizing teams, a generalizing specialist is a more valuable team member than a pure specialist. The pure specialist often has an attitude that they should not need to do work outside their specialty. This can be destructive to the team's morale. On the other hand, the generalizing specialist is willing and able to learn new skills - to stretch as the needs of the team change. And since change is natural, this is an essential attitude for team members.

However, we are usually trained, and strongly encouraged to have a deep specialty. This approach to education and training is a natural consequence to the typical organizational model for work and society. Therefore, if a team is converting to agile work methods, people need to be coached to stretch themselves and learn new things. For some people, particularly those who already have multiple hobbies outside work, this is an easy transition to make. For others, it is a very difficult transition. In some extreme cases, this may call for the removal of someone from the team. (Note: I have never seen this myself and I only mention it with great reservation. I strongly feel that only those who could be called "ill" will be so incapable of changing their way of working. For other recalcitrants, it is usually a matter of motivation.)

Other terms that are similar to "generalizing specialist" include "craftsperson", "renaissance man", and "polymath".

Posted by Mishkin Berteig at 08:05 PM | |

August 04, 2005

Just In Case You Haven't Seen It Yet

There is a fantastic article about software productivity: http://www.joelonsoftware.com/articles/HighNotes.html. I love Joel's writing style, and this article in particular has important lessons for us all, regardless of our profession: find what you can be the best at, and do that. Interestingly enough this is part of the message of the book Good to Great but applied to a whole corporation. It also applies in the context of self-organizing teams: each individual should be able to find/learn in what way they can best contribute and do that more than they do other stuff.

Posted by Mishkin Berteig at 11:41 AM | |

August 01, 2005

Broadcast Mode Communication

The book "The Mythical Man-Month"* discusses some of the reasons that larger teams are inefficient. The main concern is with the number of possible connections between team members. If you have two team members, there's only one channel of communication. However, if you have n team members, then you have n(n-1)/2 channels... which grows quickly (order n^2) as n becomes larger. If one is required to work with a large team, say more than 10 to 12 people, it becomes imperative to find ways to improve communication efficiency.

One of the best ways to do this is to use broadcast mode communications. Information radiators are a simple broadcast mode tool. In a subtler way, having the team co-located** also takes advantage of broadcast mode communication: if everyone can overhear all the conversations that are going on in a room, then people can tune in when they hear something of relevance.

It is important to note that there are several other forms of broadcast communication that are useful in certain circumstances: e-mail, blogs with RSS or Atom feeds, analog radio, television (if you can think of others, please let me know in the comments). These tend to be more useful for very large communities. Radio and television have severe limits: they are not easily used in a communal fashion.

Some forms of communication may seem to be broadcast, but in fact are not. A simple web site is not because it requires that people poll it to see if it has been updated. Conference calls are marginally broadcast in that while they are occuring, everyone participating hears everyone else. However, a conference call requires active synchronized attention on the part of all the participants.

The subject of media and communication is a vast one. Some of the best writers include Marshall McLuhan and Gregory Bateson. However, there are many many more.

*Highly recommended!

**A search on dictionary.com for collocation indicates that three spellings are all correct: collocate, colocate, and co-locate, this latter spelling being the most common on the web.

Posted by Mishkin Berteig at 11:18 AM | |

July 30, 2005

A Simple Rule of Thumb

Make your product/service development lifecycle shorter than your horizon of predictability. For example, if you can't predict your competitive environment or your own capabilities outside of 4 months, then any new product/service should be initially launched at most 4 months from the time it is conceived. Once initial launch has occured, it is possible to examine the environment and make adjustments for an additional launch. One might call this experimental marketing. Ideas that just can't be accomplished inside of one's horizon of predictability should be considered very risky. In order to reduce this risk, these larger projects can either be broken up into smaller pieces, or efforts can be made to extend the horizon of predictability out further (this second task is extremely difficult).

Posted by Mishkin Berteig at 11:09 PM | |

July 28, 2005

Applicability Matrix Tool for Colocated Team

Notes:

1. Individuals are automatically co-located with themselves.

2. Teams can greatly increase the effectiveness and efficiency of their communication by working in a shared space. For rote and adaptive work, sharing a space is highly recommended, but not always essential. Some teams have found mechanisms for working effectively in a distributed fashion. In these circumstances a great deal of effort is put into frequent use of rich communication channels. In purely creative and innovative work, it is very difficult to do the work without co-location. Risks of misunderstandings or waste due to handoffs increase a great deal if co-location is not used in these circumstances.

3. In community work, co-location is difficult in general due to the large numbers of people involved. A “command centre” open to all members of the community is usually as close as it is possible to come to co-location. With rote work, it is not necessary to even attempt co-location. Adaptive and creative work benefit greatly by increased communication so some efforts to co-locate may be worth the effort, but care should be taken in determining the return on investment.

Posted by Mishkin Berteig at 11:46 PM | |

July 25, 2005

Applicability Matrix Tool for Iterative Delivery

Notes:

1. Iterative Delivery is a specific way of managing queues of work. As such, rote work is generally better served by other applications of queuing theory.

2. There is one universal condition under which iterative delivery is awkward, if not inadvisable. If one's horizon of predictability is longer than the size of a work package by some substantial amount (e.g. 2:1 ratio), it can be more natural to use queuing theory and a pull system to flow work through the team. The actual ratio between the horizon of predictability and work package size that is used to switch over to a queue system must be determined empirically in your own circumstances. This empirical analysis can be done using a regular process reflection meeting.

Posted by Mishkin Berteig at 03:14 PM | |

July 23, 2005

Book Review - "The Tipping Point"

Overview

The Tipping Point: How Little Things Can Make a Big Difference is a book that is about the way ideas, things and behaviors go from obscurity to ubiquity in a very short period. The basic model is that of an epidemic in which three types of factors contribute to quick dissemination: 1) the network of people involved including "connectors", "mavens" or respected experts, and "salesmen", 2) the ability of that which is spreading to stick around, the "stickiness factor", and 3) the importance of small physical, mental and social factors, in creating a conducive environment. The Author, Malcolm Gladwell, includes some excerpts on his web site.

• Introduction
• One: The Three Rules of Epidemics
• Two: The Law of the Few: Connectors, Mavens, and Salesmen
• Three: The Stickiness Factor: Sesame Street, Blue's Clues, and the Educational Virus
• Four: The Power of Context (Part One): Bernie Goetz and the Rise and Fall of New York City Crime
• Five: The Power of Context (Part Two): The Magic Number One Hundred and Fifty
• Six: Case Study: Rumors, Sneakers, and the Power of Translation
• Seven: Case Study: Suicide, Smoking, and the Search for the Unsticky Cigarette
• Eight: Conclusion: Focus, Test, and Believe
• Afterword: Tipping Point Lessons from the Real World
• Endnotes
• Acknowledgements
• Index

Assessment

This is a fascinating book, well written. Some of the anecdotes and "case studies" are mind-blowing. However, there is a bit of weakness in parts. In particular, the Afterword and the sections on The Power of Context are weakly put together - ideas do not flow well, or are too stream-of-consciousness. As well, the weight of evidence, while strong, is not totally convincing. That said, there are a couple of really fabulous stories.

One story that stands out is the study related to the "Good Samaritan". In brief, researchers set up an experiment to test what factors influenced a person's behavior when presented with someone obviously in need of help. At a seminary, the researchers had students prepare and deliver a brief talk on some topic. One of the topics given randomly to some of the students was the story of the Good Samaritan. The students were to take a short amount of time to prepare their talk and then immediately go to another building to deliver it. Planted by the researchers along the path to the second building was an actor made up to appear in a great deal of physical distress. As each student was sent out the door, the researchers would breifly comment either that the student was running a little early, or that they were late and needed to hurry to deliver their talk. The results were astounding: of those students who were told that they were late 90% ignored the person in distress regardless of the topic of their presentation, while 63% those with a few minutes to spare stopped to help (pages 163-165).

Relevance

There are several ways in which this book is relevent to those of us practicing Agile Work and related methods. Most obviously, the ideas in The Tipping Point suggest some lines of action we can take to promote Agile: finding the connectors, mavens and salespeople, working to make Agile sticky, and making the environment hospitible to the spread of Agile. This applies both inside organizations and in the world at large.

In my own opinion, the drafters of the Agile Software Manifesto, either by design or otherwise, came up with an incredibly sticky term: Agile.

Finally, when coaching a team to adopt agile practices, it may be most important to focus on the Power of Context. Small suggestions, small physical changes, body language, all can have a large influence on the success or failure of an agile adoption. If a coach (Scrummaster/Team Lead/etc.) can find the connectors, mavens and salespeople in the sphere of influence of the team, and convince those people of the efficacy of Agile, then convincing the team will become that much easier.

Posted by Mishkin Berteig at 09:59 AM | |

July 22, 2005

Applicability Matrix Tool for Self-Steering Team

Notes:

1. Self-Steering may be difficult to implement in some cultural circumstances. An organization that is very comfortable with a command-and-control system can benefit from self-steering teams, but the effort to shift the culture should be realistically assessed. An excellent reference for corporate culture change is "The Corporate Culture Survival Guide" by Edgar H. Schein.

2. Self-Steering in a rote work environment boils down to teams empowered to learn how to do the rote work as effectively as possible. This learning process must include the power to change the process with the goal of doing the work faster or with fewer defects. For example, in a manufacturing environment, this means people being able to identify problems and make improvements to the manufacturing process. In a rote work environment, not all changes the team makes will be improvements, but they must be accepted. A mechanism for measuring the result of changes must be in place so that the team can assess the effect of their changes, and make corrections as appropriate.

Posted by Mishkin Berteig at 06:38 PM | |

July 19, 2005

Applicability Matrix Tool for Adaptive Planning

Notes:

1. For rote work, it is rare to need an Adaptive Planning style prioritized backlog. Rather, simple queues tend to be sufficient. The adaptive backlog is designed to allow for reprioritization of work as more is learned about the work itself. With rote work most of the learning is involved with improving the process of creating the work and reducing defects rather than changing the work product itself.

2. Individuals can benefit from using a backlog to organize their work, keep a history, and track progress. However, it may be sufficient to keep a simpler to-do list. The adaptive planning practice allows an individual to gain the benefit of explicit collaboration points with stakeholders.

Posted by Mishkin Berteig at 10:39 PM | |

July 18, 2005

Sociometry and Team Building

I was recently introduced to the term "sociometry". As it turns out, my introduction to it was a little mis-defined. If you follow the link, you will find that sociometry is basically a measurement of relationships between people. What I was introduced to has some aspects of sociometry in it. I tried it out on a team that I am coaching. Here is what we did:

Team Building

1. If the members of the team have not worked closely together previously, start with introductions, name and role/experience.

2. Go around the group again, this time each person describes something about themselves that the others likely do not know. It could be something personal, like a hobby, or it could be something professional, like a previous career. The idea here is for everyone to learn something new about everyone. This usually can end up with exclamations of suprise, laughs, and general fun for the group.

3. Simple self-organizing starts with a group exercise of sociometry. The people in the team organize themselves into a line based on length of time they have been involved with the current organization/workplace/community/association. This is a fairly easy exercise since it is an easily quantifiable measure. Sometimes interesting things come up like that everyone has "been there" for a long long time, or that everyone is really new.

4. The team then does another sociometric self-organizing exercise. Here, each individual asks themselves what proportion of the creative or innovative capacity is actually put into use in their current role. How much opportunity is there to be creative? Again, the group organizes itself into a line from least creativity to most creativity. Note: this is not a self-assessment of how creative one is, just how much of one's creativity is in use! After the group gets lined up, it is important for the facilitator to get people to describe why they placed themselves in their location and to encourage discussion around creativity in their work.

Posted by Mishkin Berteig at 11:09 AM | |

July 17, 2005

A Nice Little Intervention

Esther Derby wrote about a great, incredibly obvious, but sometimes missed never-the-less, intervention for helping teams make a decision: write the options down (20050724: corrected link).

Posted by Mishkin Berteig at 02:42 PM | |

July 16, 2005

Applicability Matrix Tool for Information Radiators

Notes:

For individuals, the use of Information Radiators is usually not applicable in rote work since the individual can keep track of status of such work easily. However, for adaptive and creative work, an information radiator can be quite useful as a constant reminder of what is happening or for organizing work to be done. A cork board for the status of tasks or for categorizing ideas can be a simple information radiator used by an individual. A whiteboard can be used for free-form notes.

For teams, information radiators are ideal for easily maintaining broadcast communication with team members. A team is usually small enough that an information radiator can be maintained by individuals making updates as appropriate. Project status of tasks, issues parking lots, and group calendars are examples of information radiators used by teams.

For a community, the difficulty of using an information radiator comes in the logistics. With a large number of people performing work, possibly never all coming together at the same time, the broadcast nature of information radiators can be severly curtailed. It is difficult to efficiently represent information that is relevent to the whole communit in a way that can be easily accessed and easily understood at a glance. As well, it is difficult to have community members directly and (relatively) equally participate. That said, there are some exceptions. The most obvious one is the various wikis that are maintained by communities... and the largest of these is Wikipedia.

Posted by Mishkin Berteig at 06:45 PM | |

July 15, 2005

Applicability Matrix Tool

Not all of the Agile Work Practices apply in all circumstances. The Applicability Matrix Tool is a very simple visual tool to indicate when a practice can be used. The matrix has two dimensions. The first is the size of the performing team: an individual, a tightly constituted team or a loosely constituted full community. The second dimension is the amount of innovation in the work being performed: rote work, adaptive work, or creative/experimental work.

Each of the nine combinations of the two dimensions in the matrix is given a value: Not Applicable, Apply with Caution, Applicable, Essential. Here is how it looks:

The Applicability Matrix Tool is based on the experience of people using agile practices but currently does not have academic research behind it to back it up. As such, please consider letting us know if you have suggestions for the tool itself, or about how the tool is applied to any of the Agile Work Practices. Over the next few weeks, this tool will be provided for each of the six Agile Work Practices.

---

See Also Applicability Matrix Tool for:

Colocated Team
Iterative Delivery
Self-Steering Team
Adaptive Planning
- Information Radiators

Posted by Mishkin Berteig at 11:49 PM | |

July 14, 2005

Innovative Teams and Change Agents

In my experience, the best teams often start with one person who is really dedicated to challenging the status quo and who is also very charismatic in some fashion, without being a control freak. This combination of qualities allows the person to set a precedent for the other individuals in the team to gradually break out of their "shells" and start to come up with innovative ideas of their own. What are other ways that the best teams are formed?

Posted by Mishkin Berteig at 10:08 PM | |

July 08, 2005

Interesting Study about Office Organization

http://iwsp.human.cornell.edu/pubs/pdf/IWS_0002.PDF

Posted by Mishkin Berteig at 11:12 AM | |

July 04, 2005

Reporting for Accountability - Article by Geoffrey Slinker

Reporting for Accountability is a nice brief summary of project communications that can be classified as "reporting", done in an agile environment. Although this article presumes software development projects, many of the basic ideas can be abstracted to Agile Work in general. From the article:

Abstract Reporting and accountability are essential for business processes. Without those budgets can not be calculated, resources can not be utilized efficiently, as well as many other issues. Reporting has come to a level where one can truly do "more with less." Daily stand-ups, end of cycle reporting, damage charts, dashboards, and burn charts accurately and concisely disseminate information.

Major topics covered: "Ten Minute Stand-Up", "Project Planning", "Release Planning", "Iteration Planning", "End of Cycle Reports / End of Iteration Reflections", "End of Release Reflection", "End of Project Reflection", and "Information Radiators".

One practice in particular is quite different: the "Ten Minute Stand-Up" simply addresses a short series of yes/no questions regarding project status.

While this meeting bears some superficial similarities to the Self-Steering Team practice, it is in reality quite different. One major difference is the lack of a mechanism for team empowerment. In the "Ten Minute Stand-Up", members of the team are focused on answering a set of questions related to project status and risks, but there is no indication that there is any formal communication from each team member to the rest of what that team member has been doing, plans to do, etc.

Posted by Mishkin Berteig at 09:30 PM | |

June 27, 2005

What If Something Hurts?

If your work is hurt by some environmental, team or technical factor, there are only a few things you can do about it:

1. Ignore it (not advised). This usually can "work" for a short time, but inevitably leads to greater pain in the future. The only time this might be worthy of consideration is if the team has a larger or more immediate problem that deserves the team's full effort.

2. Attack it/do it a lot/embrace it. Develop an exceptional skill in dealing with the problem without eliminating it's root cause.

3. Transfer or expose the stakeholders to it. Be truthful about the situation so that the stakeholders can deliberate on how to effectively address the situation. In this collaborative approach, the team and the stakeholders work to determine the root cause of the problem as part of addressing it.

4. Measure things very visibly. Expose stakeholders to the problem in a factual manner. This method is used where the relationship between the team and the stakeholders is not yet a trusting relationship. This approach can be an effective CYA for both the team and the stakeholders and can lead to greater trust.

Posted by Mishkin Berteig at 11:30 PM | |

June 24, 2005

Big Visible Charts

Ron Jeffries recently posted something to the scrum developers list, where he made reference to his article on Big Visible Charts. It's a good article, and looks at a variety of presentations of metrics in an agile project. It took me back to Edward Tufte's Envisioning Information. (His other good books on the subject include Visual Explanations: Images and Quantities, Evidence and Narrative and The Visual Display of Quantitative Information). It's often very hard for agile workers to communicate status to people without too much reliance on "inside" jargon. Some of these principles and presentation mechanisms are quite helpful. Also of note is Marty Andrew's site, also on Big Visible Charts which contains many other and useful presentation approaches.

As practitioners and advocates of agile approaches, or as people considering the use of agile, the presentation of real status of an effort is crucial. The more of, and the more creative solutions that we can use to present this, the better we can communicate the real business value that the stakeholders are receiving.

Posted by Christian Gruber at 09:19 AM | |

June 23, 2005

Avoid Making Your Testing Debt Bigger

At the Scrum Gathering in May, Mike Cohn gave some good advice about testing in software that applies to all types of Agile Work. A very important Agile Work Practice is Test-Driven Work. If you are applying agile to an existing endeavor, there may be a lot of work already completed which does not have tests in place. This is a testing debt: eventually you will have to pay the principle down (build tests) or you will keep paying the interest (fix quality problems).

1. Start by creating tests that are easy. This is the "low-hanging fruit" and it gives the team a sense of accomplishment and progress against what may be a very large and difficult (but necessary) task. This can be done in such a way that it creates a framework that makes the creation of future tests easier.

2. Add to all new work the creation of tests. This is the move to test-driven work. At this point, your testing debt will now be growing smaller as a percentage of the overall amount of work. This standard must become second-nature to the team.

3. Once all new work is being done in a test-driven fashion, it is possible to start paying off the testing debt principle. The team sets aside a small amount of extra time to build tests for work that is already "complete". It is important to focus on building tests for the parts of the work that are most likely to need the tests.

For software, the book Test Driven Development: By Example by Kent Beck is an excellent introduction. I would like recommendations for books and web resources for testing and quality in other fields. Please email suggestions to topics@agileadvice.com.

Posted by Mishkin Berteig at 09:13 AM | |

June 20, 2005

Meet and Greet Before Critical Meeting

As an agile coach, one pattern of activity that I have found very beneficial is to meet up, one-on-one or in a group of three, with individuals before critical meetings. Critical meetings include training, facilitated workshops, conflict resolution meetings, project launch meetings, or any meeting where there is a lot at stake.

Each one-on-one follows a similar pattern. First, basic introductions. Then, I give a very abreviated life and professional history (married with three kids, grew up as a geek, 9 years doing agile, blah dee blah...). I also ask for a brief professional history from the person I am meeting with and if possible, as a little about who they are as a person. For example, I might ask about hobbies, family or what they consider important outside of work. Then, I check on their knowledge of the subject of the meeting. I get a basic background of how they think they might contribute to the meeting. I also find out how much they are familiar with agile, lean and other related concepts. If they are not at all familiar, I give a very brief introduction to agile work. Finally, I ask if they have any thoughts or questions that might be important for the upcoming meeting.

What does all this do? First of all, it allows me to have a personal connection with everyone in the meeting so that I don't have to try to build that on top of facilitating the discussion at hand. Secondly, it helps map out some of the strengths of the individuals involved. Occasionally, I will encounter someone who has something really unique to offer in the meeting. For these people, I ask them to make a special effort to present their unique skill, knowledge, etc. at the meeting. They may even go on the agenda. Thirdly, the one-on-one meetings provide a potentially safe environment to bring up issues that may be hard to bring up in a group.

I usually budget 1/2 hour for each meeting and they usually start a few days before the main event.

Posted by Mishkin Berteig at 11:56 PM | |

June 19, 2005

De-matrixed Teams

Many large organizations currently operate by creating project teams of people who formally report into other parts of the organization. This matrixed organization is meant to allow people to develop centers of excellence around a specialization and at the same time to implement a system of checks and balances. However, this type of organization also often encourages sub-optimal behavior by narrow performance measures and incentives (narrow to the area of specialization).

Consider using de-matrixed teams if you are finding that people on your teams are having a hard time collaborating, or if people are refusing to do work outside their area of specialization, or if people are doing really well inside their center of excellence but seem to have real problems making projects succeed.

What is a de-matrixed team? A de-matrixed team is constituted by having all members of the team report to a primary stakeholder of the endeavor. It is still possible, and often wise, to maintain centers of excellence, but team members no longer report into these centers of excellence. Instead, the centers of excellence become a source of support for teams that have specific needs (skills, infrastructure, etc.).

Posted by Mishkin Berteig at 11:51 PM | |

June 14, 2005

Collocate the Team

Collocation of the team is used to improve communication efficiency and to allow the team to learn to be more collaborative. Perfect collocation would have all stakeholders and work performers in the same work space (e.g. a large room) during all working hours. This level of collocation is not usually possible, so adjustments are made.

Collocation reduces wastes associated with waiting, movement, and inefficient communication. Collocation increases learning and feedback and assists with team empowerment.

Collocation can present challenges to people used to working on their own. For these people, a careful consideration of how to accommodate their working style is important, but more important is helping them to understand the need for and benefits from collocation. As this understanding grows and as the team starts to produce noticeable results, most people start to enjoy the close working environment.

When perfect collocation is not possible, consider part-time collocation, video conferencing, having a decision-making proxy represent the stakeholders, getting rid of closed offices, moving into open or shared work spaces or collocating part of the team.

I typically hear a great deal of positive feedback from teams that were previously not collocated after they come together in a common space. For example: "I don't have to spend hours dealing with email anymore - it takes a few seconds to lean over and ask a question and get a response." "Meetings that used to take half an hour to organize on people's calendars now happen spontaneously." "I can work much more efficiently because the people who I need to collaborate with are right there. No more emails, phone calls, scheduling, and pestering."

Posted by Mishkin Berteig at 09:27 PM | |

June 12, 2005

A Brief Note About Types of Backlog Items

In very broad strokes, there seem to be three categories into which backlog items can be put:

1. End Results - new functionality or capability that provides direct value to stakeholders.

2. Infrastructure Investment - work that is done to support the creation or delivery of end results but which does not directly provide value.

3. Debt Reduction - work that is done to eliminate barries to the creation of end results.

There are also some types of items that (typically) are not put on backlogs:

- Ongoing Tasks - tasks that are repeated on a regular basis.

- Constraints - descriptions of the qualities of the end results.

- Milestones - events or dates that define the transition from one state to another in an endeavor.

Posted by Mishkin Berteig at 11:35 PM | |

June 10, 2005

Self-Steering Team

Team self-steering is accomplished through a structured meeting that is used with regularity and several times or many times during an iteration. This type of meeting is used in order for the team to have a structured method of sharing critical information. Team self-steering is often done with a meeting called the “daily scrum”.

The team self-steering meeting involves each team member answering the following questions:
1.What work have you completed since the last meeting?
2.What work do you commit to complete before the next meeting?
3.What barriers are you encountering that are hindering your work or the team?

Generally, the answers to these questions should be kept brief and concrete. For example, in reporting work completed, the report should name tasks that are completed. Some teams who are using an information radiator for their task tracking will physically manipulate the tasks in some way to indicate they are complete. Team members must avoid getting into details during this meeting. It is not a working meeting where any decisions are made or work performed. Even discussion among team members should be deferred to after the team self-steering meeting is complete. A future entry will detail some of the types of barriers that teams typically come across.

One member of the team is specially empowered to track and eliminate the barriers. In the Scrum methodology, this person is called the Scrum Master. This person must have a pro-active and independent personality and have access to the rest of the stakeholders. The person eliminating barriers should remain the same over the course of an endeavor if possible. Every barrier mentioned in a team self-steering meeting should be resolved before the next meeting if possible. If that is impossible, the unresolved barriers are reported to the team and the team decides for itself how to work around the barrier.

As a rule of thumb, this meeting occurs every day at the same time of day. With a team of about eight people, the meeting should take less than fifteen minutes. Stakeholders who are not committing to perform work may observe the team self-steering meeting, but may not otherwise participate.

Some teams may be in a situation where they have people filling roles as managers, project managers, team leads or administrative assistants. All these roles can be integrated into a self-steering team. The key to doing this is that all team members must be willing to move beyond the strict definition of their role, and participate with equal responsibility for delivering results. For some people, moving outside of a defined role is very uncomfortable, or undesireable. These people may become effective team members with careful coaching.

In general, teams that are very new to self-steering benefit from external coaching that provides insight into teamwork, organizational culture, and personal development. All three disciplines are necessary components of creating a high-performance self-steering team.

The team self-steering meeting amplifies learning and feedback, enables responding to change, helps empower the team, emphasizes individuals and interactions as well as valuable results. This practice is critical to agile work.

Posted by Mishkin Berteig at 05:40 PM | |

June 04, 2005

Does Agile Software Development do away with Business Analysts?

I've been exploring career directions - and I must admit, this question has haunted me for a while. Fearing the answer to be "yes", I forged ahead, wading through blogs, and meeting with colleagues to find out how they work.

My conclusion: Agile Software Development transforms the role of the Business Analyst.

But this is not surprising - one of the main things that happens when working Agile is a realignment of responsibility with accountability. Customers become responsible to state and prioritize their requirements - and Agile processes hold them accountable for these things. Development teams become wholly responsible for delivering the required functionality - and are held accountable for its quality.

The Business Analyst may find herself floating between these two responsibilities. She must navigate this territory with care - our old way of working often meant taking on accountability from these two groups, a step backward when working Agile. I believe that the BA can become a facilitator - enabling Customers and or Developers to get their jobs done. In some organizations, this role is called "Agile Coach", and may be played by a BA, a Developer or anyone passionate about enabling the work of the team. While not every team needs a coach, it can be an important role - particularly when newly adopting Agile.

There is a balancing act required to do this... my blog covers a few scenarios derived from discussions with my Toronto colleagues.

A BA not interested in coaching could also retrain as a Developer or move into the Customer camp as a Product Owner or Product Manager. Fear not, there are still many ways to help build great software!

Posted by Deborah Hartmann at 08:16 AM | | | TrackBack

June 01, 2005

Adaptive Planning - Using a Backlog of Work

In order to respond to change, plans must be made so that they can be adjusted... and then they must be changed! The agile approach to this is to use adaptive planning with a backlog of work packages or tasks.

In order to create this backlog, an overall result or goal is divided up into work packages. For example, a large company may divide its work into projects where each project becomes a work package. On a smaller level, each project may be divided into work packages, each of which represents some value to the overall project goal (note, this is different from a traditional project work breakdown structure). A third example is in the creation of a book, each chapter may be a separate work package. A work backlog can contain anything that stakeholders consider even remotely relevant to their goals for this endeavor.

Next, work packages are prioritized and listed in strict decreasing priority in a backlog. In this backlog, no two packages have the same priority. Ideally, a single person is responsible for maintaining this backlog and determining the priority of work packages. Collective maintenance of this backlog can be a source of much extra work and even conflict. The person responsible for maintaining the backlog must be trusted to take all the stakeholders' interests and produce a reasonable priority list.

Each iteration, the team collaborates with the stakeholders to choose some number of work packages to work on and complete. If the team does not think it can complete a work package in a single iteration, it should be broken into smaller packages (remember that iteration length is not flexible!). The team is responsible for committing to the work so they have the final say on how much work they can accomplish during an iteration. No other stakeholders should pressure the team to commit to more.

Inside each iteration, the team breaks the work packages into smaller tasks and prioritizes them. Based somewhat on task priority, individuals in the team choose tasks to accomplish and work on them. It is very important for team empowerment that tasks are neither defined nor assigned by people outside the team.

At the end of each iteration, the work accomplished is demonstrated to the stakeholders. Based on these demonstrations and the lessons learned by the team, the remaining work packages are re-prioritized. Packages in the backlog can be added, removed or changed at any time, but the team's work can only be adjusted between iterations.

Using adaptive planning with a backlog in combination with iterative and incremental delivery enables the principle of responding to change. It is also a method to improve team empowerment and amplify learning.

Posted by Mishkin Berteig at 06:45 PM | |

May 31, 2005

Doctor, it hurts when I do this...

Patient: Doctor, it hurts when I do this...

Doctor: Then stop doing it...

A wonderful definition of insanity is "doing the same thing repeatedly, and expecting different results." Yet, for some strange reason, we persist in using methods that are not working. On several projects at a past employer, I was hearing reports of our corporate-branded custom methodology resulting in late delivery, incorrect delivery, and reduced features, etc. The argument given was always "this extraneous factor happened," or "the customer kept changing their minds," or "the customer wasn't implementing the methodology properly."

What was the solution? Why, to do the same thing again, only harder! This I hear from many of my colleagues quite frequently. When all is lost, and the methodology is failing, cling more heavily to its rules and structures. Now sometimes this is valid. If, in fact, the methodology is being poorly implemented, and if the methodology is supportive of the environment and culture and circumstance of the project, then by all means, tighten up the implementation. Sadly, however, seldom is a proper analysis done of the fitness of the methodology to the needs of the project.

One of the very nice things about Scrum, for example, is that it is a short-cycle iterative feedback system. It is not a large methodology with lots of process. In a sense, it is a process for uncovering the work that needs doing, and for structuring that work in a highly compartmentalized way. Because of this, it is often quite resilient to external factors. Also, Scrum assumes that outward conditions will change, and assumes further that many of these changes are entirely out of the project's control. Therefore Scrum is organized to find these externals irrelevant to its measures of success. It's classic lateral thinking.

Why mention the above? Because the most common failure of a methodology is its inability to handle fundamental change. It requires a certain number of assumptions. If these assumptions change, then the whole project needs to be re-conceived. If you have a project lifecycle that lasts about 2 years, this is a very expensive re-conception. In this context, my above paraphrase could be re-stated to: "Insanity is doing the same thing, in a different context, and expecting the same results."

With Scrum and other empirical processes, you re-formulate the project on a cyclical basis (say, a month). Thus, all new information can be assumed for the next cycle safely, and everyone is secure in the knowledge that all things can be re-examined next cycle. A problem is turned into a strength.

I'm not saying that Scrum can't be misapplied, or that people can't get into trouble there... but the fundamentals of Scrum and empirical processes are such that, if reasonably applied, you shouldn't need to bang your head into the wall month after month. After all, in the end, if it's that bad, it's much cheaper to cancel a scrum project than a traditional plan-based project, because you will tend to know sooner that it needs to be cancelled.

Posted by Christian Gruber at 01:18 PM | |

May 26, 2005

About People, Tools and Processes

Experienced, smart individuals who work together effectively will always perform better than junior untalented people thrown together at random. The experienced effective group will build its own tools and create its own processes. The random junior group will be unable to effectively utilize tools given to them, nor will they be able to effectively follow a process.

When a team needs improvement, don't impose a process or throw tools at them. Instead, concentrate on improving the team and the individuals within it. Technical, personal and team training and coaching will always be time and money well-spent. Spending money on processes and tools before an excellent team is in place can be very risky and wasteful.

Individualism and competition have no place in an agile work environment. Instead, the agile environment supports and fosters teamwork, collaboration and consultation. In turn, teamwork, collaboration and consultation depend on trust and truthfulness. “Truthfulness is the foundation of all human virtues.”

Nevertheless, processes and tools still have some importance. Great people with a great flexible process and great flexible tools will be hyper-productive. A junior group may need training on tools that will help them be more productive. Just be sure to never let processes and tools get in the way of the team.

In many ways, improving people is a sufficient practice for agile work. All the other principles, disciplines and practices would eventually arise out of this one practice. However, the depth of individual and group improvement needed for this practice to stand on its own is very great. Therefore we make the other principles, disciplines and practices explicit.

Posted by Mishkin Berteig at 09:57 AM | |

May 19, 2005

Test-Driven Work

In an agile environment, all work done needs to be directly related to the needs of stakeholders. Stakeholders request or “pull” work from the team, and they do this by defining prioritized work packages. The team needs some way to know when they have completed a work package, so both work packages and iteration tasks need to have testable acceptance or success criteria. The team collaborates with the stakeholders to determine what needs to be done to successfully complete a work package.

Based on the acceptance criteria, tests are described or created. Ideally, these tests are created before or simultaneously to any work that is done on the work package or task. Any work done is done only to make the tests succeed – no speculative (wasteful) work should be done. The team members should carefully avoid the belief that they can predict work that needs to be done if there is no test for that work.

Tests can be informal, formal or even automated depending on the environment and the type of work being done. Tests can be questions or measurements and their expected results. A test can also be a procedure to follow and the results of that procedure. If the environment supports it, automating tests can be an excellent investment for reducing waste. In an ideal environment and work domain, tests can fullfil all the attributes of an ideal test.

Test driven work has two solid benefits: it helps ensure close collaboration between the team and the stakeholders, and it helps eliminate the waste of unnecessary work. Thus it supports the three agile work disciplines of Empower the Team, Amplify Learning and Eliminate Waste.

In software development, where Test-Driven Work is very sophisticated, there are a number of excellent testing tools and resources.

Posted by Mishkin Berteig at 06:01 PM | |

May 18, 2005

Making Friends Sure Beats Making Enemies

I heard a story about a situation where someone was refused career advancement because she had made an enemy a long time ago.

It made me think. Why do we make enemies? Is it because we don't really know how to make friends? In Agile Work, where communication, collaboration, teamwork and truthfulness are so important, making enemies is the worst thing a person can do. (It might not be such a big problem in mechanistic environments.)

The golden rule is a good starting place for learning how to make friends. Esther derby has a great course on teamwork that could help. An of course there's the old classic: How to Win Friends & Influence People which really is very good (if a little dated). If anyone knows some other good books or resources about learning to make friends, please reply in the comments!

Posted by Mishkin Berteig at 03:26 PM | |

May 17, 2005

The Qualities of an Ideal Test

These six qualities of tests describe how to make a test as effective and as useful as possible. The qualities are similar in style to the INVEST qualities of user stories - but they don't form a nice acronym.

Decisive: The test contains all the information required to automatically determine success or failure. Manual inspection of test results is not necessary to determine success or failure. The test is expressed in a way that produces a pass/fail answer rather than a numerical or qualitative result. Decisive tests are often expressed as assertions.

Valid: The test produces a result that matches the intention for the work artifact under test. Test failure indicates failure in the artifact under test and test success indicates correct operation or configuration of the artifact under test. Simply put: the result of a test should be true.

Complete: The test contains all the information it needs to run correctly with a given test harness and work artifact under test. The test performs all activities and provides all the data necessary. The test does not require any input outside of itself in order to run.

Repeatable: The test always gives the same results if the test harness and the artifact under test are the same. The test is created in such a way that the result is deterministic. Even if the system under test is not deterministic, the test should be created to account for that (possibly with statistical analysis) and produce a deterministic result.

Isolated: The test result is not affected by other tests run before it nor does a test affect the results of tests run after it. The test and the test harness work together to clean up after every test is run. A collection of tests can be run in any order and always produce the same results. Any test that depends upon the results or side-effects of a previous test is not isolated.

Automated: The test requires only a start signal in order to run to completion in a finite amount of time. No manual intervention is required after the test is started. Tests that are automated can be put together into a test suite and run one after another without human intervention. Automation of tests requires the creation of a test harness system.

---

Update 20060106

I've added a little bit more detail to the above qualities. I also wanted to say a few words about my experience with testing:

I first started doing test-driven development almost seven years ago after reading the book Refactoring by Martin Fowler. I picked it up in Windsor Ontario while I was driving to San Francisco for my first contract position as an independent. I had to stay the night there due to the immigration office being closed so I read a lot of the book in my motel room that night. By time I got to California four days later, I was totally convinced that I should be using JUnit and refactoring for everything I did. Fortunately my project was ammenable to this approach. Over the next four months I built a Java JMS layer on top of Tibco Rendezvous. In the process I discovered methods for doing unit tests for asynchronous multi-threaded distributed functionality. And my tests satisfied all the above qualities. I delivered code with 100% test coverage and zero defects discovered until more than two years later when a very rare and obscure deadlock issue was found. Suffice it to say, I was convinced from a quality perspective.

But there is more. To build tests that follow all the above qualities, you need code that is testable. I have come to believe that testability is the most important architectural attribute of code for most software. The implications of having testable code include code that is easily changed, that is verifiable, and that is easy to understand. Refactoring plays a big role here too.

For getting a basic but very practical sense of test driven development, I strongly recomment Test Driven Development: By Example by Kent Beck.

---

I have also written a couple of articles recently about quality:

Quality is Not Negotiable in which I talk about how to handle defects - by always treating them as top priority work items.

and

Technical Debt in which I expand on this common analogy between lack of testing and debt to show that technical debt is even worse than financial debt.

Posted by Mishkin Berteig at 06:48 PM | |

May 16, 2005

Iterative Delivery

Work can often be divided up so that the smaller pieces are valuable on their own. By dividing work this way, a team can deliver value incrementally. The team can choose a short period of time called an iteration and select a small amount of work to complete in that time. This work should be valuable on its own. For example, if a team is building something, then at the end of each iteration whatever is built is usable as it is. This means that each iteration includes all the planning and design as well as construction or creation necessary to deliver a final product or result.

For example, a volunteer group may desire to attract new members. A non-agile approach would have the group plan their membership campaign completely before actually executing on it. An agile approach using iterative delivery would have the group plan a small piece of work that will attract some small number of new members, execute it, and then start a new iteration. One iteration may cover the creation of and delivery of a door-to-door flyer in a neighborhood. Another iteration may cover the design, creation and publishing of a small advertisement in a local newspaper. Each iteration includes all the steps necessary to produce a furthering of the group's goal of attracting new members.

In a business environment, iterative delivery allows for a much faster return on investment. The following diagram compares delivering value iteratively with a non-agile project delivery where results are delivered only at the end of the project:

One can see clearly from the diagrams that the non-agile delivery of value at the end of a project is also extremely risk prone and suseptible to change. If the project is cancelled just before it delivers, then a fairly substantial amount of effort is wasted. In the agile iterative delivery situation, an endeavor can be cancelled at almost any time and it is likely that substantial value has already been delivered.

Even if the work cannot actually be delivered incrementally, it almost always can be divided in a way so that it can be inspected in stages. Either method of dividing work allows us to do the work in iterations.

Iterations are fixed and consistent units of time during which work is performed and between which planning, inspection and adjustment is done. The empowered team will decide on the length of iterations for their work. As a rule of thumb iterations should be shorter than the horizon of predictability. Generally, iterations should never be longer than one month, no matter what the endeavor.

At the end of each iteration, a demonstration of the work completed is given to the stakeholders in order to amplify learning and feedback. Between iterations, the stakeholders collaborate with the team to prioritize the remaining work and choose what will be worked on during the next iteration. During the iteration, the stakeholders need to be accessible for questions and clarifications.

Iterative and incremental delivery is used to allow for the early discovery and correction of mistakes and the incorporation of learning and feedback while at the same time delivering value early.

Posted by Mishkin Berteig at 10:27 PM | |

May 15, 2005

Truck Factor

Truck Factor (definition): "The number of people on your team who have to be hit with a truck before the project is in serious trouble"

Clearly "hit by a truck" is an extreme thought however you could easily substitute "take vacation at the same time" to get the same idea. If any part of your project has a truck factor of one then you are in a particularly fragile situation. If that one person leaves or is unable to work on the project, you will suffer the consequences.

Over time, anyone can be replaced. Truck factor is an indication of how expensive it will be to replace specific people.

In an ideal situation, everyone on the team will know all parts of the system so that the loss of any one person would have minimal impact. In reality, many projects rely on one or more "heros" who are the only one who understand certain critical parts of the system. When these heros leave (and you should assume they will), you must be prepared to recover.

If you have a hero on your team, the best thing you can do is reassign that person to a different part of the system. This will allow the replacement to ramp up while the hero is still available for support. If you wait until the hero has left then the ramp-up will be significantly more expensive.

An added benefit to reassigning the hero is that this person will now have the opportunity to work on something different. Since the hero's tend to be the most technically competent members of the team, this will usually mean that the new area will improve once the hero has worked on it for a while.

Truck factor is a quick metric that will highlight potential problems in your project. Having hero's on your team can be very beneficial but only if you don't become dependant on them. Truck factor is one metric that will highlight your dependencies.

Cross posted from Mike Bowler's Weblog

Posted by Michael Bowler at 06:42 PM | |

What To Do With the Horizon of Predictability

In a previous entry about constant change, the idea of a horizon of predictability was introduced. This concept, along with the agile discipline of amplifying learning, suggest a strategy for addressing problems in a project.

Shorten the length of the iterations you are using. Contract your "planning horizon". The length of your iterations should be motivated by the horizon of predictability for your environment. If your project encounters trouble, particularly of the sort where it looks like you might not accomplish your commitments for an iteration, then shortening the length of iterations will enable you to resolve your problems.

First off, by shortening your iteration length, your opportunities for learning become more frequent.

Secondly, a contracted planning horizon will put you more firmly inside the horizon of predictability... and therefore there will be fewer unexpected changes (on the whole, not in any specific iteration).

A related article is The Pros and Cons of Short Iterations.

Posted by Mishkin Berteig at 06:34 PM | |

May 10, 2005

Steps in Making a Decision

In her workshop "Advanced Scrum: Collaboration Skills for Scrum Teams", Esther Derby includes a brief discussion on the five parts of a decision.

1. Define the Problem
2. Establish Focus and Boundaries
3. Identify Options
4. Choose Among Options
5. Implement

At each step, it is instructive to examine who is "responsible" or involved. In an agile team where team empowerment and self-organization are considered critical success factors, the answer to "who?" fore each step should usually be "the team".

There are however, some situations where decisions are outside the realm of a team's empowerment. As well, some decisions are so trivial that it is wasteful to have the whole team involved. In these trivial decisions, usually another person can take responsibility for all the steps of a decision as a service to the team.

Over time, a team and the organization in which a team operates can evolve a set of standards that describe who acts in each step of a decision under what circumstances.

Many thinking tools described by Edward de Bono in his various books (such as Six Thinking Hats, Lateral Thinking : Creativity Step by Step (Perennial Library), Textbook of Wisdom etc.) can be used at various steps in the decision making process.

Posted by Mishkin Berteig at 11:48 PM | |

Empower the Team

Empowerment is the ability of a team to make decisions about how to do their work and execute on those decisions without outside interference. If a team is empowered, then it will be more capable of responding to change, and it will be able to focus on manifesting the members' creative potential. Empowerment comes from a combination of several factors:

1. members of the team have a deep sense of self-worth that includes nobility, and contribution to the progress of humanity

2. tacit or explicit authority and responsibility for results as a team and as individuals

3. a team environment which is honest, trusting and allows for mistakes

4. the absence of personal attacks against individuals on the team and in particular a total lack of gossip and backbiting

There are several ways that team members will demonstrate their empowerment. People will derive joy from their work. Team members will be dedicated to the work and the team. Individuals on the team will frequently take individual initiative to accomplish tasks, share insights, and develop improvements. Spontaneous leadership will become common. Individuals will step out of comfort zones or areas of specialization in order to assist the team.

Empowering a team is a process that can sometimes take a great deal of time and effort. In order to start on this process, the team members should carefully listen to each other and ask many questions. More mature individuals should lead and teach by example. And all the team members can start to question and challenge the rules and procedures of an environment that are preventing effective work. If the team is in an organizational environment where team members have management to report to, then management must be aware of this opportunity for empowerment and support it.

An empowered team can gradually understand and internalize the agile work principles (People are Creators, Change is Constant, Perception mediates Reality). By internalizing these principles, a team can move beyond specific agile work practices and become a high performing team setting their own work practices.

Jeff Sutherland has a very brief blurb about the progress of teams as they evolve in their use of Scrum.

Future entries here will discuss the methods of creating empowered teams.

Posted by Mishkin Berteig at 11:04 PM | |

Information Radiators

An information radiator is a large display of critical team information that is continuously updated and located in a spot where the team can see it constantly. The term "information radiator" was introduced extensively with a solid theoretical framework in Agile Software Development by Alistair Cockburn.

Information radiators are typically used to display the state of work packages, the condition of tests or the progress of the team. Team members are usually free to update the information radiator. Some information radiators may have rules about how they are updated.

Whiteboards, flip charts, poster boards or large electronic displays can all be used as the base media for an information radiator. For teams new to adopting agile work practices the best medium is usually a poster board on the wall with index cards and push pins. The index cards have a small amount of information on each of them and the push pins allow them to be moved around.

Information radiators help amplify feedback, empower teams and focus a team on work results. Too many information radiators become confusing to understand and cumbersome to maintain. If an information radiator is not being updated it should be reconsidered and either changed or discarded.

Here is an information radiator used to quickly display the status of multiple projects to an agile Project Management Office:

As the team used an information radiator, it can adapt the display of information to become more appropriate to the way the team is operating and the information they are really concerned about. For example, on the above IR for a PMO, the group may decide that they wish to put red dots on projects that are in trouble in some way.

Some very interesting examples of the effective visual display of information can be found in The Visual Display of Quantitative Information.

Posted by Mishkin Berteig at 06:25 PM | |

May 06, 2005

Agile Readiness - When Can Your Organization Adopt Agile?

I've come up with a short quiz about agile readiness. It has never been tested anywhere. Rather, it represents my observations about what conditions have been in place in organizations where agile has taken root and flourished vs. places where attempts at agile have failed.

Agile Readiness Assessment Worksheet

Empowered Agile Process Facilitator

This person is responsible for the success of the agile process used on your project. They help your teams and your organization deal with the obstacles to becoming agile. They facilitate an explicit learning process. They avoid "command and control" approaches to managing work. An excellent source of such people is those who have taken the training available from Agile Masters.

Your situation is best described by:

Score: 0 - No one available for this role
Score: 3 - Someone is available and empowered by management, but he/she is inexperienced
Score: 3 - Someone is available and experienced, but not empowered by management
Score: 6 - Someone is available who is both experienced and empowered

Your Score: _______

Management Support

Management support provides protection from the “old way” of doing things, and enables a team to self-organize, cut through red tape, and establish a “new way”. Initially, this is often done with a pilot project. It can also be done with special task force teams. In the long term, it requires upper management to understand and support with clear goals and measures the change needed.

Score: 0 – Management insists on full compliance with existing internal project process
Score: 2 – Management does not know that the team is doing Agile
Score: 4 – Management accepts Agile, but is ambivalent about methodology
Score: 8 – Management is excited about doing Agile
Score: 8 - Management is unconcerned about method and cares about results only

Your Score: _______

Team Readiness

A team must be ready to take on work. If the team is already familiar with the work to be done, and the team has worked together previously, then the team is ready to take on the new challenge of agile work practices.

Score: 0 – no team has been created for the project
Score: 2 – team has been created but has never worked on this domain
Score: 4 – team has been created and members have worked in the domain previously
Score: 6 – team has been created and members have worked in your organization in the domain previously
Score: 8 – team has been created and worked together previously in your organization in the domain

Your Score: _______

Team Experience with Agile

Past experience with agile practices can have a substantial positive effect on the outcome of the project launch.

Score: 1 – no experience and not interested in Agile
Score: 4 – no experience but very interested in Agile
Score: 6 – some experience with Agile and still interested in it
Score: 8 – very experienced with Agile

Your Score: _______

Project Readiness

The project must be funded (or otherwise materially supported) in order to be launched. A strong champion can often ensure funding is in place before project launch commences. It is also critical that the project is satisfying a real need in the organization.

Score: 0 – Project has no champion nor has it been funded by the organization
Score: 1 – Project has a strong champion but no funding yet
Score: 5 – Project has no single strong champion, but it has funding
Score: 9 – Project has both a strong champion and confirmed funding

Your Score: _______

Scoring:

Sum up the scores for each aspect of readiness.

0 – 12, or 0 on any single aspect: Definitely NOT ready to launch an agile project. You need to do some basic work to prepare.

13 – 27: Your organization is ready to take on the launch of an agile project... but with assistance! Consider hiring a coach.

28 – 39: Go for it! You have enough experience/support/excitement to have a good chance of doing it on your own successfully.

(NOTE: this assessment is an indicator not a guarantee.)

Posted by Mishkin Berteig at 04:44 PM | |

May 04, 2005

Can dying plan-based projects be recussitated?

We've all seen this. A one-year project in its 13th month, and the Project Manager has been reporting 80% of the tasks at 90% and has been doing so for the last 120 days. There's no end in sight, and the customer is leaking cash every day the product fails to go into production. What can be done? Agile project management principles can help this all-too-frequent scenario.

First, let's look at how this situation comes about. In a typical task-oriented project plan, one is required to decompose the tasks down to a fairly reasonable degree of specificity. The tasks are organized around a dependency graph, estimated, resources are assigned, and the schedule is calculated and/or nudged. (Well, usually the initial estimates don't match the customer's expectation and deadlines, so there's a revision step here where estimates are shortened) But how does change get reflected? If a PM is doing an excellent (if frustrating) job, they are constantly updating the schedule, the plan, and re-conceiving the tasks as new information comes to him.

More often than not, however, this gets so messy and unwieldly that the PM holds fast, and starts to estimate completion based not on a proper decomposition and a completion of each of these tasks, but based on his guess, or his workers' guesses. Complexity of the tasks is hidden, and becomes often quite invisible. Tasks at 80% which suddenly need to be re-decomposed and re-conceived do not, in the main, get moved back down to 40% after certain roadblocks are discovered.

The result? The customer is increasingly afraid, trust between delivery staff and client (and management) are eroded, pressure is increased, mistakes under pressure become more frequent, less sleep is had by all, and 90% complete becomes an asymtote, rather than a milestone.

Now what is to be done with such a project? How can Agile project management approaches help this situation? We can examine this by playing out such a scenario...

We can start by identifying a few key practices of Agile project management, and examine their benefits to the business client.

Timeboxing and Iteration

The first thing we can talk about to the fearful client is timeboxing. Timeboxing caps his investment into small chunks. We look at it and say, OK, you're in deep trouble, but you don't know how deep your trouble is. By timeboxing into a very short timeframe, and making a large project into many little short projects, we can get more visibility into the process - we can see things as they are, rather than how they're reported on a project plan. Speaking of visibility...

Daily Meetings and Iteration Review

Part of the value of iteration and timeboxing is increased visibility, so we really need to have a mechanism for visibility. Already distrustful of project plans, we can tell the client, "Don't believe the paperwork, let's look at what's actually built. At the end of each iteration, we'll review the current situation, and demonstrate existing functionality." His eyes perk up. "Wah?" he asks incredulously? What do you mean? So we say, "we don't want you to guess at how ready this thing is. We'll show you. That way, you can decide if it's ready enough. ...Or your product marketing people, if you prefer. It's up to you, but you get to see it, touch it, and sense for yourself how ready it is, and you won't have development managers and developers waving their hands pretending it's further than it is."

"Oh wierd," says he. "So what are these daily meetings?"

We tell him that the daily meetings have several purposes. Only project members get to speak, and they report on what they did yesterday, what they plan to do today, and what, if anything, is blocking their path. No one else gets to speak, but others who are not on the team itself can listen in. This way, the whole project team is clearly aware of how they're working, what's left to do, and what each other are doing.

"Why do they need this? They have the plan." "True," we reply, "but how often do you have two people who need something, and both do it because they don't know that someone else already did it. With your current project delays, do you want any duplication of effort? Just by way of example?"

Feature Lists, not Task Lists

We also talk to him about working from feature lists, not task lists. The team will be implementing features, and fulfilling requirements. How they do it is up to them. "Why should I care," he'll ask. "You don't," we reply, except to assure him that if people are working against features, then they can choose to re-order their tasks in such a way as to most quickly get to the goal. No wasted effort, we tell him. Sounds good to him.

Customer-Prioritized Features

What's more, we assure him, we will be first working on the highest-priority features. What "needs" to get to market. Everything else slides down the list. Even if the wonderful plan we all love had it earlier. High-value features (as prioritized by the client) and their necessary dependencies. That's it.

"So no features that I didn't ask for?" He looks hopeful.

"That's right," we reassure him, "and you can change your mind."

He faints.

Smelling salts are brought.

"What do you mean, 'I can change my mind?'" he asks.

"If, when we get to the iteration review, and you test drive the thing, Acme corporation has come up with the killer feature that you absolutely must have or the whole thing is useless, you put it at the top priority on the list we use to drive the next iteration."

"And no one will complain that it's out of scope?" he marvels?

"If you put it at the top of the list, it is the scope for the next iteration. We are at your service," we comfort him.

"So when will this be finished?" he asks us desperately.

"When you say it's ready," we reply. He boggles. What does that mean, he thinks.

"What does that mean," he asks.

"It means that we will tie it off, when you think it has enough juice to go to market. If, after you re-prioritize what's left, you find that it's 'ready enough', then we'll roll with it, take a couple of weeks to steady it and ship it, and then we can pick up your next-highest priority things, or anything new you want in it." He looks near fainting again. "And we stop when you feel that spending money on it is no longer bringing you enough value, ideally because we've done all the high-value stuff already, and we're working on less valueable stuff."

"So I have discretion to pull the plug whenever I want to?"

"Yep."

"Please help me..."

Conclusion

This little scenario is fictitous, but in the end, it's consistent with the experiences of many Agile practitioners (particularly Scrum) that I have spoken with. We've only covered a small sampling of Agile practices that may help a project in crisis. Others may help quality, may improve developer productivity - but the above can help a key client or stakeholder begin to see a light at the end of the tunnel. While many people cannot get their heads around it, they may be willing to try new things when they're in enough pain with the existing process.

And it can turn a project failure into an ever-increasing success, because success is defined monthly, re-defined at the desires of the business client, and executed in bite-sized chunks that are digestible and estimable.

Just don't forget that people have the strangest reactions to things that break their expectations... so make sure to bring the smelling salts...

Posted by Christian Gruber at 09:08 PM | | | TrackBack

Asymmetry of Knowledge and Abuse of Agile Practice

I read an article in Wired yesterday that was modified from a book "Freakonomics". The article talks about real-estate agents and motivation to push the price 10000 higher. The observation was that the $150 incremental gain (1.5% of 10,000) doesn't make it worth their holding out an extra three weeks to get the higher number. Their interest is in closing quickly and moving on. They can often convince (through fear) the poor seller price that suits their interest. He wasn't even sure if it was conscious, but it naturally flowed out of the asymetrical knowledge levels between the agent and the client. (I'm reminded here of the saying "A System's Purpose Is What It Does".) This asymmetry of knowledge is highly important in the Agile community's current situation, in that it gives early practitioners the "expert" status, and lots of power to help or hurt the client.

Doctors have a similar motivation. Statistically, when times are tighter (fewer patients), the article pointed to the proportion of interventions going up (referring here to internists and surgeons). The article isn't crying conspiracy. Rather, it's talking about the natural incentives, and the consequences of the asymmetry of knowledge. The doctor knows more, so if they (consciously or subconsciously) recommend more intervention than is necessary, the patient has no way of knowing in order to assess bias and accomodate. Likewise with Real-estate agents.

With alternative practices or new sciences there is an even larger knowledge gap, because even popular wisdom hasn't filtered down to the masses in digestible CNN-sound-bite chunks. Also, there is a lot of "naive money" in new fields, as well as a lot of genuine people who are just trying to help. Unfortunately, this means that there are a lot of wolves among the sheep, and they're wearing the costume of a sheep-dog.

I think, in some ways, that was at the basis for Ken Schwaber's concern on the Scrum Developer's list about a scrum practitioner who was not really teaching scrum, but was (in Ken's paraphrased view) bilking the customer and ego-tripping. Scrum will have a similar dynamic as one finds in, say, alternative health and nutrition, or other early-stage professional arenas. There will be idealists and opportunists and then some who try to apply balance. One has to be very careful of both the idealists and the opportunists. Sometimes it is very hard to tell, and this has a high chance of painting the whole Agile community with the same brush. One of my associates had a very very bad experience with Scrum for that reason. An unscrupulous person who used the position of Scrum Master to aggrandize himself.

Posted by Christian Gruber at 01:07 PM | |

May 03, 2005

Index Cards as an Agile Work Tool

Index cards are an excellent tool to use to optimize communication. There are two primary types of use for index cards.

1. Dynamic Collaboration

Many types of meetings can be made more collaborative and therefore more effective by the use of index cards. Cards are written on to record ideas. By writing on cards, all the participants in the meeting can see the ideas.

As an example, suppose that a team is examining two competing ideas of some complexity. The team uses two colors of 5x7 index cards and a pile of Sharpie(R) markers. The different card colors represent the competing ideas. Members of the team take cards and write down their comments as they think of them. The team member then reads their card aloud and passes it to a facilitator. The facilitator takes the cards and puts them up on the wall under various categories. The team uses a thinking tool such as PMI (Pluses, Minuses, Interesting) from CoRT to organize the cards.

Contrast this method with someone taking notes. Using the cards allows all the team members to see all the information at the same time. It also allows team members to come up to the wall and either add notes to a card or move cards around.

2. Dynamic Tracking

Teams are more focused when they are constantly aware of the status of their work. Index cards can be used to improve the team's awareness of status information by forming them into an "information radiator".

For example, a team might be working from a list of tasks. Each task can be written on an index card. The task cards can then be put on a wall and organized into groupings based on their completion state. A typical set of states might include "Not Started", "In Progress", "Waiting for Test", "Tested" and "Approved". As team members work on tasks, they move them from group to group. In this way, the team can easily see how much work they have done, and have yet to start. As work progresses, the team gets immediate positive feedback as the number of cards in the "Approved" state grows.

This method can be compared to an online project plan status updated by a project manager. The index card information radiator is participatory and always visible. It requires no effort to check status, and provides tangible motivation and focus for team members.

Posted by Mishkin Berteig at 05:00 PM | |

April 30, 2005

Pair Programming in Software Development

Pair programming appears to be the most controversial of all the Extreme Programming (XP) practices. It invokes such a violent emotional response in some people that they quickly dismiss all of XP just because of this one practice.

Let me start by saying that I've done pair programming on software development teams and it has worked really well for me. I freely admit that it doesn't work for everyone or in every situation however when it does work, it is the most effective form of peer review that I've ever used.

Laurie Williams of North Carolina State University has done extensive research into pair programming and has published her findings at PairProgramming.com. She has also written the book Pair Programming Illuminated with Robert Kessler. If you are interested in seeing actual research into this practice then I'd strongly recommend reading Laurie's work.

Lets look at why this practice is so controversial.

The benefits of pair programming are significant. Overall development time is reduced and quality is higher. Additionally, teams doing pair programming tend to have more fun than teams working individually. People who have done pair programming when it worked well are strong advocates for the practice as they've seen first hand what is possible.

The biggest downside to pair programming is that it can push people well outside their comfort zones. I have often heard comments like "if they make me pair, I'll quit". This is an understandable fear reaction to something that is outside our comfort zone. Pair programming cannot be effectively mandated for exactly this reason. If the team is reacting out of fear then you won't get any of the benefits of the pairing.

Another downside to pair programming that doesn't get discussed as often is that it is tiring work. After a day of pairing, the team is usually exhausted.

I've also seen problems where there is a personality clash between programmers. I coached one team where I had two otherwise excellent programmers who couldn't be paired with each other because of a personality clash. Either one could pair with anyone else on the team but they couldn't be put together.

One common myth about pair programming is that it will take twice as long to complete a certain amount of functionality. In my experience (and the research backs this up), a pair will take longer to write the initial code but will spend less time debugging as the code will have significantly fewer defects. When the total developer time is measured, it actually turns out that pairs are more effective than individuals.

To be perfectly honest, I didn't believe this claim myself until I actually tried it. Now I've seen the results first hand.

One nice side effect of pairing is that you are continually cross training the team. Over time, everyone will learn all parts of the application and therefore the team will be less susceptible to staffing changes.

If your team is open to the idea of pair programming then you can get some significant benefits from this practice. Be aware however, that mandating the use of pair programming can be disastrous if the team is not receptive.

Posted by Michael Bowler at 03:28 PM | | | TrackBack

April 18, 2005

Book Review: "Good to Great" by Jim Collins

Summary: In this well-written, engaging book, author Jim Collins describes six critical factors that he and his research team found common in companies that transformed themselves from a long period of mediocre or bad results to a long period of great financial results. Although focused on publicly-traded companies in the United States, the results of this research can easily be extended to apply to other types of organizations.

Good to Great describes the following six concepts:

1. Level 5 Leadership: personal humilty and professional discipline in an organization's leader are the starting point for the transformation.
2. First Who... Then What: don't worry about what to do until the right people are in the right positions in an organization.
3. Confront the Brutal Facts (Yet Never Lose Faith): careful and honest examination of an organization's current situation is the foundation for finding a path forward.
4. The Hedgehog Concept (Simplicity within the Three Circles): discover a simple business concept that people can be passionate about, that works with a single key economic driver and that the organization can be the best in the world.
5. A Culture of Discipline: disciplined people removes the need for heirarchy, disciplined thought removes the need for bureaucracy and disciplined action removes the need for excessive controls.
6. Technology Accelerators: pioneer the application of carefully selected technologies without relying on technology for transformation.

Some of these concepts are very close to the underlying prinicples of agile work. For example, in the Scrum methodology, the first five principles are all represented. The Scrum Master embodies some of the attributes of level 5 leadership. A self-organizing team gets the right people in the right position. The daily scrum and the sprint planning meetings are designed to help the team confront the brutal facts. The sprint goal embodies at a local level the simplicity of the hedgehog concept. And the practices in general are a manifestation of a culture of discipline.

Who Should Read this Book? Anyone interested in creating a lasting positive transformation in an organization should read this book. In particular, individuals who are coaching teams or organizations should read this book since the concepts also appear to apply at a sub-organizational level.

Posted by Mishkin Berteig at 07:29 PM | |

April 14, 2005

Stealth Methodology Adoption

This link was seen on a scrum-toronto list, referring to an e-book called Stealth Methodology Adoption. The title is brilliant, and reflects, in my view, a significant means of adoption of Agile technologies at this point in the maturity of this market.

More projects than not, a small straw poll of friends and family in the business indicated, where Agile was used, used it under the radar screen. Often artifacts were translated into the artifacts of more traditional PMOs, and not a word was said. However, this is a dangerous approach, however necessary at times. The partial implementation of an Agile method, without buy-in in certain quarters can lead to a failure to realize the benefits of the method. If the practices that were used can be blamed, they will. People love to find scapegoats, and there are costs to agile that can be pinned. For example, if the project fails, but TDD was used in isolation, or used badly, it can be held to account as having taken more time than just writing code. If Pair Programming is used in an otherwise traditional project that fails, it can be identified as a halving of productivity. If daily scrums and backlog are used (again, by themselves, or without experience), they can be seen as a failure to gather sufficient requirements and manage to those requirements.

It take subtlety and wisdom to know how much agile to put into an organization, how much visibility, and which particular practices will garner the most benefit in a particular area. Most agile methods have a combination of practices that encourage emergent behaviour. But in many cases, the practices themselves are emergent. The interaction of daily scrums with a scrum master that's working the group to a sprint backlog, and working with a product owner to refine the product backlog for the next sprint - without interrupting the sprint - these have powerful effects on productivity when put together. But, for example, all you have to do is interrupt the sprint and start messing with sprint backlog, or have a product owner / scrum master that doesn't do the work of refining a good product backlog and you end up with developers who don't know which way to turn at a given moment.

Similarly, TDD - if you are writing tests first, but you're not actually defining "done" properly, (ie. sufficiently covering the desired behaviour and edge and negative cases) then you can end up having someone write a lot of tests that are practically meaningless to the code in question. This means that you don't get the benefits of the testing, plus you incur the costs not only of the tests, but also of the wasted time sifting through test code that was not written against the requirements of the interface.

In a lot of these situations, it is judgement that comes from experience that is the real solution. There are few formulae that can practically resolve these questions. The benefits of NOT implementing Agile in stealth-mode, therefore, include the ability to bring in experienced mentors who can provide this kind of judgement to an organization new to agile approaches. Most "stealth agile" projects don't have budget for such. But books like the afore-linked can help communicate some of this wisdom and judgement.

Posted by Christian Gruber at 07:08 AM | |

April 13, 2005

Backlogs in an Organization - Levels of Queues

Queues of work form at three types of levels in an agile organization.

At the largest level is the project portfolio. The queue for this level contains all the projects that are not yet being actively worked upon by project teams.

At the intermediate level is the backlog of project functionality. The queue for this level contains packages of business function or infrastructure components necessary to implement business function. These packages are selected by a project team to fit into a single iteration.

The packages in turn are also elements in a queue. This smallest level of queue contains individual tasks required to implement all the business function and infrastructure that make up a selected package of work. The team members select tasks off this queue based on priority and dependencies.

In many agile methods, the queue management approach is fairly explicit at the intermediate and small levels. However, very little is said about the largest level. Some organizations have solved this by limiting the size of projects:

To be successful, high-tech CIOs recommend biting off projects in small chunks.... Gregoire notes that Dell is growing so fast that at the end of an 18-month project, the company would be significantly different from when it began. "A project has to take less than six months [to complete]. That's the only way we can make sure [it stays] with the business," he says. (http://www.cio.com/archive/120198/tech.html)

Posted by Mishkin Berteig at 06:19 PM | |