Agile Advice

December 11, 2007

New Agile Training Course and 2008 Schedule

Berteig Consulting Inc. is introducing a two day course for team members. The first run of this course is occurring in Toronto on Jan. 21 and 22. This course is a slimmed down version of the four-day intensive training that we often deliver in-house to teams. It is an inexpensive option for teams that want to bring a new team member up to speed, who need to get a few people to understand how Scrum works and then share it with the rest of the team, or for any team member who would like to learn how Scrum works in the hopes of intelligently convincing other team members to try it out. Since there is a strong experiential component to the course, it is also ideal for managers and other stakeholders who would like to try out an agile process.

We are also offering our three day Agile Project Management / ScrumMaster Certification course in several locations: Toronto, Ottawa, Edmonton, Calgary and Beijing. Right now, there are special prices for the first team member training course as well as the course being delivered in Beijing.

For more information, please check out the Berteig Consulting listing of agile and Scrum training.

Posted by Mishkin Berteig at 03:43 PM | |

November 01, 2007

Learning Collaboration

How do we teach people to work in a collaborative manner? How do we help individuals, in our incredibly individualist and competitive society, to learn the skills needed for agile teamwork?

Start with the Kids

Our school system, here in the West, is strongly oriented to individual grading, work, and even competition. We throw our kids into age-limited classrooms where they are inevitably compared to one another and learn to make the comparisons themselves. There are private schools which don't do this: no grading, mixed-age classrooms, but they are the exception by far.

It seems reasonable to me that if we could help our kids learn collaborative skills, they would at least have a foundation to build upon and minds that were more open to the possibilities.

In my mind, the best way to do this consists of two aspects: collective efforts and human capacity development.

Collective Efforts

Kids are amazing at learning. If they have experiences, they naturally learn to cope with those experiences. It follows then, that even if children start out with little or no skill in collective, collaborative work, then simply by putting them into situations where that type of work is required, they will learn at least some of the necessary skills.

I had two experiences in my childhood that helped me learn those skills. In my faith community, as a Baha'i, we had children's classes (kinda like Sunday school) where we played many collaborative games and learned about the Baha'i concept of consultation. I didn't particularly like the games, but nevertheless, they made an impression on my young mind. I even remember at one point when I was a little older learning to help out with these games. The things I learned about group decision making through consultation made a big impact on me and have become more and more important as I progressed through school and professional life.

The second experience was in my public school where I was streamed into a program for academically talented children. I think the idea was that if you had an IQ of 120 or over you were eligible for the program. I remember doing an IQ test in grade four. Anyway, the program was excellent in many ways. In grades seven and eight we started to learn Edward deBono's CoRT thinking skills program. I'm not sure if it was intentional or not, but many of the exercises were small group exercises where two or three or four of us had to work together. Again, I learned a great deal about the value of working with people with different skills and ideas, and how to do this in a systematic way. Many of the exercises and techniques that I use as a coach and trainer are based on or inspired by these exercises I did as a child.

Human Capacity Development

I recently wrote here about truthfulness. Aside from the obvious implications for agile methods that I have written about, there is another level to this concept.

Truthfulness is the foundation of all human virtues - Baha'u'llah.

There is no doubt in my mind that some of the basic virtues or moral ideas that we are supposed to learn in childhood are critical to effective collaboration. For example, the "Golden Rule": "And if thine eyes be turned towards justice, choose thou for thy neighbour that which thou choosest for thyself." Epistle to the Son of the Wolf, p30.

The trouble is, you can't do the Golden Rule effectively without being truthful. How so? Well, if you can't be truthful about what you really want for yourself, deep, deep down, then chances are you aren't going to do to others what they truly want. Knowing your own self at the deepest level is a pre-condition to following the Golden Rule effectively. And knowing your own self deeply requires a level of truthfulness that most of us are not accustomed to.

The same could be said about almost any other virtue or capacity required for collaboration: courage, humility, assertiveness, compassion, etc.

Of course, developing these capacities is something that doesn't happen overnight. The starting point is to look at what we can be truthful about, and building on that. As we practice these capacities in our relationships with other people, they will strengthen and we will set out on a path of improvement. It is helpful to have other people working with us; to support us, encourage us, and to help us honestly face up to our failures and learn from them. It also helps to have guidance that can be trusted. Searching for these sources of guidance is an important part of developing professionally as well as personally, whether it is a mentor, an author or some other figure.

These capacities are essential to our ability to work well together. The root cause of most of our failures to work together can be traced back to a lack of or failure to exercise these human capacities. For example, a lack of courage can lead to a failure to experiment. A lack of humility can lead to a failure to ask for help.

Posted by Mishkin Berteig at 07:26 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 24, 2007

Agile Benefits: Five Essential Reasons to Try Agile

Although there many other benefits of agile, and although those provide us with other reasons to try agile, the five essential benefits of agile are:

Rapid Learning - disciplined application of the scientific method to explore the best ways to deliver valuable results.

Early Return on Investment - opportunity to use the results of work starting with the work delivered at the end of the first iteration.

Satisfied Stakeholders - engagement in the process in a way that allows meaningful contributions from all stakeholders.

Increased Control - mechanisms to track/measure and therefore steer the direction that work is going so that it meets goals.

Responsiveness to Change - processes, tools, roles and principles that allow a team and an organization to embrace change rather than reject, control or suffer from change.

These reasons are sufficient and apply to operations work, project work and open-ended research work, whenever humans are involved. The above links take you to more detailed descriptions of each of these benefits.

What are some of the other benefits of agile?

Posted by Mishkin Berteig at 10:47 PM | |

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

A Cautionary Tale - Delaying Agile Adoption

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

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

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

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

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

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

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

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

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

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

Please, just start iterating!

Posted by Mishkin Berteig at 09:55 AM | |

March 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 20, 2007

Learning Vocabularies

Last April I wrote a brief article showing the relationship between five different learning models. I've discovered two more for your edification:

The Shewhart (Deming) Cycle of Plan, Do, Check, Act

and the Six Sigma DMAIC cycle: Define, Measure, Analyze, Improve, Control

