Agile Advice

February 19, 2006

Three Concepts for Value Stream Mapping

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

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

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

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

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

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

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

Value Stream Mapping Process Step Template

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

---

OpenOffice.org
Value Stream Map Process Step Template

---

Microsoft Excel
Value Stream Map Process Step Template

---

Adobe PDF
Value Stream Map Process Step Template

Posted by Mishkin Berteig at 08:56 PM | |

February 17, 2006

Timeboxing: A Critical Agile Work Practice

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

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

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

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

---

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

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

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

Posted by Mishkin Berteig at 01:18 AM | |

February 14, 2006

Daily Status Meeting Disfunction

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

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

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

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

More details about the Daily Scrum from the Scrum methodology.

Posted by Mishkin Berteig at 05:35 PM | |

January 25, 2006

The Pros and Cons of Short Iterations

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

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

Pros of Short Iterations

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

Cons of Short Iterations

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

Guidelines: Choosing Iteration Length

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

What We Did Way Back When...

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

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

Posted by Mishkin Berteig at 01:39 AM | |

December 15, 2005

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

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

How Bad is This?

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

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

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

Planning Failure

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

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

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

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

Obstacle Removal Failure

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

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

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

Failure to Abort the Iteration

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

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

Posted by Mishkin Berteig at 03:30 PM | |

December 08, 2005

Essential Advice for Agile Coaches

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

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

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

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

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

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

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

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

---

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

Posted by Mishkin Berteig at 05:35 AM | |

December 06, 2005

Agile Work for "Flow Projects"

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

Self-Organizing Team

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

Iterative Delivery

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

Adaptive Planning

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

Test-Driven Work

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

Maximize Communication

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

Appropriate Metrics

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

---

Agile Work Axioms and Disciplines

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

Posted by Mishkin Berteig at 02:52 PM | |

More on Daily Status for Self-Organizing Teams

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

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

Posted by Mishkin Berteig at 07:25 AM | |

November 11, 2005

Agile Planning

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

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

Posted by Mishkin Berteig at 08:54 AM | |

November 10, 2005

Agile and Defined Processes

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

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

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

Posted by Mishkin Berteig at 02:35 PM | |

November 08, 2005

Retrospectives

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

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

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

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

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

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

Posted by Mishkin Berteig at 07:36 PM | |

November 02, 2005

Iteration Progress Information Radiators

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

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

Posted by Mishkin Berteig at 01:03 PM | |

October 11, 2005

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

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

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

Self-Organizing Teams

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

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

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

Pitfall: Speculative Work

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

Pitfall: Failing to Deliver

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

Pitfall: No Barriers

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

...

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

Posted by Mishkin Berteig at 02:42 PM | |

October 10, 2005

Agile, the Adult Educator and Ethical Considerations

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

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

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

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

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

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

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

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

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

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

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

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

Posted by Shabnam Tashakour at 09:35 PM | |

October 07, 2005

Agile Coach/Mentor Job Description (Process Facilitator)

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

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

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

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

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

Suggestions and ideas are greatly appreciated!

Posted by Mishkin Berteig at 12:33 PM | |

October 05, 2005

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

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

Posted by Mishkin Berteig at 02:09 PM | |

September 27, 2005

Tools Versus Capabilities Approach To Agile Training

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

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

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

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

Posted by Shabnam Tashakour at 12:44 PM | |

September 26, 2005

Wideband Delphi Estimation Technique

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

Posted by Mishkin Berteig at 12:40 AM | |

September 06, 2005

Process Facilitator Role

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

The Process Facilitator is a person who is both experienced with agile work and trained as a facilitator. The Process Facilitator acts as a coach to the team to monitor the process, foster the understanding of the agile work axioms, the development of the agile work disciplines and adherence to the agile work practices.

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

Posted by Mishkin Berteig at 12:27 AM | |

August 25, 2005

The Role of the Process Owner

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

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

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

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

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

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

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

