Agile Advice: Theory Archives

July 19, 2007

Agile is Not Communism

Last week I taught an introductory course on Agile Work. Normally this is pretty easy stuff. However, I was teaching this course in Bucharest, Romania (cool), and I have come across a substantial, strong and vigorous objection to agile (also cool, but challenging too). Several people in my class are asserting that agile is just like communism and since communism failed, agile is not likely to succeed either. I'm looking for help on this!

I have Googled "agile communism" and come up with some interesting reading:

Does Scrum/XP Violate the Agile Manifesto?
The Agile Method and Other Fairy Tales: QED

I have also done some quick research on communism to check that I understand the comparison and objection. Here is a wiktionary definition of communism:

1. A term used to refer to a number of political philosophies or ideologies which share the belief in the virtue of holding the production resources collectively. 2. A society organized in line with the communist theories, the ultimate aim of which is the abolition of the state and the creation of a classless, stateless society whose members produce according to their abilities and take what they need.

So let's start with that definition.

Holding Production Resources Collectively
Also called: common ownership of the means of production

I suppose there are a few ways to look at this. In an agile environment which encourages (for example) collective code ownership, it might seem like holding the production resources collectively. However, the code is actually the result of production, rather than the Means of Production. This distinction is not trivial. The means of production for a team in an agile environment still include both the tools and the raw materials upon which those tools exercise. In software development (and in most creative work nowadays), the tools are computers and software and other electronic gadgets such as video cameras, telecomm systems, etc. The raw materials are typically intellectual constructs such as images, sounds, ideas, processes (and of course their legal counterparts such as trademarks, copyrights, and patents). Agile methods do not require the team of workers to own these means, nor do agile methods forbid workers from owning these means. In fact, There is one important way in which agile methods are decidedly not communist: every individual owns their own creativity, experience, and knowledge and is only asked to share willingly (and usually in exchange for pay such as salary, stock options or outright corporate ownership). I believe this passage clarifies things nicely:

Marxists define economic systems in terms of how the means of production are used, and which social class controls them. Thus, in capitalism, the means of production are controlled by the bourgeoisie, (the "capitalists" - the owners of capital), while in socialism they are controlled by the people's elected representatives and in communism they are controlled collectively by the people themselves. [Means of Production]

Agile methods, if anything, tend towards capitalism in this regard. (Although a whole other question could be asked about just how much control the owners of a corporation really have given delegated authority through the board of directors to the chief executive staff _and_ the abrogated authority through mutual funds, pension funds, holding companies, and trusts _and_ the limitations on that control through the blunt instrument of voting shares _and_ the influences on that control through the control of information by financial analysts and the media...)

Ultimate Aim of The Creation of a Classless, Stateless Society

Well, this certainly isn't the aim of agile methods that I am aware of. The aims of agile methods as I understand them includes:

Building stuff that stakeholders like
Creating an environment for team members to exercise their creativity
Doing all this in a way that responds well to pervasive frequent change

Again, I can understand why there might be some confusion here. Agile methods promote these three aims by doing something that looks just a little like a classless organizational structure. Typically, agile (and lean) environments start to have a higher manager to staff ratio (fewer managers), encourage self-organizing, cross-functional teams, and emphasize team goal setting, commitment and accountability. This might seem classless (and stateless/managementless) until one examines what is not said: Agile does not claim that every team member is exactly equal, it does not require that every team member do exactly the same thing, it does not require that every team member give up _all_ their individual preferences (although certainly it would be hard for someone who didn't like talking to other people to be part of an agile team... so I guess some individual preferences won't work in an agile team), it does not encourage every team member to do exactly the same amount of work regardless of if you are measuring effort or output.

Now admittedly, when I am presenting examples of self-organizing teams, I do sometimes use examples that come close to classless stateless teams... but that's just to show that this is a possibility and allowable in an agile environment, not that it is the only way.