I find it so interesting that the same basic ideas have circulated (no pun intended) in so many different disciplines for so many years. Does anyone know if there is a good description of a universal / abstract cycle of which all the others could reasonably be considered instances?

Posted by Mishkin Berteig at 05:51 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 22, 2007

Cancelled Iteration

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

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

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

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

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

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

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

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

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

Posted by Mishkin Berteig at 05:58 PM | |

January 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 04, 2007

Coaching and Agile Work

Someone recently said to me that I should offer individual coaching assistance to people based on Agile Work. This would be completely non-technical life/profession style coaching. It's an interesting idea. I don't think I'm quite ready for it, but here are a few links to coaching, life improvement, and related things.

We'll start with the Wikipedia entry on Coaching. This article provides some good definitions and links to a number of articles about specific types of coaching.

Esther Derby is a person I have met a couple of times through the agile community. She has a wonderful approach to training and facilitation. This article about coaching is a simple introduction to the tools of a coach.

This is a brand new blog about lifestyles. There are only two entries so far, but both are interesting. I enjoy the style of writing which is quite personable. The author seems to be positioning the blog as a lifestyle coaching resource.

And the International Coach Federation which seems to be one of the most well-known bodies that promotes coaching as a profession.

Posted by Mishkin Berteig at 09:44 PM | |

January 03, 2007

My First Challenge

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

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

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

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

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

Posted by Mishkin Berteig at 05:16 PM | |

January 02, 2007

Top Ten Most Popular Entries from 2006

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

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

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

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

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

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

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

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

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

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

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

Posted by Mishkin Berteig at 06:32 PM | |

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 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 19, 2006

Learning Circle - Interview with Garry Berteig (Updated)

The Learning Circle is a graphical description of the cyclical stages of learning and the qualities that are necessaary to go from one stage to the next. This method has been developed by the artist and teacher Garry Berteig as part of the application of Agile Work to his instruction. What follows is a short iterview with Garry after he attended one of my Agile Project Management / ScrumMaster Certification courses.

AA. Why should people be interested in this Learning Circle?

GB. Usually, the action/reflection cycle is one of trial and error... it's a very common experience for us, say learning to ride bike, through trial and error we actually learn. We also learn by modeling behaviors. We learn to speak, we learn to socialize. So that's a very short feedback loop. It's very effective.

What interested me about this model comes out of recognizing that my students didn't really know how to identify their own learning. And so they expected the teacher to determine what they had learned by giving them exams and other sorts of assignments with marks. Then I came across a development model in the "Building Momentum" document issued by the Baha'i World Center around 2003. There were very interesting considerations that focused on learning by using short three month cycle with reflection gatherings that ended a sequence of action, reflection, learning and planning. I thought it would be interesting to apply features of this Building Momentum document to my art classes because there it would be possible to increase the frequency of the cycle from three months to say six to twelve cycles in three months. Further to increasing the frequency of cycles, the student grouping in my class is quite diverse and it would be a way of testing what the model could generate in a group that was usein the model as a tool for artistic growth.

After explaining it to the students I tried it and applied as best as I could in the context of several art classes. The students were delighted with how easy it was to apply to their own lives! Not only to art. And so they bought into it as a method. Gradually we began to use the Action Reflection Learning Planning model in our method of conducting a critique. This circle was applied to work that the students did based in assignments. It became clear that this model had generated learning attributes in these students - these were exciting for me to recognize. I gradually recognized these attributes were arising from the movement from one stage to the next in the learning circle.

AA. Describe how this learning cycle was applied in your class.

GB. [In my sculpture class we used] a four-step process and in each step we use the circle as a critique method. The first step was to make an egg shape out of clay. Because it's the first time, it takes them about 45 minutes to make an egg shape about 6” long and 5” wide. Then I had them do it again. And this time it would only take them about 10 minutes. And the third time they did it they could probably make the same thing in about 5 minutes. Clearly, practice was the key learning in that first cycle or iteration. It gave the students an understanding that repetition reinforces learning and confidence. That's one iteration if you will. Making that set of three eggs is one group of activities that we then applied the learning circle to. We talked about the actions of doing it three times. Their reflection on those actions gave them an insight about learning which was that by repeating something they got better at it and they became more confident. An important outcome was that the first iteration established trust between them and me so they would accept guidance from me.

Then we began to do the second step in making a head and remember the head is based on the egg shape. I then showed them how to make a kind of a blank where you have the location for the eyes and the nose and the mouth in terms of the egg shape where the point of the egg is the chin and the large part is the back of the head. We do that several times. And each time we do it students become more confident in making this generic human head. As before, we have a critique and use the learning circle to help consolidate the experience with the students.

Then the third iteration is to bring a model into the studio, having a blank prepared, and now make a portrait of the model. What happens is that students end up with self-portraits! Because they have a prejudice, unknown to themselves of what the human face looks like. This prejudice of how a face should look is derived from looking in the mirror 10000 times and only looking at the model once.

In the reflection process then, some students resist this recognition of the result being mostly a self portrait. But as the group identifies details of the portraits they've made, for example the nose of the model is like a ski jump but the nose the student has made is like a hump... the student realizes they have made a self-portrait. This comes as a real eye-opener... a real revelation to the student! The insight that comes into focus is that they have predispositions. Therefore to make an action reveal it's true potential, detachment from preconceptions and/or benchmarks is necessary. So detachment is the first condition of really learning.

AA. So is detachment one of the attributes that you mentioned earlier?

GB. Well we haven't listed them, but it is one of the key learning attributes. Detachment comes into focus through the instrumentality of the group consultation and the role of the mentor in the reflection part of the learning circle.