Posted by Mishkin Berteig at 09:32 AM | |

August 23, 2005

Agile Offshoring References

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

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

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

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

August 18, 2005

Using Agile Work Practices to Develop a Seminar

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

Iterative Delivery and Adaptive Planning

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

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

Test-Driven Work

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

Appropriate Metrics

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

The Other Practices

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

Posted by Mishkin Berteig at 08:32 AM | |

August 11, 2005

Agile Work Roles

The Process Owner is responsible for the process used by the team
- Keeps the team on-track by gently reminding the team of the process rules, e.g. having a completed chunk of work at the end of the iteration
- Facilitates process improvements, usually by doing a process reflection between iterations
The Product Owner is responsible for working with stakeholders to develop the work list and understanding, maintaining and prioritizing it
- Often the Product Owner is responsible for working with the team when the team has questions about items in the work list
The Team Members are responsible for organizing and executing the work they have committed to doing
- Team members are expected to extend themselves beyond their field of specialization

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

Posted by Mishkin Berteig at 10:03 PM | |

August 10, 2005

Optimizing a Team Room

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

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

Posted by Mishkin Berteig at 03:13 PM | |

August 06, 2005

Generalizing Specialists

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

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

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

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

Posted by Mishkin Berteig at 08:05 PM | |

August 04, 2005

Just In Case You Haven't Seen It Yet

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

Posted by Mishkin Berteig at 11:41 AM | |

August 01, 2005

Broadcast Mode Communication

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

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

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

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

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

*Highly recommended!

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

Posted by Mishkin Berteig at 11:18 AM | |

July 30, 2005

A Simple Rule of Thumb

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

Posted by Mishkin Berteig at 11:09 PM | |

July 28, 2005

Applicability Matrix Tool for Colocated Team

Notes:

1. Individuals are automatically co-located with themselves.

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

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

Posted by Mishkin Berteig at 11:46 PM | |

July 25, 2005

Applicability Matrix Tool for Iterative Delivery

Notes:

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

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

Posted by Mishkin Berteig at 03:14 PM | |

July 23, 2005

Book Review - "The Tipping Point"

Overview

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

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

Assessment

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

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

Relevance

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

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

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

Posted by Mishkin Berteig at 09:59 AM | |

July 22, 2005

Applicability Matrix Tool for Self-Steering Team

Notes:

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

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

Posted by Mishkin Berteig at 06:38 PM | |

July 19, 2005

Applicability Matrix Tool for Adaptive Planning

Notes:

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

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

Posted by Mishkin Berteig at 10:39 PM | |

July 18, 2005

Sociometry and Team Building

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

Team Building

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

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

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

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

Posted by Mishkin Berteig at 11:09 AM | |

July 17, 2005

A Nice Little Intervention

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

Posted by Mishkin Berteig at 02:42 PM | |

July 16, 2005

Applicability Matrix Tool for Information Radiators

Notes:

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

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

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

Posted by Mishkin Berteig at 06:45 PM | |

July 15, 2005

Applicability Matrix Tool

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

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

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

Posted by Mishkin Berteig at 11:49 PM | |

July 14, 2005

Innovative Teams and Change Agents

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

Posted by Mishkin Berteig at 10:08 PM | |

July 08, 2005

Interesting Study about Office Organization

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

Posted by Mishkin Berteig at 11:12 AM | |

July 04, 2005

Reporting for Accountability - Article by Geoffrey Slinker

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

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

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

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

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

Posted by Mishkin Berteig at 09:30 PM | |

June 27, 2005

What If Something Hurts?

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

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

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

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

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

Posted by Mishkin Berteig at 11:30 PM | |

June 24, 2005

Big Visible Charts

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

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

Posted by Christian Gruber at 09:19 AM | |

June 23, 2005

Avoid Making Your Testing Debt Bigger

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

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

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

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

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

Posted by Mishkin Berteig at 09:13 AM | |

June 20, 2005