Those practices in agile methods that do seem like classlessness and statelessness are not aims... they are means. A self-organizing, self-managing team, is means to an end. It is not an aim in itself. Why does this matter? For the simple reason that it is always bad to confuse means and ends. The end cannot justify the means (classlessness and statelessness imposed by revolution)... and nor can the means justify the ends (classlessness and statelessness that results in apathy, boredom and low productivity). So the fact that self-organization is a means is a way for us to decide if it is worthwhile. The evidence for self-organizing teams in a business context is strong (lots of links and articles and books on this blog as well as others). Most team members enjoy being self-directed in a way that is collaborative with other professionals. So both the ends are good - productivity - and the means are good - happy people.

Members Produce According to Their Abilities and Take What They Need

To me, "produce according to their abilities" sounds a lot like a tautology. Certainly, team members can produce no more than their abilities! From an agile perspective, this isn't even what we are interested in... we are interested in the multiplicative effect of teams of people working together effectively so that the result of the work is greater than the sum of the individual abilities. There is now substantial evidence that this is not just possible, but a likely outcome of group work (see Research on Group Effectiveness vs Individuals among many others). My favorite phrase for this is "Unity in Diversity" which describes a group of people who have united around a common goal, but with each individual having talents, experiences, knowledge, patterns of behavior, and insights that are all different from each other.

The second part of the phrase "take what they need" is another piece of this pie that has absolutely no relationship to agile methods. Again, there is evidence that this is specifically not supported. Lean methods encourage compensation that is based on a number of things including: contribution to results in one's sphere of influence (rather than the more limited sphere of responsibility) and the number of skills you have mastered and use to contribute to the work.

Disconnecting reward from results is an obvious problem. While people do have altruistic feelings, we also are clearly motivated by praise

Some Similarities

One of the attendees of the course, a woman by the name of Christina, provided me with some notes based on her understanding of Agile and Communism and she listed these similarities:

They both rely on participation, rather than executing orders.
One aim is less frustration.
They use some similar phrases such as multidisciplinary / cross-functional.
They both ask people to evaluate each other.

And What about Reality?

Well, I haven't lived in a communist environment so I admit that my ability to talk intelligently about this is not what I would like it to be. I am interested in people out there who might be able to help me with this.

Here are some questions for people who have actually experienced communism:

What are the actual, in-practice similarities between agile and communism?
What are the in-practice differences between agile and communism?
Why did communism fail and how might this affect the success of agile methods?
How can we safeguard agile from falling into the same problems?

Can anyone out there help please?

Posted by Mishkin Berteig at 06:13 PM | |

January 02, 2007

Top Ten Most Popular Entries from 2006

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

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

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

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

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

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

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

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

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

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

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

Posted by Mishkin Berteig at 06:32 PM | |

November 10, 2006

The Essence of Agile

What is the difference between an agile process and a non-agile process?

Both are concerned with delivering value quickly and with high quality. No one can dispute that those are "Good Things".

Both, in their own ways, have mechanisms for learning how to deliver more value. In iterative and incremental processes, this is done by checking the results against reality and adjusting the work to be done in the next increment. A non-agile process can do this just as easily as an agile process.

The real difference is in learning at the process level. A non-agile process doesn't change. An agile process starts with certain artifacts, meetings, steps, roles, and those all are up for discussion and change based on learning about the work. You can't freeze a definition of an agile process in reality. (It is, of course, possible to define an agile process starting point.)

Any other differences?

Posted by Mishkin Berteig at 10:52 AM | |

September 07, 2006

Queuing Theory and Agile Backlogs

Queueing theory (1, 2, 3) and Lean pull-based queue systems provide some insights into why agile backlogs such as the product backlog found in Scrum are done they way they are.

Updated! (originally published April 6, 2005)

Typically, an agile team works by taking iteration-sized chunks of work off of the project backlog. Even though items on the backlog do not need to be the same size, by taking several off the backlog at a time, the total package of work for the iteration can be made a consistent size. The backlog is prioritized so the agile team is always working on the highest-priority stuff. So far, this is great: the work packages are consistently sized (iterations are always the same duration and with the same team), and generally small so the team is working at high utilization. However, individuals in the team may not be at a high level of utilization.