The next thing that becomes evident is that in order to identify the learning that has occurred, there has to be a search for the principle that arises out of the action and the reflection. Identification of that principle may be quite elusive to the group and the individual at the stage they're at in the discipline. It may be [obvious] to the mentor, but not to the group. Certainly patience is required in that quadrant. However, when you identify that specific principle, for example the importance of contrast in two dimensional art, you move to the learning part of the circle and begin to investigate what other practitioners have donewith that principle as applied in their work. In our case sculptures or paintings. But it might be some practice in medicine. The learning is accelerated because of the work that other people have done. The acceleration of learning seems to be linked to love of learning. Love of the discipline is an attribute that emerges in the individual. There's a kind of fire or heat ... an urgency that comes along with it to learn more. It causes excitement in the person that is involved and the group that is involved. This love and this learning prepare a space or condition to receive guidance. Guidance comes in many forms but often seems to be a gift and a bit of a mystery.

In the individual [guidance] may emerge as inspiration and insight. In the group it emerges through consultation. It may also come from a mentor. The next thing that happens then is that what was learning now becomes conscious knowledge. This gives people courage. Conscious knowledge and courage seem to be hand-in-hand in the planning part of the process. It makes it possible to plan in a very strategic way and also in a very flexible way. It takes courage to go to a new level of action where you've never been before. And that's the power of this process. It caries people through identifiable stages with attributes that become strengthened as you go around and around and around the cycles. So that's basically why it's useful. The iterations generate detachment, search, love and courage. Attributes that give rise to the realization of individual and group potentials.

The term guidance is very significant. Because it's not prescriptive. It enables people to find solutions ...often unpredictable solutions... to the problems, the assignments.

AA. So what does this look like in your media class?

I won't go into detail, but I have the students do a single movie still a la Cindy Sherman that is a shot indicating a story that came before and will continue after that single momemnt. The first cycle is to develop a story. So the Action Reflection Learning Planning is to develop a story, present it to the group, take their responses and plan a modification to the story. We do that several times so that each student has a story that is coherent. That's the first step if you will.

Second step is to go and shoot, to photograph, the single shot that is a movie still that represents the whole story at some juncture in the story. Bring it to class, and the group reflects on it and makes recommendations to the author who learns something from the group, plans and re-shoots the still. The learning that emerges is powerful. Again, there's a kind of amazement at how perceptive individuals are about the image. And how you can't fool anybody. Of course, this creates in every student a search mode. They have to search within themselves for a better solution... and they do and they find it. It's really exciting.

The third step is a second still photo that rounds out the narrative of the story and the fourth step is to do a video of the scene, with all of the angles, lighting, make-up, costumes and mis en scene concerns looked after.

---

Garry Berteig is an instructor at Keyano College in Northern Alberta where he teaches Sculpture, Media and other visual arts. Some feedback from Garry's students about the use of Agile Work and Scrum has been posted here on Agile Advice before: Scrum Saves the Day for Media Student and A Student Documentary Film Project.

Posted by Mishkin Berteig at 12:16 PM | |

September 12, 2006

Yet Another Big Picture of an Agile Process

I created this image for a presentation targetted to management. It's a good high-level overview of what goes on in an Agile Work effort. Feel free to use this or the high res version... just keep the copyright notice on and put a link somewhere in your email/document/presentation/webpage/etc. back to Agile Advice. Suggestions on ways to improve the diagram would be greatly appreciated. I will try to update it... and maybe even get my incredibly talented visual artist brother Alexei to re-do it.

Here's the high resolution version, good for nice printed material: Agile Work - The Whole Process.

Posted by Mishkin Berteig at 08:52 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 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 | |

June 30, 2006

Agile Project Engagement Roadmap

(Parts of this posting were adapted from an email written by my business partner, Dale Kiefling)

We recently had the disconcerting experience of having a client cancel our engagement because they'd felt that we weren't being agile enough. In hindsight there were a number of reasons why this might have happened but I think the most important one was simply that we did not provide a clear overview of the engagement. This meant that the client was confused about the value of what we were doing. I myself am confused about how the situation arose. I thought we had been very clear but obviously that was not the case.

In our practice we typically combine a discovery phase and a prototyping analysis and design phase. What some people in the agile world might call iteration zero. For our client this discovery seemed open ended and they didn't have a clear understanding of how it fit into the project as a whole. This was a communication failure on our part. The process of discovery can indeed feel open-ended as it is the very nature of discovery to explore the domain of the business opportunity in an open way. The purpose of this "openness" is to find the appropriate scope, workflow, practical boundaries, and hidden benefits in an exploratory and visual manner.

The primary advantage of doing this work at a high level early on in the process is that it is much easier and cost-effective to identify boundaries and priorities on a whiteboard rather than during the construction phase or even during prototyping. We should have done a better job explaining this prior to our first discovering meeting which might have helped our client better understand our process and purpose. We also never really established a timeline beyond having one or more discovery meetings which may have added to their confusion.

Let's chalk this up to another lesson on the importance of managing client expectations.

Posted by David Chilcott at 01:16 PM | |

June 23, 2006

Managing "Leaderful" Groups

In agile development circles self-organizing teams are all the rage nowadays. And I often hear people bemoaning the "evil managers". And no doubt in many circumstances and organizations there is real work to do here and real dysfunction to resolve. But I'm less concerned with the analysis of what's wrong and more concerned with what can we do differently and better. IE: How can we develop the skills necessary to practice effective self-organization.

So what does it mean to be a participant in a "leaderful" group?

The implication of "leaderful" is that many or most of the people in the group are exercising leadership. It seems that leadership is necessary, humans can't engage in group activity successfully without leadership. Successful group action always requires leadership and leaders. Someone, at least one person, must think about the effort as a whole and not only about her or his individual role in it in order for the group effort to succeed. A group can have more than one leader, but must have at least one to function successfully. Leadership is thinking about the well-being of the group as a whole as well as that of the individual group members. The essential commitment of a leader is to see to it that everything goes well.

I assume that leadership is an inherent capacity of every person and that leadership is not a "special" role or activity only for "special" people. The skills of successful leadership can be taught, learned, mastered, and practiced.

Further, I assume that people are fundamentally peers and that we are all doing the very best that we can at the moment. So the question becomes how do we reconcile assuming leadership with our peers? And how do we support each other in developing our leadership skills together?

More on this later...

Posted by David Chilcott at 04:58 PM | |