Meet and Greet Before Critical Meeting

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

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

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

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

Posted by Mishkin Berteig at 11:56 PM | |

June 19, 2005

De-matrixed Teams

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

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

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

Posted by Mishkin Berteig at 11:51 PM | |

June 14, 2005

Collocate the Team

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

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

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

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

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

Posted by Mishkin Berteig at 09:27 PM | |

June 12, 2005

A Brief Note About Types of Backlog Items

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

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

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

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

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

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

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

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

Posted by Mishkin Berteig at 11:35 PM | |

June 10, 2005

Self-Steering Team

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

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

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

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

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

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

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

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

Posted by Mishkin Berteig at 05:40 PM | |

June 04, 2005

Does Agile Software Development do away with Business Analysts?

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

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

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

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

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

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

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

June 01, 2005

Adaptive Planning - Using a Backlog of Work

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

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

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

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

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

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

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

Posted by Mishkin Berteig at 06:45 PM | |

May 31, 2005

Doctor, it hurts when I do this...

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

Doctor: Then stop doing it...

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

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

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

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

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

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

Posted by Christian Gruber at 01:18 PM | |

May 26, 2005

About People, Tools and Processes

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

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

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

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

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

Posted by Mishkin Berteig at 09:57 AM | |

May 19, 2005

Test-Driven Work

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

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

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

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

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

Posted by Mishkin Berteig at 06:01 PM | |

May 18, 2005

Making Friends Sure Beats Making Enemies

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

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

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

Posted by Mishkin Berteig at 03:26 PM | |

May 17, 2005

The Qualities of an Ideal Test

These qualities are similar in style to the INVEST qualities of user stories - but they don't form a nice acronym.

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

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

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

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

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

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

---

Update 20060106

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

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

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

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

Posted by Mishkin Berteig at 06:48 PM | |

May 16, 2005

Iterative Delivery

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

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

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

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

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

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

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

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

Posted by Mishkin Berteig at 10:27 PM | |

May 15, 2005

Truck Factor

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

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

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

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

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

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

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

Cross posted from Mike Bowler's Weblog

Posted by Michael Bowler at 06:42 PM | |

What To Do With the Horizon of Predictability

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

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

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

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

Posted by Mishkin Berteig at 06:34 PM | |

May 10, 2005

Steps in Making a Decision

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

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

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

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

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

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

Posted by Mishkin Berteig at 11:48 PM | |

Information Radiators

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

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

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

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

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

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

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

Posted by Mishkin Berteig at 06:25 PM | |

May 06, 2005

Agile Readiness - When Can Your Organization Adopt Agile?

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

Agile Readiness Assessment Worksheet

1.Empowered Agile Project Manager
This person is responsible for the success of the agile process used on your project. An excellent source of such people is those who have taken the Scrum Master training available from ControlChaos.com. Your situation is best described by:

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

Your Score: _______

2.Management Support
Management support provides protection from the “old way” of doing things, and enables a team to self-organize, cut through red tape, and establish a “new way”.

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

Your Score: _______

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

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

Your Score: _______

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

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

Your Score: _______

5.Project Readiness
The project must be funded (or otherwise materially supported) in order to be launched. A strong champion can often ensure funding is in place before project launch commences.

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

Your Score: _______

Scoring:
Sum up the scores for each aspect of readiness.

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

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

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

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

Posted by Mishkin Berteig at 04:44 PM | |

May 04, 2005

Asymmetry of Knowledge and Abuse of Agile Practice

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

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

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

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

Posted by Christian Gruber at 01:07 PM | |

May 03, 2005

Index Cards as an Agile Work Tool

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

1. Dynamic Collaboration

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

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

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

2. Dynamic Tracking

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

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

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

Posted by Mishkin Berteig at 05:00 PM | |

April 30, 2005

Pair Programming in Software Development

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

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

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

Lets look at why this practice is so controversial.

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

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

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

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

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

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

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

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

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

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