Utilization Graph.gif

A basic lean pull-based system operates so that as a "server" (i.e. the project team) completes a piece of work, it pulls another piece off of a queue of work items and begins processing that item. However, agile methods say nothing about how long work is waiting in the queue. The work in this queue is in progress as far as the customer/client is concerned. Therefore, from the customers perspective, the time-to-delivery of an agile team is not managed because the size of the queue of work is not being managed. In most agile methods, including Scrum, there is no "gating function" that determines what work can be added to the backlog and when to add it. The Product Owner controls the backlog priority and maintains it. However the backlog

represents everything that anyone interested in the product or process has thought is needed or would be a good idea in the product. It is a list of all features, functions, technologies, enhancements, and bug fixes that constitute the changes that will be made to the product for future releases. (Agile Software Development with Scrum, p33.)

So what is happening? There is an implicit gating function occuring that releases work into the team's iteration. That gating function is based on the Product Owner prioritizing the backlog and refining the items so that they are small enough for a single iteration, and the team estimating the high-priority backlog items so that only enough for one iteration is released.

In terms of Little's Law, the team has deliberately pre-determined the average time a work item spends "in the system" (iteration). Therefore, the number of items taken from the backlog varies per iteration.

Is there another way to do this? What if the team, instead of being considered a single server, was examined from the perspective of the individual people doing the work?

In this case, the backlog would have to be managed differently in order for the system to work efficiently. First of all, the size of the backlog would need to be fixed. Then, items put on the backlog would all need to be of the same size in terms of man-hours. Instead of having iterations, the people on the team could each take items off the backlog independently. Finally, everyone on the team would have to be fully capable of doing any item on the backlog from start to finish. The Product Owner would then be responsible for replenishing the backlog.

Uniform Backlog.gif

In this scenario, iterations do not really make sense. However, this way of managing the backlog is only possible under the following conditions:

1. Work can be normalized into independent equal-sized packages.
2. Individuals work at roughly the same rate.
3. A single person is able to take full responsibility for a single work package.

We can see from this list of conditions, that for most creative endeavors, this is not realistic. This in turn points us back to the way that Scrum and other agile methods are designed. A team's velocity (rate of work completion) can be determined after a few iterations because work packages are broken into iteration sized chunks and because the team represents a single server in the queueing system. This in turn leads to much more flexibility in both the type of work packages that can be handled and the level of skill and specialization that the people constituting the team can have.

Check out the short whitepaper I've written about the relationship between lean and agile.

Posted by Mishkin Berteig at 08:59 AM | |

April 20, 2006

An Introduction to General Systems Thinking

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

The Subject

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

The Ideas

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

The Writing

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

How Does This Apply to Agile Work?

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

The Table of Contents

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

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

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

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

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

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

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

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

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

Posted by Mishkin Berteig at 05:18 PM | |

April 12, 2006

Follow the Principles and Adjust the Practices

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

Follow the Principles

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

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

We are Creators
Reality is Perceived
Change is Natural

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

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

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

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

Learning Circle

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

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

Blind Men and Elephant

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

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

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

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

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

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

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

Adjust the Practices

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

The Agile Work practices are simple to state:

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

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

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

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

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

Posted by Mishkin Berteig at 01:45 AM | |

March 12, 2006

Work Item Backlogs as Queues - Agile vs. Lean

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

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

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

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

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

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

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

Capacity of Team(s):

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

Gate Backlog Items by ROI

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

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

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

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

Posted by Mishkin Berteig at 03:31 PM | |

March 10, 2006

The Art of Obstacle Removal

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

What are Obstacles?

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

Obstacles and Waste

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

Types of Obstacles

Personal

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

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

Physical Environment

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

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

Here are some guidelines on a good team room.

Knowledge

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

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

Organizational

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

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

Cultural

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

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

Dis-Unity

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

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

Removing Obstacles

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