June 15, 2006

Upcoming Agile Training and Certification

Agile training including ScrumMaster Certification, Introduction to Agile Work and Adult Learning for Agile Coaches. Toronto, Edmonton, Calgary, Ottawa, Beijing. Reserve your spot on the schedule of public agile courses offered by Berteig Consulting Inc.

The Berteig Consulting agile training courses are designed to help the attendees of the course learn about agile methods, make the needed mental shift towards agile concepts, and start the change in their habits of behavior. We do this in the following ways:

• Extensive simulation and discussion exercises to practices and investigate core agile principles and practices
• Opportunity for participants to see agile methods modeled (demonstrated) by the instructors in the running of the training course itself
• Several "Aha!" exercises designed to viscerally affect attendees' mental models and kick-start the shift to agile thinking
• Full disclosure of the difficulty of implementing agile methods and the radical change of thinking and habits required
• Reflective exercises about the learning process itself so that the attendees learning needs are dynamically met during the training course
• And of course, sufficient time for in-depth coverage of the materials so that most questions about agile methods, agile practices, agile experience and agile principles can be answered

Posted by Mishkin Berteig at 12:01 AM | |

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 20, 2006

An Introduction to General Systems Thinking

I recently completed reading An Introduction to General Systems Thinking by Gerald M. Weinberg. Since it was mind-blowingly fantastic, I thought I should probably write a brief review of it so you-all can check it out!

The Subject

This book is about science, philosophy, behavior, organizations, organisms, problems, solutions, faith, reason, and everything in between. Specifically, it is about a general approach to dealing with systems given the limitations of our human abilities.

The Ideas

One of the strongest ideas in the whole book is that there is a class of systems for which we have only very poor tools to understand them. These systems, which he calls "organized complexity" are contrasted to "organized simplicity (machines)" and "unorganized complexity (aggregates)". Machines can be dealt with purely analytically and in a deterministic manner. Aggregates can be dealt with statistically. Systems that are in the organized complexity category are too complex for a purely analytical approach but too simple for a reasonable statistical analysis. The book is focused on methods for dealing with this class of systems.

The Writing

Mr. Weinberg's writing is, first and foremost, engaging. He writes in an informal voice that is a wonderful complement to the subject matter. Even with the informal tone, he is nevertheless able to communicate some tricky ideas with a great deal of precision and clarity. His use of examples, diagrams, stories and quotes throughout the book is excellent. Although I did not do the exercises he includes, upon reading them, I was satisfied to see that they are all interesting. Since I intend to re-read the book in six months or so, I will also publicly commit to doing a good chunck of the exercises too. Maybe you'll see some of my efforts here since many of them are apropos to Agile Work.

How Does This Apply to Agile Work?

Much of the emphasis in agile methods is on the intractability of building a perfect plan for a set of work (particularly in software projects). The group of human beings that are building something is in itself a system of "organized complexity". As a result, it is impossible to treat that group of people as a system that can be made to work in a deterministic manner. We simply can't account for all the variables. At the same time, we would like to have a lot more certainty about the behavior of the group than we could just using statistical methods. (Check out Systematic HR for some related articles.) Agile methods help us find this middle way that gives us a very good shot at reaching our goals, but acknowledges our inability to determine precisely how we'll get there. A good understanding of Systems Thinking helps us comprehend the necessity and applicability of agile methods.

The Table of Contents

The chapter and section titles of this book tell a great deal about the scope of the work. I have reproduced the table of contents here for your reference.

Chapter 1 The Problem
- The complexity of the World
- Mechanism and Mechanics
- The Square Law of Computation
- The Simplificiation of Science and the Science of Simplification
- Statistical Mechanics and the Law of Large Numbers
- The Law of Medium Numbers

Chapter 2 The Approach
- Organism, Analogy, and Vitalism
- The Scientist and His Categories
- The Main Article of General Systems Faith
- The Nature of General Systems Laws
- Varieties of Systems Thinking

Chapter 3 System and Illusion
- A System Is a Way of Looking at the World
- Absolute and Relative Thinking
- A System is a Set
- Observers and Observations
- The Principle of Indifference

Chapter 4 Interpreting Observations
- States
- The Eye-Brain Law
- The Generalized Thermodynamic Law
- Functional Notation and Reductionist Thought
- Incompleteness and Overcompleteness
- The Generalized Law of Complementarity

Chapter 5 Breaking Down Observations
- The Metaphors of Science
- Boundaries and Things
- Qualities and the Principle of Invariance
- Partitions
- The Strong Connection Law

Chapter 6 Describing Behavior
- Simulation - The White Box
- State Spaces
- Time as a Standard of Behavior
- Behavior in Open Systems
- The Principle of Indeterminability

Chapter 7 Some Systems Questions
- The Systems Triumvirate
- Stability
- Survival
- Identity
- Regulation and Adaptation
- The Used Car Law

---

Also, check it out, Mr. Weinberg has started a blog on writing fiction. He also helps run the AYE Conference (amplifying your effectiveness).

Posted by Mishkin Berteig at 05:18 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 | |

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

December 22, 2005

Acting on the Essential Advice for Agile Coaches

In the entry "Essential Advice for Agile Coaches" I mentioned seven responsibilities that we have. These seven responsibilites can be used as a framework for self-evaluation and goal setting. I have created a simple spreadsheet tool to help track this work.

---

OpenOffice.org

Agile Coach Assessment.ods

Sample of Agile Coach Assessment.ods

---

Microsoft Excel

Agile Coach Assessment.xls

Sample of Agile Coach Assessment.xls

---

Terms of Use: Copyright 2005, Berteig Consulting Inc. No warranty express or implied, blah dee blah... If you want to give people copies, please go ahead just don't take out the link to the help page. If you want to distribute modified copies, you must send me a copy first with permission to use your modifications if I like. If I find out you've been bad, I might not like you as much any more... then again, I'm Canadian so I'll probably say "sorry!"

Posted by Mishkin Berteig at 03:23 PM | |

December 19, 2005

Penny Queueing Exercise - Lean Process

This simple simulation exercise helps people to understand the efficiency that can come from moving away from a waterfall or large batch process. The exercise can be done with 20 pennies, 5 people and a clock with a second hand.

The exercise simulates processing work in the form of flipping pennies from heads to tails and back. Four people in the Team sit at a table or other hard surface in a line beside each other. The surface must allow for easily sliding the pennies. The fifth person, the Manager, starts the process and times it. The Team will process the pennies twice...

First Pass - Waterfall Large Batch
1. The Manager gives all the pennies to the first person in the Team and notes the start time. The pennies should be in a big jumble.
2. The first Team member chooses a side (heads or tails) and flips all the pennies onto that side.
3. The person with the pennies passes the whole pile of pennies to the next person. That person then flips all the pennies to the other side.
4. Repeat step three until the last person on the Team has flipped them.
5. The manager notes how long this took.

Second Pass - Waterfall Small Batch
1. The Manager gives all the pennies to the first person in the Team and notes the start time. The pennies should be in a big jumble.
2. The first Team member chooses a side (heads or tails) and flips all the pennies onto that side. As each penny is flipped, the Team member passes it along to the next person.
3. Each person flips their pennies as quickly as possible and immediately passes them on to next person.
4. Do this until they are all flipped.
5. The manager notes how long it took for the first penny to go through all four Team members, and how long it took for all of them to finish.

Optional Third Pass - Parallel Small Batch
1. All the pennies are in a random jumble in the middle of the table.
2. One Team member calls heads or tails and the manager notes the start time.
3. Each person grabs a penny at a time from the pile.
4. All working at the same time as quickly as possible, each person flips the pennies first so they are all the same as the original call if needed, and then three more times
5. As each penny is finished 3 or 4 flips (as appropriate) it is pushed into a separate done pile in the middle of the table.
6. The Manager records the time for the first penny to be put into the done pile and for all of them to be completed.

---

I heard of this exercise through the agile coaching grapevine, originally from one of my apprentice coaches. After attempting to trace it back to its origins, I believe that it may originate in some lean training, but I am uncertain at this time. I have made my own modifications to the original exercise and these are reflected above. If I am able to properly acknowledge the origin of this exercise, I will update this entry to do so.

Posted by Mishkin Berteig at 11:53 AM | |

December 11, 2005

The Power of Iterative Delivery and Adaptive Planning

As a coach, it is nice to have some simple ways to show people the power of Agile methods. This quick little exercise is an excellent way to demonstrate the weakness of the waterfall approach to working with up-front requirements analysis versus the power of the agile iterative/adaptive approach. UPDATED 20051213!

Find the Number

Work in pairs with someone you don't know. One person will choose a number at random between 0 and 1000. The other will try to figure out the number chosen. You have sixty seconds to communicate the number but...

FIRST METHOD:

1. Write down the number so the other person can't see it.
2. Come up with clues about the number. You cannot use any math either explicitly or implicitly in your clues. E.g. if the number is "256" here is a good clue: "the first and second digits are rotationally symetrical on an LED display", and here is a disallowed clue: "it is an even number" (uses a mathematical feature).
3. As you figure out clues, tell them to the other person.
4. The person trying to determine the number cannot ask questions.
5. Before the sixty seconds are up, the person must state a number they think is correct (and the other person must tell them if they are correct). Only one "guess" is allowed.

SECOND METHOD:

1. Switch roles with your partner.
2. Write down the number so the other person can't see it.
3. The person trying to find the number guesses a number at random.
4. The person who knows the number tells the other person if the guess is low, high or correct.
5. Repeat steps 3. and 4. every six seconds.

Debriefing

1. How was the first part of the exercise like the waterfall method? Was it successful/how close did you get?

2. How was the second part of the exercise like the iterative/adaptive method? Was it successful/how close did you get?

3. What other interesting things did you notice about this exercise?

Acknowledgements: the second part of this simulation exercise comes from a discussion with Jim York of CCpace.

Posted by Mishkin Berteig at 08:39 AM | |

December 05, 2005

Mastering Agile Work

Not everyone will master the techniques of Agile. Mastery of any discipline takes much more than reading a few books and taking a few courses. Here's my take on mastery...

Mastery of any discipline depends on four conditions:

1. Will. If you have the will to master a discipline, you will put in the effort required.

2. Assistance. Mastery requires an environment which supports the learning process. The learning opportunities available must fit with your personal learning style.

3. Constraints. In order to truly master a discipline, the process of mastery must include dealing with constraints and other challenges. Learning from failure is just as important as learning from success.

4. Opportunity. A person must have the time or the ability to free the time to work on mastering a discipline. The amount of time necessary depends on one's starting point in personal capabilities.

Mastering Agile Work

Mastering a discipline takes more than just learning the practice and being able to do it well. There are in total four components to a discipline that need to be accounted for:

1. Theory. Agile Work theory includes Lean and queueing theory, adult education, organizational learning, systems theory, and economics. Understanding this theory allows a person to extend their mastery of Agile into unfamiliar situations.

2. Practice. The practice of Agile Work has simple basics, but includes a vast array of combinations, minor practices, and disfunctional practices to be avoided. Experience actually trying, failing and succeeding at a majority of these practices is necessary for mastery.

3. History. Understanding how Agile evolved, who were the leaders in the field, and various anecdotes about Agile implementations are critical for being able to link our own activities into a larger community. This larger community allows us to understand the constraints of Agile, and provides a peer group to share with and learn from. Mastery can only be ongoing in a historical context.

4. Criticism. No person can grow in their understanding of a discipline without also understanding how to do critical reflection of one's own work and the work of others. Fortunately for those interested in Agile, this process of critical reflection is built into the Agile process and practices to a large degree.

Call to Action

The vast majority of current discussion in the Agile community is around practices and focused on software development specifically. There is only a little work being done in the Theory, History and Criticism aspects of the discipline. In order to become a fully respected discipline, all aspects need to be given appropriate weight.

Those of you who consider yourselves masters of the Agile practices, can you see yourselves investigating these other aspects? The question "why?" is just as important, if not more so, than the question "how?" Let's investigate these wonderful methods of ours.