Direct

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

Command and Control

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

Influence

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

Support

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

Coaching

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

Creating a Culture of Obstacle Removal

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

Strategies for Dealing with Obstacles

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

Remove

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

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

Move Aside

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

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

Shield

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

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

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

Transform

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

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

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

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

Counteract

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

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

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

Removing Obstacles and Learning

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

Obstacles Inherent in Agile

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

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

Go Forth and Demolish Obstacles!

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

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

Posted by Mishkin Berteig at 01:10 PM | |

January 27, 2006

People vs. Process

One of my favorite little management blurbs, seen on the door of an SVP at a major financial services company: "Processes don't write software, people do!" And of course, the Agile Manifesto states: "... we have come to value: Individuals and Interactions over Processes and Tools..." Here's an interesting little writeup about people and process. My own take is quite similar: a process can be more or less helpful, but only if people are willing to learn and change can true progress be made.

Posted by Mishkin Berteig at 07:54 AM | |

January 11, 2006

The One True Metric

Agile Work requires that we align our perception of reality in order to understand each other and do work that is considered valuable by everyone. One very blunt and seemingly simple way to do this is with metrics. But metrics need to be in context and that is the part that is hard to get right. Does your organization get it right?

Having a Goal

The point of Agile Work is to get stuff done. Sound simple? It is, but it requires that you actually have a goal. Ideally a single goal. That goal forms the basis for your work and is the target towards which you drive yourself and your organization. For most corporations, that goal is related to either revenue, profit or market share. For most non-profit organizations, that goal is related to helping some group. For communities, the goal is usually related to growth or relationships. For individuals... well, it really depends on you.

There has been much written about goal setting. Here are a few quick interesting links:

The Goal by Eliyahu Goldratt
Be Excellent: Goal Setting Study from 2005
Success Through Goal-Setting
Built to Last : Successful Habits of Visionary Companies by Jim Collins

If you are working with many people in a team, an organization or a community, goal setting is a bit more complicated. There are many techniques for finding goals, gaining consensus and acting upon those goals. Brainstorming methods, doing off-sites, getting business or strategic coaching, and using various decision-making processes will all help.

Improve Against Your Goal

Once you have a goal, the next obvious thing to do is to start to move towards it. That motion must be planned and there are many ways to do this. In Agile Work methods, adaptive planning is the method most commonly used. If your goal is farther than your horizon of predictability, or if your goal somehow represents a moving target, then adaptive planning is a necessity. The specific steps you take towards your goal create an opportunity to inspect and adapt. In order to inspect your progress towards your goal, you need some way of measuring where you are and where your goal is.

One True Metric

Since your single goal is your most important destination, and since all your work should be to get towards that goal, you should only have one thing to measure. At this point, it helps to give a couple of examples.

If my goal is to drive from Toronto to San Francisco, all I really care about is estimated time to arrival. This allows me to call my friends and say things like: "Hi Jesse, I'm going to be in San Francisco at about 3pm tomorrow." I can find a value for estimated time to arrival if I can estimate my speed, my current road distance from San Francisco, and how much time I will take stopped for breaks. This single value is all I really care about.

For a large commercial organization, finding the single measurement, the One True Metric, can be more complex. Profit is not always the best measurement, all by itself. Usually, a better metric is profit per something. In Good to Great: Why Some Companies Make the Leap... and Others Don't by Jim Collins, there is a note of the economic denominator used by Nucor: profit per ton of finished steel. This is Nucor's One True Metric.

Behavior

It is often claimed that metrics drive behavior. In reality, there are a large number of factors which drive behavior and metrics are only a small part of that environment. Nevertheless, if you are missing good metrics, your chances of having desirable behavior are lower.

The One True Metric, by being single, simple and universal to your organization, can have a large effect on behavior.

Once you have the One True Metric in place, then what? Well, the obvious first step is to start measuring it immediately. Each measurement of the One True Metric should be no farther from the others than your organizations Horizon of Predictability. The results of this measurement must be published far and wide in your organization to every human being who works there either management or labor, employee or contractor, full-time or part-time, day shift or night shift, on-site or off-shore. Absolutely everyone should be constantly aware of this metric.