Posted by Mishkin Berteig at 12:13 PM | |

November 15, 2005

Salutogenesis and Agile

Twenty-five years ago American-Israeli Medical Sociologist, Aron Antonovsky developed the theory of salutogenesis. As opposed to the traditional pathogenic model of medicine focused on the study of disease, salutogenesis is the study of health. Since then, his work has been integrated into the field of public health and health education. This asset or strength based type of approach to individual or institutional development has been found in other fields such as organizational development and community development. In organizational development the field of Appreciative Inquiry and in community development the Asset Based Community Development model share the essential premises of salutogenesis. Quoting Garmezy, Antonovsky highlights the medical professions focus on deficits:

our mental health practitioners and researchers are predisposed by interest, investment and training in seeing deviance, psychopathology and weakness wherever they look.

This type of approach to work based on weakness and deficit can be found in most of our organizations. It seems to me that although Agile exposes inefficiencies and problems in organizations, it's focus never-the-less is to build on strengths and assets. It is in this light that I have been thinking about Antonovsky's work and what it can offer to Agile.

Antonovsky came to this theory of salutogenisis when he carried out a study on Israeli women going through menopause. He found that there were a number of women who, according to all indications of the pathogenic model, should be suffering severe symptoms (because they faced severe stressors which cause illness). But they were not suffering at all. To his surprise he discovered that these women happened to be survivors of concentration camps. He found certain qualities in these women that resulted in what he called a higher “Sense of Coherence” than the other women.

Sense of Coherence is made up of three factors; comprehensibility, manageability, and meaningfulness.

Comprehensibility means that whatever happens to a person, she is able to make sense of it and understand it, that is, the challenge is in some way "structured, predictable, and explicable." Manageability means that either the resources are available to one to meet the demands posed by the stimuli,or one has a way to find them. Meaningfulness involves having a sense of meaning in the important areas of one's life or recognizing "these demands are challenges, worthy of investment and engagement."

Antonovsky found meaningfulness to be the motivational factor of the three, although he also found that all three mutually reinforce one another. For example if one has a high sense of comprehensibility but is low on the other two, one ends up not having the motivation to find resources and soon after this causes comprehensibility to be lost. If one is high on meaning and missing the other two, Antonovsky explains that there is a good chance to find the other two.

The theory of Salutogenisis may provide researched and proven reasons why Agile is so empowering for people. This research may also provide more insight into how to deepen Agile experiences to higher levels of empowerment. Agile methods help people to make sense of the market place by allowing for iterative delivery and adaptive planning, thus increasing their level of comprehensibility. Iterative delivery, adaptive planning and the concept of amplifying learning are all conducive to increased sense of manageability. Because people spend most of their time at work, it is quite important that they feel a sense of meaning in their work. The concept of empowering the team and the practice of self-organized teams and appropriate metrics can contribute to increased sense of meaning in one's work.

Salutogenic food for thought for the Agile practitioner:

Antonovsky associated comprehensibility with consistency which he defined as "the extent to which one’s work situation allows and fosters the clarity of seeing the entire work picture and ones place in it, provides confidence in job security, and supports communicability and feedback in social relations at the workplace".

How can the concept of consistency be promoted in Agile projects?

Manageability is related to under load/overload balance which is defined as "the availability of resources to the individual and to the collectivity within which there is interaction to get the job done well" and "...the extent to which the work situation has room for allowing potential to be utilized in substantively complex work." The opposite of the former results in overload and the opposite of the latter is a situation of under load.

How can Agile projects guard against overload? How can an Agile coach and Agile teams fully utilize the capacities of its members?

Meaningfulness is closely associated with participation in shaping outcomes. Antonovsky explains beautifully the relationship between these two concepts:

When others decide everything for us-when they set the task, formulate the rules, and manage the outcome-and we have no say in the matter, we are reduced to objects. A world thus experienced as being indifferent to what we do comes to be seen as a world devoid of meaning.

In light of the concept of meaningfulness how can the principle of self organized team and shared decision making be deepened in Agile work?

Reference:
Antonovsky, Aron (1988). Unraveling the Mystery of Health: How People Manage Stress and Stay Well (Jossey Bass Social and Behavioral Science Series)

Posted by Shabnam Tashakour at 07:50 AM | |

October 21, 2005

Authenticity in Teaching

By Dr. Patricia Cranton

"I value and see myself as an authentic teacher. To me, authenticity means three things: the expression of the genuine self in the community, understanding how others are different from us without attempting to make them into our own image (helping others discover their authenticity as a way of fostering our own authenticity), and critically participating in life—questioning how we are different from the community and living accordingly."

http://www.stfx.ca/people/pcranton/

Posted by Shabnam Tashakour at 12:03 AM | |

October 16, 2005

Notes from The Sixth International Transformative Learning Conference Michigan State University Oct 6-8, 2005

Debra Langon and Ron Sheese Professors at York University

They have a transformative learning research project with their first year sociology and psychology students. Their focus is on incorporating transformative learning into their practice as educators.

Principles:
Engagement, deep learning v.s. surface learning, reflection, caring and at the center of all this is collaboration

Old approach to learning is just a critical thinking approach. They use the work of Thar Bacon on constructive thinking "Playing the believing game" beyond just logic.

They prize listening as much as speaking so that quiet students are not marginalized.

They have been surprised that simply stating a value like caring in their project has affected the students and also changed their own inward orientation towards their work. Students have repeatedly reported that feeling cared for in the classroom has enriched their learning experience. The focus on caring has also rejuvinated their work as professors.

Posted by Shabnam Tashakour at 11:54 PM | |

October 15, 2005

Notes from The Sixth International Transformative Learning Conference Michigan State University Oct 6-8, 2005

"What Might Education for Transformation Look Like?"
Dr. John M. Dirkx, Michigan State University, Oct 8

Ego and rationality are servants of the education process. Learning centered on text (i.e. books, students writing, teachers writing and dialog between, or individual etc...) therefor forming a dialogical relationship of teachers, students, subject and context.