Contextual Temporary Metrics

With everyone in the organization hyper-aware of the One True Metric, you can then begin to use contextual temporary metrics to help understand details or troubls spots. These "CTMs" are qualitatively different from your One True Metric: they are used only for a short time and only in a very limited context. Two examples of CTMs are Time to Obstacle Removal and Obstacles Removed per Iteration.

Like the above example metrics, there are three important questions that must be answered about any CTM:
- Why Use This CTM?
- When to Use This CTM?
- When to Stop Using This CTM?

Every contextual temporary metric must be aligned with the One True Metric so that a good result with the CTM will not cause a bad result for the One True Metric. It is critical to understand that good results with CTMs don't guarantee good results with the One True Metric. All CTMs can be gamed; people can produce good results against the metric while doing something that isn't really valuable or is possibly harmful.

At some organizations, people are measured by how busy they are: their utilization levels. There are many reasons this is a bad idea, and here is one story of the consequences.

An organization I worked at decided that the larger the percentage of time that people worked, the more cost effective the organization would become. Labor was a primary cost for this organization. In order to make this idea stick, people were punished and rewarded based on their utilization rates. If you were 50% utilized, you were out the door, and if you were 100% utilized, you were lauded. But management noticed three problems:
1) it started to take a really long time to get projects done
2) people were working on several projects simultaneously
3) it was very hard to find people available for new projects
Further digging revealed that people were making up projects to fill in their time! Measuring utilization had turned into a disaster.

The improper use of metrics can cause no end of subtle problems. By using proper goal setting combined with the establishment of One True Metric and contextual temporary metrics, an organization can become aligned to its purpose and efficient at executing on that purpose.

December 13, 2005

Agile Work Uses Lean Thinking - Team Self-Organization

This third and final installment of the "Agile Work Uses Lean Thinking" series introduces Team Self-Organization from a lean and agile prespective. Find out what lean practice relating to people is not commonly used in agile methods... (Previous installments are Empirical Process Control and Queuing Theory. A polished version of all three articles will appear soon as a downloadable PDF.

The people who actually do certain work on a day to day basis know that work intimately... more intimately than anyone else. Anyone else who knows the work either knows it historically or in theory, but not in the same intimate manner. This intimate knowledge carries a great deal of potential. In order to release that potential, people must accept individual responsibility and collective responsibility. Management and organizational culture must support that responsibility. Lean and agile have a very similar approach to supporting this self-organization.

The first aspect of this support is just a simple recognition of this intimate knowledge. The people doing the work must have their expertise acknowledged both individually and collectively. The second aspect of this support is to share with these people the strategic and tactical "why" of what they are doing. This can include sharing financial models, strategic assessments, etc. The third aspect of this support is in allowing individuals and teams to create and implement their own process improvements. In lean this focuses on "identifying and eliminating waste" and in agile this focuses on "identifying and removing obstacles". The fourth aspect of this support, and perhaps the most important, is that of self-organization: teams and individuals organize themselves around the work. Managers no longer have the authority to tell people how to do their jobs.

In agile teams, this concept of self-organization is taken quite far. Team members collaborate to get work done. No one orders a team or an individual to do specific work. The team members volunteer for work that they see needs doing, even if it is not something that is in their area of expertise. An agile team is constantly promoting learning in its people. Agile teams are also cross-functional so that the team can get work done without relying on external services. The team therefore represents a complete work unit capable of taking a function valuable to customers from start to finish, from idea to deployment.

One aspect of lean systems that is not commonly practiced in an agile environment is the idea of stopping the production line when a flaw or defect or error is discovered. In lean manufacturing, every person working on the line has the authority to stop the whole line if they notice something wrong. Then, everyone works on correcting the defect all the way to the root cause of that defect before starting the line again. This is a very powerful mechanism for making certain that there is constant improvement in the production process. Giving people the power and authority to stop the line takes a great deal of trust.

Posted by Mishkin Berteig at 09:09 PM | |

November 15, 2005

Salutogenesis and Agile

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

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

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

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

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

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

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

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

Salutogenic food for thought for the Agile practitioner:

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

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

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

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

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

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

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

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

Posted by Shabnam Tashakour at 07:50 AM | |

Salutogenesis and Agile

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

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

Salutogenic food for thought for the Agile practitioner:

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

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

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

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

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

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

Posted by Shabnam Tashakour at 07:50 AM | |

November 09, 2005

Agile Work Uses Lean Thinking - Empirical Process Control

This is Part 2 of a 3 part series.
Part 1
Part 3 - not posted yet :-)