Jung speaks of pulling us out of the womb - individuation- this is about having a sense of self so that one can experience union and communion with others.

Create an opening
Engage the interest of students in the subject by activating the emotions, cognition and memory. Learning is fundamentally connected to emotion. Emotion is essential to the process of thinking, analysis and synthesis.

Construct and hold together patterns of information gathered around text. Use text as basis and have student re-story (that is, students use the text to create their own story).

Cultivating creative and critical thinking
Encourage analytic critique and synthesis and imagination. Foster the dialectic of intuition and analysis.

Fostering understanding - seeing the world through the "eye of the heart" heartfulness...building connections... deep relatedness or intimacy with subjects

Nurturing wisdom - learning to act wisely
Stay with ambiguity, cultivate a sense of wonder, put aside quest of certainty. Discovering the nature of the self "the transcendent self." Deepening what it means to be in the world. Find out what we love.

What is transformative learning?
Holding the tension between:
Feminine and masculine
Agency and communion
Autonomy and interdependence
Will and willingness
Intuition and analysis

Transformative Learning has to be:
Experience based
Subjective
Depth instead of breadth
Reflective
Use of story
Imaginative and symbolic
Embodied (how the body takes on what it feels, for example when I am teaching my body also comes alive)

Further Reading:
"Nurturing the Soul in Adult Learning." John M. Dirkx
"Strategies of Transformation Towards a Multicultural Society." David Ablos
"Fostering Critical Reflection in Adulthood". Jack Mezirow
"From Information to Transformation: Education for the Evolution of Consciousness." Tobin Hart

Posted by Shabnam Tashakour at 12:35 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 | |

September 29, 2005

Transformative Learning and Agile

It seems to me that most people who have had any kind of success on serious projects, or in life, can probably point to a profound collaborative experience at the core of that experience. In my last posting, "tools vs. capabilities" I said that because Agile is fundamentally a process of collaboration and our culture is fundamentally is a culture of contest, we need to recognize that learning Agile requires a transformation at the level of character more than methodology. Despite the fact that we may have had profound experiences with collaboration, because we are also deeply influenced by our environment, there are limits to what we can understand about it. We need not look further than the agile disciplines to see how most of our working and social practices are not supportive of Agile perspectives. For example empowering the team and the concept of self-organizing team is a direct challenge to most of our social, economic, cultural, community and familial structures which are essentially hierarchical. The discipline of amplifying learning is a direct challenge to the practice of excessive specialization which manifests itself in the form of expert elitism. How can any one of us ever hope to have a culture of learning and innovation if we come from a culture of expertise and hierarchy based on that expertise?

This is where transformative learning comes in. Agile requires of us not just an ordinary, but transformative learning experience. When we learn, we take something new and fit it into an old category or assign an old meaning to it. Categories are ways in which we organize our learning, they can also be called frames of reference. If we encounter an experience for which we have no category it is hard to understand it. For example have you ever been in a conversation or taken part in a course where what you were learning was so foreign to you that you didn't even know what kinds of questions to ask to help you understand it?

Our frames of reference are shaped through the influence of our culture, language, and experiences, which all interact to set boundaries to future learning. This is because outside of these categories it is impossible for us even to register something new, let alone seek out its reality in an unprejudiced manner.

How often do you find yourself in a new learning situation where you feel overwhelmed, frustrated or even angry? It is possible that at those times you may be at the threshold of a transformative learning experience. You can have two reactions: one would be to dig deep and try to figure out why you are disturbed and see what insights you are led to and the other would be to just give up on the idea and find arguments against it.

Another way to recognize a potential opportunity for tranformative learning is to reflect on the following question: have you ever had an experience where you were faced with some new learning and because you have had a similar experience or because for some reason you see yourself as an expert in that field you have not been able to derive the proper learning from that experience? You may have realized this at a later time after numerous interactions with a similar experience where you slowly started to recognize gaps in your own understanding.

In order to derive the full benefit of a new experience that doesn't fit into the realm of our experience we must have a transformative learning experience. A transformative learning experience is an experience that requires of us to examine the values and limitations of our old categories and assign new meanings to them. This does not mean that all of our previous learning is invalid. A transformative learning experience allows us to expand our frames of reference to allow for more complexity and at times possibly to integrate two previously perceived dichotomous approaches.

For a detailed introduction to transformative learning theories, its thinkers and history check out this link:
http://en.wikipedia.org/wiki/Transformative_learning on Wikipedia.

Posted by Shabnam Tashakour at 10:50 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 15, 2005

Personal Philosophy of Adult Education

The following is my approach as an educator to my work in community and organizational development. I have come to this understanding mainly through experience, a great deal of mentoring and study.

Please note that when I use the term “teacher” in this document I also mean consultant, mentor, coach etc. The term “student” is also interchangeable with organization or community. The term education is interchangeable with organizational or community development consulting.

Validation: a starting point

Education should start from, affirm and validate the experience, insights and knowledge of the individual. This is a foundation for education that honours and respects the student. Recognizing the nobility of the student allows her an active role in her own learning. The role of the teacher is to facilitate learning by drawing on the experience of the student, to build on that experience through the acquisition of new insights, knowledge and skills.

Learning must be self-directed. The teacher may have a number of wonderful things to teach, but if the student does not believe that they are relevant to her, she will not be engaged. This is especially true for teachers who are working in communities that they are not a part of. The teacher must engage in careful investigation in order to understand the situation of the student, which includes attentive listening, as well as a genuine interest in the needs of the student, before proceeding along any line of instruction. Taking her cue from the students, the teacher must work with the individual / group to create a learning environment in which everyone takes responsibility for their own learning. In this kind of environment the teacher is not an expert and does not do the students’ learning for her. The teacher can use questions to assist the student to understand, instead of delivering answers. The teacher should also encourage an environment of learning that recognizes mistakes as part of the learning process. The learning environment should create in the student a hunger for the acquisition of knowledge, insights and skills beyond the direct experience with the teacher.

Encouragement: the key to self-directed learning