Some work processes cannot be perfectly controlled nor perfectly defined. There may be non-linear interactions between steps in a process or there may be creative input from a human required. Processes with these qualities require empirical process control.
The basic attribute of empirical process control constitutes a continuous cycle of inspecting the process for correct operation and results and adapting the process as needed. A simple example of this is detecting impending failure of equipment by constantly monitoring the operation of that equipment. For Agile Work, the book Agile Software Development with Scrum provides an excellent chapter about this topic of Empirical Process Control.

In human processes like those to which Agile Work applies, the frequency of inspecting and adapting must match the needs of the process. Many projects occur in the context of constant change. This constant change makes long-term planning a wasteful effort. Rather, short-term planning with constant feedback provides a simple inspect and adapt cycle. This cycle can play out at different levels: daily for a team, monthly for a client of the team. The team inspects and adapts daily at the level of the tasks that it is performing. The client inspects and adapts monthly at the level of the team's actual delivered results.

Both lean and agile methods claim to increase both speed and quality. Many people believe that there are four constraints in a system that can be controlled: speed (or schedule, or time to market, or process cycle time), quality (number of defects), scope (how much functionality), and cost savings (how much to spend on the work). Frequently, management believes that one has to trade off between these four constraints; spend more money, get more scope; lower quality, go faster. But in fact, lean and agile strongly support the idea that as you increase quality, you also increase speed... you just have to do it right.

In Agile Work, increasing speed and quality is done in three ways. First, increase the frequency and quality of communication among team members so that errors are detected early or avoided altogether. Second, drive the work with the creation and execution of automated testing. No work is done without a test in place to check if it is done correctly. This constant testing means that work is always defect-free and therefore very little time/money is spent on fixing defects. Third, eliminate wasteful work steps or obstacles to performance of work. This last one is difficult to do an bears closer examination.

Wasteful work is done in every process, no matter how efficient. Lean tells us that there are several types of waste in a manufacturing process. Those types of waste have analogies in Agile Work. For example, documenting something you plan to do instead of just doing it is wasteful. Another example is waiting while someone completes work that you depend upon. Any step or task that does not add value to the final product of an effort is waste. This standard is very high and most organizations have about 80% of their efforts going into wasteful tasks. An organization that has done an initial cut of wasteful work might stand at about 50% waste. The leanest organizations, such as Toyota, stand at about 20% waste.

Agile work eliminates waste in the form of barriers or obstacles that come up when a team is trying to go fast. Sometimes this is in the form of waiting for another group to do something for the agile team... an outsourced request for service. Sometimes waste is in the form of corporate standards or policies around documentation of work. The Process Facilitator role in an agile team has responsibility for working with the team and others to help overcome these obstacles.

Posted by Mishkin Berteig at 02:08 PM | |

November 04, 2005

Agile Work Uses Lean Thinking - Queueing Theory

Queueing theory describes the statistical and theoretical behavior of queues. In a queue system, there are two basic parts: work items and worker units. Worker units perform some work upon work items. The streaming of work items through worker units composes a queueing system. The time it takes for a work item to enter the system to exit the system is the process cycle time. From the study of real queueing systems and from simulation of queueing systems, researchers have shown there are some simple methods for creating an efficient queueing system that minimizes process cycle time.

One method for making a queueing system more efficient relates to the size of work items and how this relates to worker unit utilization levels and process cycle time. Queues behave in a very interesting way in relation to utilization and process cycle time. As utilization of a worker unit approaches 100%, process cycle time goes up very quickly. Not only that, but the more variability there is in the size of the work items, the worse this effect becomes. With a queue with work items that are all the same size, the worker units can maintain a very high level of utilization and the process cycle time is not significantly affected. However, with a queue with work items that are many different sizes, a worker unit will slow down significantly and process cycle times become worse even with relatively low levels of utilization.

Lean and Agile both use these ideas. Lean applies these ideas to manufacturing and other production processes and Agile applies these ideas to project work.

In Agile, iterations are used to create consistently small sized units of work that are then taken on by a team. In other words, the work items are designed to be exactly the size of an iteration and the worker unit is the Agile team. Since iterations are typically much smaller than the size of the overall project and since each iteration is always the same size, this allows the team to achieve very high levels of utilization while maintaining extremely short cycle times (the length of the iteration or release). Compare this to the waterfall approach to project management where the work is only finally delivered at the very end of a long process and you can see that not only do you have a very long cycle time, but each project will be highly variable in size and therefore it will be hard to get good utilization out of teams (think resource planning and leveling).

The Theory of Constraints, which is nicely introduced in The Goal by Eli Goldratt, presents some additional basic techniques for making improvements in efficiency of a process. The basic idea is that one can always find a slowest point or constraint in a process by finding out where there is a buildup of unfinished work. For example, if two people are cleaning a kitchen, one washing dishes and the other drying, if the number of wet washed dishes keeps building up, then the constraint for the process is the person drying. In more complex processes either in manufacturing or in creative work such as software development, it is sometimes more difficult to see where the constraint is. Typically, if you find that you have people waiting for work that is coming from someone else, then that someone else is a constraint and means can be found to improve their efficiency. In Agile, the focus on resolving the constraint would be to provide that person extra training or get other members of the team to assist in the work. Agile tends to shy away from a mechanistic perspective on efficiency.

Finally, in any queueing system there is some point at which work enters the system. This point of entry is very important because it can be used to control the utilization levels of worker units in a queue. In Agile Work, this control is accomplished through backlog management, iterative delivery and adaptive planning. All possible requests, features, constraints, improvements for a project are put into a master Work Item List. This list is strictly prioritized in descending order by a person empowered with this responsibility (called the Product Owner). This list of work items becomes the basis for deciding what work the team will do each iteration. The process of managing this list and how the work is chosen for this iteration allows the customer/client to prioritize important things to be delivered quickly and allows the team to work on consistently sized work units (iterations) and therefore achieve very high levels of utilization. In queueing theory this process is referred to as the gating function in that it provides a gate that lets work items into the system. All work must go through this gate or work item list management process in order for the team to function effectively. If the team is interrupted with work that has somehow skipped the gate it will seriously reduce the efficiency of the team(e.g. a senior sales person comes to the team and declares that it must work on X, it'll only take a day, a potential client really needs this, surely that won't hurt?).

Posted by Mishkin Berteig at 01:44 PM | |

October 10, 2005

Agile, the Adult Educator and Ethical Considerations

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

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

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

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

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

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

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

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

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

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

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

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

Posted by Shabnam Tashakour at 09:35 PM | |

October 07, 2005

Agile Coach/Mentor Job Description (Process Facilitator)

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

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

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

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

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

Suggestions and ideas are greatly appreciated!

Posted by Mishkin Berteig at 12:33 PM | |

September 29, 2005

Transformative Learning and Agile

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

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

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

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

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

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

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

Posted by Shabnam Tashakour at 10:50 PM | |

September 28, 2005

Agile Infrastructure Projects - Lessons Learned