Once the experience of the student has been validated and her needs established, education should be challenging but not obtrusive and challenges must be presented with respect and encouragement. Encouragement versus excessive criticism leads to individual initiative instead of paralysis. The natural result of an encouraging and challenging learning environment is self-discipline and self-correction instead of external discipline (control) and constant external correction.

A transformative, holistic approach centred in humility and service

The learning environment should foster humility in both the student and teacher. Most contemporary approaches to education are materialistic; the student pays, studies, receives a degree, becomes an “expert”, etc. The whole educational experience, from the teachers to administrators, cultivates in the student a sense of self is that is based solely on the expertise and knowledge gained. The “Expert” attitude in the community development environment is often not useful because the work in the field is so complex. Many stakeholders have keys to the process, as a result, the “expert” attitude devalues the knowledge of others and tends to taint the path to solutions with conflict and ego. Another consequence of the expert mentality in the community is dependency; people are divorced from the solution to problems that they all contribute to and to which they all hold the keys. Instead of drawing on the knowledge of the stakeholders, the expert renders her own knowledge most valuable which in turn causes them to discard volition and succumb to a state of perpetual dependency on one expert after the other. Community members or institutions are robbed of the ability to play a central role in their own lives as a direct result of being robbed of opportunities to play central roles in the decision-making process of their community.

With humility at the centre of all learning, the purpose of education becomes transformation. We learn so that we, our communities and our institutions can improve and change for the better. Also as learning is applied to community efforts, individual capacity unfolds and is developed. Learning for its own sake is valuable, but learning for positive social change, makes the acquisition of knowledge, skills and insights relevant and engaging in the face of community development challenges. Learning then becomes intimately connected with action and is corrected and refined through action. This infuses a powerful sense of purpose and meaning in the learning process, especially as successes are realized.

Principle-based approach facilitates ownership

Education should cultivate a sense of personal ownership in the learning process and community life. Fostering a sense of personal ownership comes with educating students to have a mature perspective about their own learning as well as the changes they desire to implement in the community. It involves helping students learn the capability of ‘becoming’ the change that they want to see, as well as finding positive starting points in desperate situations and building on them. A mature outlook demands that students have a principle-based approach to problem solving versus a rule-based approach. Education then becomes not only a process of acquiring knowledge but centred on capacity building for individuals, institutions and groups. Fostering the development of capacities needed to overcome obstacles also requires a principle-based approach, embodying principles such as perseverance, human rights and dignity, building unity in diversity etc.

Integration and balance of methods essential

Education should be methodical and balanced. It should aim to acknowledge, validate and employ different learning paradigms: those of science, spirituality, culture and the arts. Systems of education that value science above the arts or spirituality are destructive to the individual and community as they create an imbalanced view of the world and rob people of a diversity of perspectives and tools that they need to face complex challenges. An educational program should strive to address the mental, emotional, spiritual and physical needs of students and not focus too much on merely one dimension of life. This is especially important in communities that have experienced extreme marginalization (colonization, oppression) where healing and wellness must play a significant role in the learning process.

Modelling Change

A key ingredient to success in transformational education is the example of the educator. As people, naturally we do what we know and what we have experienced. In order to change our patterns of behavior we need to begin having fundamentally different experiences than what we have known. The educator must be able to assist in the creation of such experiences. To do this she must be capable of modelling what is being taught and through constant critical self-reflection strive to exemplify in every action empowering ideals.

Summary

Learning and education are indispensable to all community efforts for positive change. The job of an adult educator is to assist individuals, the community and its institutions to adopt a posture of learning. This begins with working with the experience of the student, fostering self-directed learning and follows as the teacher interacts with the student to challenge and assist her to new levels of learning. With humility at the centre of all learning efforts, dependency on “experts” can be replaced with volition and independent decision-making. The potential of the individual further unfolds as she applies her learning to service to the community. Attention to capacity building and cultivating a sense of personal ownership -in the process of learning and community building- deepens the experience and truly engages the student in taking an active role in the development of her life. Utilizing all systems of learning in the education process ensures balance of methods and helps cultivate the infinite and diverse capabilities of human potential. Ultimately the success of an educator rests on the degree to which she is able to model the change she is fostering.

Posted by Shabnam Tashakour at 05:04 PM | |

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

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 13, 2005

Amplify Learning

Learning is the result of both encountering new experiences and deliberate experimentation. Learning creates new knowledge, increased volition and improved action.

Some of people's best learning comes from “failure”. An essential component of learning is feedback.

Learning and feedback can be amplified in several ways. Provide opportunities for learning through books, training courses, coaching, deliberate exposure to diverse work, and deliberate experimentation. Frequently ask the questions “why?” and “how?” and answer the honestly and deeply. Increase the level and quality of communication among the stakeholders and team members. Inspect work in progress frequently or even continuously. Learning accelerates greatly if a culture of learning is created where individuals feel free to experiment and take initiative even on critical aspects of the work.

Learning and feedback support all three agile principles. People become more effective creators as they learn. People are better able to adapt to and embrace change as they learn. And a person's span of perception increases as they learn. Any increase in learning or feedback leads to an increase in the manifestation of the principles.

Learning and feedback can be amplified rapidly, but an empowered team is necessary to effectively take advantage of this amplification. If a team is not empowered, then rapid learning can lead to frustration. Amplified learning and feedback result in excitement, enthusiasm and playfulness, rapid problem solving, high quality work results and satisfied stakeholders.

An excellent analysis of learning at a social or group level is presented in Progress and Its Problems by Larry Laudan. In this very well written book, Laudan takes a look at the history and philosophy of science and develops a model for learning that is applicable to the development of agile methods.

Posted by Mishkin Berteig at 01:12 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 | |

April 20, 2005

Scrum Scorecards - Measurements to See Progress of Agile Adoption

Two interesting visual presentations of the progress of adoption of Scrum practices. These are marginally software-specific but could very easily be adapted to non-software agile work situations.

http://wiki.scrums.org/index.cgi?ScrumScoreboard

Posted by Mishkin Berteig at 04:31 PM | |

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