I've worked as an agile coach on three infrastructure/maintenance projects in a row. One was a software/hardware upgrade, one was implementing agile for a defects/enhancements team, and my most recent was a data warehouse decommissioning project. In all cases, the interesting part for me was taking the basic principles of agile and applying them in a way that works when not doing new product development. Here are some lessons I've learned:

1. Figure out what is going to deliver value (usually cost savings). In the case of infrastructure projects, one is usually focused on cost savings. Find a way to tie your work items directly to cost savings. You need a good financial model to do this. Mary and Tom Poppendieck talk about this a little in their Lean Software Development book. In the decommissioning program, there was a very explicit dollar cost associated with disk space and cpu utilization. Every user/MB decommissioned saved a measurable amount of money. As well, it allowed us to easily prioritize our backlog.

2. Focus project/program organization more on Lean principles than agile. A good understanding of queuing theory will go a long way to helping with throughput. In a team doing defects/enhancements work, the small pieces lend themselves well to certain types of streaming through the team. Iterations are not necessary to chunck work. Instead, iterations become checkpoints solely for process reflection.

3. Technical infrastructure projects can benefit greatly from automation. Test automation including test generation can sometimes be possible. Automating parts of a regularly repeated process that is used for every work item can be extremely beneficial for increasing speed. In the case of the decommissioning effort where every database table needs to be considered separately and where they all go through the same process for decommisioning, there are many opportunities for automation. The project/program/team can invest in doing this automation to great benefit to NPV.

4. The basic axioms (We are Creators, Reality is Perceived, Change is Natural) and disciplines (Empower the Team, Amplify Learning, Eliminate Waste) still apply. Even though it is not "new" product development, the creativity of people is essential for problem solving, and finding ways to do the work faster. Stakeholders still need to have their perception of reality acknowledged, and the teams still has to do constant checking to make sure they are on track with that perception. And of course, things are always changing including priorities, our understanding of the work, resource availability etc. Having an empowered team makes short work of many obstacles, but that wouldn't happen without an explicit acknowledgement that we have to constantly be learning and eliminating waste. Teams get better and better at these disciplines over time.

I would be very interested to hear other peoples experiences with infractructural/operational projects.

Posted by Mishkin Berteig at 12:00 PM | |

September 27, 2005

Tools Versus Capabilities Approach To Agile Training

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

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

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

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

Posted by Shabnam Tashakour at 12:44 PM | |

September 15, 2005

Personal Philosophy of Adult Education

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

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

Validation: a starting point

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

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

Encouragement: the key to self-directed learning

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

A transformative, holistic approach centred in humility and service

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

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

Principle-based approach facilitates ownership

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

Integration and balance of methods essential

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

Modelling Change

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

Summary

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

Agile Advice

Thoughts and experiences for practitioners of Agile Work, the Middle Way to Excellence.

July 19, 2007

Agile is Not Communism

January 02, 2007

Top Ten Most Popular Entries from 2006

November 10, 2006

The Essence of Agile

September 07, 2006

Queuing Theory and Agile Backlogs

April 20, 2006

An Introduction to General Systems Thinking

April 12, 2006

Follow the Principles and Adjust the Practices

March 12, 2006

Work Item Backlogs as Queues - Agile vs. Lean

March 10, 2006

The Art of Obstacle Removal

January 27, 2006

People vs. Process

January 11, 2006

The One True Metric

December 13, 2005

Agile Work Uses Lean Thinking - Team Self-Organization

November 15, 2005

Salutogenesis and Agile

Salutogenesis and Agile

November 09, 2005

Agile Work Uses Lean Thinking - Empirical Process Control

November 04, 2005

Agile Work Uses Lean Thinking - Queueing Theory

October 10, 2005

Agile, the Adult Educator and Ethical Considerations

October 07, 2005

Agile Coach/Mentor Job Description (Process Facilitator)

September 29, 2005

Transformative Learning and Agile

September 28, 2005

Agile Infrastructure Projects - Lessons Learned

September 27, 2005

Tools Versus Capabilities Approach To Agile Training

September 15, 2005

Personal Philosophy of Adult Education