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 infinite and diverse capabilities of human potential. Ultimately the success of an educator rests on the degree to which she is able to model the change she is fostering.

Posted by Shabnam Tashakour at 05:04 PM | |

August 17, 2005

The Viable Systems Model

Agile Work is a system that can be created inside many types of organizations and work environments. I recently came across an interesting article about the viability of systems. The article describes an interesting recursive breakdown of systems into sub-systems of specific types. Over the course of the next few weeks, I will use this model to try to analyze Agile Work to see if it is viable.

Posted by Mishkin Berteig at 08:36 AM | |

August 12, 2005

Just-In-Time Value Delivery and Waste Elimination

Lean Manufacturing

If I am manufacturing computers, and I receive a large batch of CPU's... say... Intel Pentium IIIs, I put them in inventory. There is a recurring montetary cost associated with keeping this inventory. There is, however, also a hidden cost. If I use up half my inventory to build computers, and then I inventory those computers, and I ship half of those computers, I now have 3/4 of my initial chips waiting around, earning me no money at all.

Then, Intel ships the new Pentium 4. What happens now? Well, I basically have to throw out my Pentium 3 stock (either by making low-cost, reduced-margin computers just to get rid of them, or by trying to sell the chips wholesale at cut rates). I also have to either slash prices on my remaining stock of computers, or re-fit them with the new processors. All of this is very expensive, and may eliminate most or all of the profits I was expecting to make on the original purchase. It is a scenario that is rife with waste.

Most manufacturing industry players have figured this out, and moved to a Just-In-Time model of production. Toyota pioneered much of this in the 1970s, and now inventory is seen as a liability, rather than an asset. This waste-free approach is a centrepiece of the Lean manufacturing revolution

Waste and Inventory in Software Development

Unfortunately, there is a parallel in computer software creation that has been rather poorly understood by businesses that need custom software development. Waste can be considered as anything that is unfinished, and/or unused. In software development terms, this can be applied to documents that will never be read or that might be unnecessary, and other such things. It is also true of unfinished software.

Traditional Software Development Example

Let us suppose that we ask someone to develop a piece of software with thirty features. Let us further suppose that this software will take about twelve months to produce. Let's further suppose that ten of these are business-critical features, and that all of the features' definitions are highly market-driven.

So a traditional software project starts to develop them. First there is a requirements analysis phase, then a design phase. Throughout there are lots of approval stages, sign-offs, etc. Then some team codes up the software starting somewhere around month five. Coding proceeds for about three months, after which the software goes through a testing process in month nine. In theory, at the end of this testing process (month twelve), we are supposed to receive the software for use, and we should be able to receive the value it was supposed to offer. However, defects are found in testing, requiring some re-work. The software is delayed by a further three months, and we finally receive it. By the time we receive it, our competetors have defined new features, and we have to submit new feature requests, whose results will not be seen for several months.

So for the entire development process, we received no business value, and continued to pay. Fifteen months from first investment until we started to achieve results that could mean revenue from the system. At this point, the software is partially obsolete. This is quite similar to the manufacturing scenario above.

Lean and Agile Software Development

Agile and Lean software development practices change this process by delivering business value a little-bit at a time. In an Agile software project, the business specifies what the most important features are (in our case the ten business-critical ones). The team then begins working in small time-boxes - say, two to four weeks. In each time-box, the team works on a small but well-defined list of features taken from the top of the prioritized feature list that we specified. At the end of the time-box, those features that were worked on are delivered to a degree of quality that each of the delivered features would be suitable for use by the customer. The whole might not be ready, but any features worked-on would be complete and production-ready.

If the team can average about three features per month (about what they pulled off in the above example), then by month four, the team could deliver a piece of software that has all ten business-critical features ready for use. The whole might not be ready, but the customers could determine whether those ten were worth taking the software in its current state, and packaging it up and deploying it. Quite simply, the software may not be "done", but it's "done enough". Then the team can continue to roll-out less valueable features from the prioritized list.

Market and customer needs volatility

This becomes even more important when we consider the competition's changes. In the traditional example above, after fifteen months, additional features were required. These may have been discovered in month six. Traditionally, these could only be considered in month sixteen. In Agile and Lean software development, however, work on these changes could be started in month seven or sooner. So the business received value early, or "just-in-time", and they could get high-value changes "just-in-time".

Quality

Because testing is built-in to the process, the customer is able to validate the product at the end of every time-box, so there are no large batches of re-work. The only time large batches of rework are necessary are when large changes to the basic requirements are requested. And then, Agile does not resist the customer's desire to change, but recognizes it as an essential part of software delivery, and adapts to the changing consditions. As a result, the Agile and Lean methods are optimized to produce quality product in small increments, so quality doesn't suffer from customers or markets changing their minds.

Summary

Agile and Lean principles are very powerful, and allow for business value to be delivered sooner to end-customers. This allows for better quality and risk management. It also allows strategic and tactical decision-making by executives to be undertaken when such decisions are most needed - not six months too late.

Firms that embrace Lean and Agile development principles are beginning to see the competetive differentiation that Toyota saw vis-a-vis the rest of the automotive industry throughout the 70's and 80's. It is only in the last two decades that, after adopting Lean practices, Toyota's competitors have begun to close the gap. Agile software shops are beginning to achieve these same competetive gains. Those who don't adapt to just-in-time value delivery - who don't eliminate waste in their processes - will feel the results as their competitors take products and services to market far faster, and with more responsiveness to their customers.

"If you're not on the steam-roller, you're part of the asphalt." - Lighthouse Design, circa 1996.

Posted by Christian Gruber at 01:30 PM | | | TrackBack

August 08, 2005

Value redux (more on business value added)

In a previous article, Mishkin portrayed three kinds of added value that can be considered when analyzing a value stream: Customer Value Added (CVA), Business Value Added (BVA), and Non-Value Added(NVA). I recommend peeking at this article before reading this one.

The second flavour mentioned is Business Value Added. This is, to quote the above, "activity that is required to operate the business but the customer is unwilling to pay for." I wanted to look at this a bit closer.

Why would we separate this kind of value? On one hand, if the customer wouldn't pay for it, is it really value? Management and executive would say, "Yes", since it amounts to operational infrastructure or overhead necessary to the business. By this view, without certain "horizontal" functions, the entire enterprise to which the lean analysis is being applied would not be possible - therefore it's of immense value to the customer, however indirect. On the other hand, if it isn't of value to the customer - ie. the customer cannot see the value, then why is it there at all? This is a tough question.

A fanatical Lean interpretation would be to say that this kind of value doesn't exist. Either a reasonable customer would be willing to pay for it, explicitly, if indirectly, or it simply is not value added. In essence, business value added can be seen as something of an allowance - a departure from the sharp scalpel of lean value-stream analysis. Its purpose is to provide to those who do these "BVA" functions some explicit value, since these are often those whom lean analysts must convince of the accuracy of their analyses. By this interpretation, BVA is strictly a cop-out. It doesn't provide value to the product/service produced, and is therefore a target for waste elimination.

There are very good reasons to look at BVA from either side. The discipline of waste elimination on one hand, and validating necessary if unprofitable work on the other. As in most things, a balanced view is wisest here, and perhaps BVA is merely a short-hand for such a view. BVA, like NVA is waste. However, there are some necessary and unavoidable wastes.

Traffic lights are on all night, even when cars aren't available, because no one has figured out an efficient way of turning them off until cars appear. It's necessary infrastructure. But it is waste. It's power being consumed without result.

A full highway is a jammed highway. Having about 15-20% capacity under-used actually tends to optimize the on-ramp-to-off-ramp cycle time. Here is unused roadway, where clearly one could fit on more cars. Yet, according to queueing theory, this localized "waste" is necessary in that it optimizes the whole system. Such system-supporting overhead is counterintuitive, but bears itself out in many natural systems.

The process of tracking project progress does not improve the final product, but it aids in the organization of the corporation/entity that is providing the initial funding, and satisfies necessary requirements that are not direct from the customer. It may result in better resource allocation, for example. The daily meeting is time not spent on the product, but those 5-15 minutes can unjam horrible project roadblocks. Eliminating this "NVA" or "BVA" step would be catastrophic for the whole system.

Because BVA, like NVA, is waste, it should always be examined for reduction and elimination. Unlike other NVA, however, I would argue that BVA is that minimum NVA activity that cannot be trimmed, without unduely sacrificing the effort as a whole. By calling it NVA we keep it in perspective. Perhaps it might be better called "unavoidable non-value added" (UNVA) activity. It's value is not direct, and it is effort and resources taken away from the customer. Where possible, it should be eliminated as NVA. However, those who perform these functions can rest assured that, once the process is leaned-out, what they are doing is unavoidable and necessary work.

BVA (UNVA) can be a very useful tool for clarifying process, so long as the analyst doesn't get sloppy about treating it as waste.

Posted by Christian Gruber at 03:27 PM | |

August 06, 2005

Generalizing Specialists

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

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

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

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

Posted by Mishkin Berteig at 08:05 PM | |

August 04, 2005

Just In Case You Haven't Seen It Yet

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

Posted by Mishkin Berteig at 11:41 AM | |

August 02, 2005

Memory and Mystery

My father, Garry Berteig, recently took a trip to China to visit my brother in Beijing. Garry is an artist and an educator of great skill and insight. While there, he had the following insight:

Memory (traditional forms) is undone by Mystery (abstract forms). The next step is to combine the two into new forms in a postmodern sense... unity through diversity.

I believe this can be related to the idea of levels of mastery which I first encountered in Alistair Cockburns excellent book "Agile Software Development". Since I don't have the book in front of me, I have to go from memory. First there is rote learning, memorization of predefined forms. Then comes understanding of why the forms are the way they are. Finally comes the wisdom and experience to innovate on the forms.

If anyone else has any ideas about this, I would love to discuss them!

Posted by Mishkin Berteig at 12:00 PM | |

August 01, 2005

Broadcast Mode Communication

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

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

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

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

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

*Highly recommended!

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

Posted by Mishkin Berteig at 11:18 AM | |

July 25, 2005

Applicability Matrix Tool for Iterative Delivery

Notes:

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

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

Posted by Mishkin Berteig at 03:14 PM | |

July 23, 2005

The True Cost of Software

From the Link: Calculating the True Price of Software by Robert Lefkowitz -- Businesses have long viewed support and maintenance as essential components of software. Open source business models often focus on charging for support and customization. Is there an economic model that can demonstrate the true worth of a piece of software and the option for support, maintenance, and upgrades? Robert Lefkowitz argues that open source exposes the true value of software itself as, essentially, worth less in comparison to support and maintenance.

Posted by Mishkin Berteig at 04:37 PM | |

July 21, 2005

Waste and Value: Basic Lean Concepts

In assessing a process, it is important to understand what activities in the process actually add value to the end result. All other activities are wasteful.

CVA (Customer Value Added - or just VA for Value Added): adding form fit or function to a product or service, an activity that the customer would be willing to pay for in isolation if they knew it was being done – e.g. Creating code, implementing functionality.

BVA (Business Value Added - non-negotiable waste): an activity that is required to operate the business but the customer is unwilling to pay for – e.g. Budget tracking, code documentation.

NVA (Non-Value Added): an activity that is not required by the business nor is the customer willing to pay for – e.g. Waiting for resource allocation, requirements documents.

In the book Lean Six Sigma : Combining Six Sigma Quality with Lean Production Speed by Michael George, he describes a series of questions that can help you distinguish between these three categories:

Customer Value-Added (CVA) Questions:
Does the task add a form or feature to the product or service?
Does the task enable a competitive advantage (reduce price, faster delivery, fewer defects)?
Would the customer be willing to pay extra or prefer us over the competition if he or she know we were doing this task?

Business Value-Added (BVA) Questions:
In addition to customer value-added activities, the business may require you to perform some functions that add no value from the customer's perspective.
Is this task required by law or regulation?
Does this task reduce the financial risk of the owner(s)?
Does this task support financial reporting requirements?
Would the process break down if this task were removed?
Recognize that these activities are really non-value-added but you are currently forced to perform them. You need to try to eliminate or at least reduce their cost.

Non-Value-Added (NVA) Questions:
Does the task include any of the following activities: counting, handling, inspecting, transporting, moving, delaying, storing, all rework loops, expediting, multiple signatures?
...

(p 52-53)

Links:

Its About Time - an article about the importance of time in lean and value.

Reducing NVA Office Work - applying lean in an office environment.

Lean Six Sigma on the Electronic Business - some lean six sigma success stories.

Inventory is Ignorance - reasons that lean is so hard to do.

Posted by Mishkin Berteig at 04:22 PM | |

July 12, 2005

Why Should Business-People Care About Continuous Integration?

Continuous integration, and for that matter, TDD, FDD, and other Agile practices and methods can be obscure to someone who hasn't run across them before. Since some Agile approaches really relate to engineers more directly than to their managers and executives, I have been asked why business-people should care about some of them?

The question might be examined from the other side - how do things that are important to the business side relate to things happening on the technology side. Put yet another way, is the whole organization in-sync and harmonious, or is the left hand interfering with the right. Finding consistency of vision and values across disciplines within an organization can be very difficult, but there are good examples of business' values being reflected in engineering practices.

Kaizen, for example, is an increasingly common business watch-word. It's philosophies of waste-reduction, orderliness, and continuous improvement have radically affected Toyota's much-vaunted production system, for example. This philosophy, and other principles have influenced Total Quality Management, Lean analysis, Six Sigma, and other value-oriented business management practices. Kaizen is often translated as meaning a continuous improvement in small increments, and in practice is almost a micro-quality-control. The idea that a single defect can bring a production line to a halt, so that the defect is caught early and fixed when it is cheap springs from this approach. (Kaizen is much more than this, and often also refers to a short high-value problem-solving session that uses related principles. Kaizen, in this context, refers to the process philosophy and the practice thereof, cf. Kaizen.)

Continuous integration is a software engineering practice that is quite similar. When combined with test-driven development, it forms a kind of Toyota-style production line scenario. Continuous integration basically means that all changes to the software are integrated with the rest of the software as soon as the developer submits the change to the central repository. At that point, or at very near intervals, the whole system is run through unit and integration tests to see that it is still healthy. If a defect arises, either through a mistaken submission, or the submission of something that breaks something else, the system alerts the developer, and possibly relevant management. The system "goes red", as the jargon goes, and the developer rapidly fixes whatever is out-of-sync. This is quite analogous to Toyota's "stop the production-line" approach to quality management.

Assigning power so close to the ground can be frightening to both executives and technical employees alike. This is understandable. People used to controlling everything often find it hard to delegate to the "shop floor", and people who are used to posessing little power are often afraid to wield it once it is granted. Both the arenas of technology and business, however, have established, through volumes of evidence, that defects caught early can be orders of magnitude cheaper to fix. Toyota lept ahead in its reputation of quality very soon after implementing such a system. Businesses that use Kaizen or other related approaches to quality management and process evaluation on the business side can see these principles at work in their software development organizations.

As with most good things - simple principles, broadly applied to specific disciplines, work to the overall benefit of the organization. They provide confidence and common vision and value across disperate specialties. Business stakeholders who make these high-level decisions can then have increased confidence that what they're defining, marketing, and selling won't fail them in execution in the customers' hands.

Posted by Christian Gruber at 04:58 PM | |

July 06, 2005

Some Comments on the Three Agile Axioms

People are Creators

When people are creating, they feel fulfillment. If a person can increase the quality, speed, quantity, or uniqueness of their creation without reducing any of those, then that person will feel increased fulfillment.

Joint creation (people creating something together) develops strong relationships among the people doing the creating. And in a very nice feedback loop, strong relationships among people empower exceptional creation.

Reality is Perceived

We can increase perceptual ability in order to understand reality more completely. In the sciences, this is done by creating tools such as telescopes. For teams, this can be done with coaching and training as well as communication tools and practices.

A team can use a common vision to align perception. Perception that is aligned can create harmonized beliefs. Harmonized beliefs allow a team to work in a united fashion.

People can choose what they perceive. For example, a person can choose the value of some work that has been created. People can also choose how they perceive change.

People disagree because they have chosen to perceive different aspects of reality.

Change is Constant

Stasis, the lack of change, is death.

Responding to change is our natural state. For example, our eye and the neurological system for sight is designed to be attracted to changes in our visual field. Our minds have the capacity to learn which is based on exposure to new experiences or ideas (and new experiences are another sort of change).

Posted by Mishkin Berteig at 10:34 PM | |

June 22, 2005

Agile Enterprise Reference Model

There is a very interesting paper online that presents an Agile Enterprise Reference Model. From the paper:

Sponsored by the Agility Forum, this 1996 reference model project had two principal goals: 1) design a reference model structure that effectively captures and displays the essence of enterprise-wide competency at both proactive and reactive change; and 2) validate the design with a rich, comprehensive example that provides an instructive reference case for an entire enterprise. The purpose is to provide a defining profile with examples for business managers and executives responsible for strategic planning, operational management, and reengineering.

One very interesting part of the reference model is a Change Proficiency Maturity Model. In this model, an organization can be described by its level of maturity in adapting to and creating change. The levels of maturity are as follows (again quoted from the paper):

0: Accidental - Stumble through change, recognition but no awareness.
1: Repeatable - A set of rules for acheiving change become understood.
2: Defined - Rules broadened and performance metrics put in place.
3: Managed - Objectives clarified, rules refined, accountability in place.
4: Mastered - No longer rule based - principles guide action.

There is a logical correlation between these levels and the various aspects of the Agile Work framework. The Repeatable and Defined levels of Change Proficiency match up with the various Agile Work Practices such as Maximize Communication, Self-Steering Team, and Adaptive Planning. The Managed level of maturity matches up with the Agile Work Disciplines of Empower the Team, Amplify Learning and Eliminate Waste. Finally, the Mastered level of maturity corresponds to the Agile Work Axioms: People are Creators, Change is Constant and Reality is Perceived.

Posted by Mishkin Berteig at 03:52 AM | |

June 16, 2005

Engaging the Environment

In a recent discussion I had with someone about the Agile Work Axioms, he mentioned that he thought that "people are lazy by nature". Here is my brief response:

I don't totally agree. Those who are motivated for whatever reason to do something will be "not-lazy", and those who aren't motivated will be "lazy". But the fact is, that I don't think laziness is a fundamental truth about human nature. I think it's a consequence of how engaged we are with our environment, which in turn is a result of both our internal state, and how attractive our environment is. Television is a great example: it is so engaging that we will sit around doing nothing even if it becomes physically quite uncomfortable. Normally, laziness is associated with avoiding discomfort.

In terms of engaging with our environment, the three Agile Work Axioms define a system of engagement:

Posted by Mishkin Berteig at 10:44 PM | |

June 13, 2005

Reality is Perceived - So What?

Results are necessary to reach a goal. Work is done to produce results and reach a goal. Therefore, any work done that does not produce results that contribute to the goal is wasteful. The degree to which a result of work contributes to the goal is the degree to which that work is valuable. However, since reality is perceived, it means that the stakeholders' perception of the results is of paramount importance. If a team produces a result that the stakeholders do not find valuable, then at that time, it is not valuable. This is both obvious and subtle. If the stakeholders have an articulated set of values, then it is easier for the team to produce results that satisfy those values. However, it is often the case that stakeholders will also have unarticulated values. These unarticulated values are just as important. Agile Work attempts to use various disciplines and practices to elucidate, draw out and make explicit the values of the stakeholders so that the team can produce results that are satisfactory.

Posted by Mishkin Berteig at 10:01 PM | |

June 05, 2005

Scrum Evolution: What's it all about?

Love it or hate it, the Agile 2005 Conference reviewers thought the paper below was either a major innovation or a gross violation of the principles (dogma) of Scrum. It's motto is innovate or die and only the paranoid survive in the global economy. Does it show the future of Scrum? Well the paper was accepted for presentation at Agile 2005 and many people have asked for the real bits (all 27 pages) before I chop it down to the required 10 page IEEE paper. It could take you to CMM Level 4 or beyond. Decide for yourself whether this paper should be burned or nailed on a door somewhere!

Future of Scrum: Support for Parallel Pipelining of Sprints in Complex Projects

Jeff Sutherland, Ph.D.

Certified ScrumMaster Training

Patientkeeper, Inc., Brighton, MA, US

Abstract

Scrum was invented to rapidly drive innovative new product to market. Six month releases used to be a reasonable time from for an enterprise system. Now it is three months for a major new release, one month for upgrades, and one week for maintenance releases. The initial version of the Agile Scrum development process was designed to enhance productivity and reduce time to market for new product. In this paper, one of the inventors of Scrum goes back to Scrum basics, throws out preconceived notions, and designs Advanced Scrum using multiple overlapping Sprints within the same Scrum teams. This methodology delivers increasing application functionality to market at a pace that overwhelms competitors. To capture dominant market share in 2005 requires a metaScrum for release planning, variable length Sprints, overlapping Sprints for a single team, pre-staging Product Backlog, daily Scrum of Scrums meetings, and automation and integration of Product Backlog and Sprint Backlog with real-time reporting. A practical example of Advanced Scrum describes how mobile/wireless product teams implemented Scrum process automation during 2000-2005. Administrative overhead for over 45 enterprise product releases a year was less than 60 seconds a day per developer and less than 10 minutes a day for a Project Manager. While Advanced Scrum is not for the uninitiated, the future of Scrum is still Scrum, just faster, better, and cooler.

Posted by Jeff Sutherland at 11:42 AM | | | TrackBack

June 02, 2005

A Little Something from The Theory of Constraints

<br /> The Theory of Constraints or (ToC)[Google] is introduced in the book "The Goal">The Goal" by Eli Goldratt. At its most basic level, the theory of constraints posits that there is only one thing right now preventing your team from going faster. It is the weakest/slowest link in a process or procedure.

How do you find that one thing? There are various possibilities depending on the sort of work environment. One way, that is appropriate to a manufacturing-like process is to identify the Work in Process (WIP) pileup. If you are working in a more human-skills based process, then ask "if you can only hire one skill set, what would it be?"

In an agile process framework like Scrum, there is constant discovery of the constraints (although possibly not the one specific constraint that is slowing the overall process). This discovery is encouraged by the Scrum Master and is exposed by team members as they participate in their daily "scrum" status meeting. An important feature of this meeting is that the team members identify any barriers to the performance of their work. The Scrum Master is then responsible for removing the barriers that are identified.

In organizations that are very paper-documentation oriented, often approval gates are one of the worst constraints in a process. Those who must approve the team's movement to the next step must receive the documentation they need, then find the time to read it, then find the time to formulate their decision, and then find the time to communicate it to the team. I have been in environments where this can take a few months (I'm sure some organizations are worse, and many are better than this). During this time, the team is essentially idle.

Another typical problem exists in organizations that have gone through several rounds of layoffs in a short time period. In this situation, often the constraint is due to an unbalanced skill distribution. The organization may have very few people with a specific critical skill. The only way to remove the constraint (and speed up) is to add more people with the skill either by hiring or by training.

In general, because of their short iterations, and the resulting amplification of learning, agile teams tend to expose many constraints in the organizational environment. This can be a cause of backlash against the agile team.

Posted by Mishkin Berteig at 10:01 PM | |

May 31, 2005

Scrum and its Relationship to Other Management Techniques

(On relationships of Scrum,TOC, BPR, Systems’ Thinking, Knowledge Management, TQM, Complexity, Manufacturing, New Product Development, etc.)

Although there are great synergies between TOC and Scrum, there are also vast differences. Both provide patterns to resolve systemic problems akin to those described in Systems’ Thinking by Senge, but TOC resolves systemic problems that are more akin to process improvement ala TQM, rather than complete overhauls as in BPR, which I argue, is closer to what Scrum does – it reengineers the process from scratch, by implementing high performance patterns altogether.

For the most part, TOC, and The Goal, assume a somewhat repeatable business process, where the process of removing constraints, exploiting constraints, finding new ones, etc.; is an ongoing process in a somewhat stable, repeatable process.

Scrum, on the other hand, generalizes this technique in the absence of a repeatable process, it simply removes *any* constraints constantly, with no assurance that the constraints removed will remain so the next day, and that the particular constraint optimized
“has been removed”, and that we can move on to new ones at that point. It is usually the case, however.

Another important difference is that a Scrum team is already an organizational structure that avoids process anti-patterns like handoffs, iteration and re-work (among different organizational structures, between an “analysis” team and a “design team” for example, or between an organizational structure building component A, communicating with another one building component B, in a Conway’s Law configuration i.e. where Organization Follows Architecture.

In that sense, a Scrum team is a true “Case Team”, as termed in Michael Hammer’s BPR, i.e. an organization structure that is *completely responsible* for the success of a process or project, where the ScrumMaster is the “Case Manager* ala Hammer, that responds to the Product Owner.

From the Knowledge Management perspective, TOC optimizes the process and therefore, more knowledge of the processes themselves are more valued, while in the Scrum (Case Team) perspective, the individual contributor’s knowledge is more valued.

On the other, and to make things slightly more complicated, Scrum sits atop a number of processes, that as more applications of the same kind are built, tend to be more repeatable, like configuration management, testing of certain components, vertical slice development or new applications on top of reusable architectural services.

The interesting thing to note, is that in Scrum, smaller reusable processes develop underneath as a base of knowledge but they don’t drive development, while the Scrum process, acts as a “work generator/work management” “process envelope” (a superprocess, or meta-process, if you prefer), that drives the work. (In Complexity terms, it is the Maxwell Demon that provides the autocatalytic cycles to drive self-organization, ala Kaufman’s “Origins of Order”.

Curiously, manufacturing is turning more and more to the original BPR patterns to build things. However, New Product Development always requires one meta-level more of work organization to handle the variability of “building something new every time”. In software development this difference evolves into a more continuum spectrum. The first application in a domain is New Product development, but as new ones get added, only a percentage is New Product development, the other percentage is more like manufacturing, and therefore more repeatable.

But don’t worry – no one needs to understand all the above gibberish for Scrum to work. On the other hand, it is nice to understand these things to properly understand Scrum in the context of other management techniques,

- Mike Beedle

Posted by Mike Beedle at 02:54 PM | |

May 28, 2005

People are Creators - Effectiveness

Our effectiveness as creators depends greatly on our knowledge and our skills. Less obviously, our effectiveness as creators also depends on our emotional and mental state, and even what some would call our spiritual state. Finally, our ability to create can be greatly magnified or greatly reduced by our environment, particularly the other people who are around us. Which is interesting, because our creative nature affects our environment.

Posted by Mishkin Berteig at 08:54 AM | |

May 27, 2005

Reality is Perceived

Our senses and the devices we create to extend our senses, are filters through which we perceive reality. We don't get to sense all of reality. Then, our minds take in the streams of information from our senses, and filter them further. Our attention or focus, our preconceptions, our mood, all determine the way we filter information from our senses. If we are feeling guilty, we may be more likely to hear other peoples' conversation as criticism. If we are feeling proud, we may be more likely to hear those same conversations as praise.

If our perceptions are wrong then no amount of logical excellence will give the right answer. So it is a pity that almost the whole of our traditional intellectual effort has been directed at logic and so little at perception.

Logic will not change emotions and feelings. Perception will.” (Edward de Bono, Textbook of Wisdom, 1996)

Posted by Mishkin Berteig at 10:33 AM | |

May 25, 2005

Agile Corporate Culture Change

In "The Corporate Culture Survival Guide", Edgar H. Schein describes a method for implementing culture change in corporations. He says:

As the change team works on the ideal state and the present state [of the corporate culture], it probably has to periodically redefine the change problem in terms of the gap or gaps identified. In other words, though the process is a set of steps undertaken in sequence, there are many feedback loops that force going back to earlier steps to guarantee clear thinking. . . .

As various gaps are identified in concrete form, it becomes apparent where cultural assumptions aid or hinder the change agenda. For example, having sales teams work together on big accounts may sound simple until it is discovered that the organization's individualistic culture prevents changing the incentive system to a group-based compensation program. The change program then has to shift to examining how to change some of the individualistic assumptions; this might entail an entirely new change program not previously thought about at all.

In other words, expect and embrace changes in understanding brought about by learning from work performed. Deliver corporate culture change work iteratively. Plan corporate change adaptively.

Posted by Mishkin Berteig at 03:46 PM | |

May 24, 2005

People are Creators

People are creators: we willfully change our environment, we imagine new things and through our actions, manifest those things in the world. All people do this. Human beings enjoy having an effect on their environment and seeing the results of that effect. We all have this ability. We all derive satisfaction from the exercise of this ability. And we can all learn to improve this ability.

In any endeavor we take on, we are attempting to create something new. A new system, a new object, a new pattern of behavior, or a new way of thinking. We are attempting to create change. This is one of three fundamental axioms of Agile Work.

Posted by Mishkin Berteig at 08:12 PM | |

May 20, 2005

Management and Business as Sources of Waste

Waste can be of several different types. Independent of what the types of wastes are, they can also come from different sources. When attempting agile work, it is essential to identify the underlying causes or sources of waste. Once these sources are identified, efforts can be made to change them so that they cause less waste.

Management is least effective and a source of waste in an agile work environment when it imposes decisions, plans work, and directs people. Management is most effective in an agile work environment as a facilitator, shield and servant.

Business can cause waste by not being focused or by being focused on un-profitable efforts. Paradoxically, business can also cause waste by being too focused on profitable efforts. A balance of investment in short-term, long-term and "cleanup" efforts is ideal for an agile work environment.

Posted by Mishkin Berteig at 07:55 PM | |

May 17, 2005

The Qualities of an Ideal Test

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

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

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

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

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

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

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

Update 20060106

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

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

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

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

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

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

and

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

Posted by Mishkin Berteig at 06:48 PM | |

May 13, 2005

Self Organizing Systems FAQ

Just a link to the Self Organizing System FAQ - glanced through it, it looks amazing.

Posted by Mishkin Berteig at 10:29 PM | |

May 09, 2005

Reasons for Conflict or Disagreement

As part of the Advanced Scrum Training, Esther Derby presents a section on conflict. One very insightful part of the presentation is a description of four reasons for the existance of conflict or disagreement. They are as follows (adapted from "Advanced Scrum: Collaboration Skills for Scrum Teams" (c)2004-2005 Esther Derby):

1. Lack of Clarity - the communication between parties is missing information or the information is not being communicated in a consistant manner.

2. Position Focus - the parties involved have already each decided on their own solution and are failing to discuss the problem those solutions are addressing.

3. Different Values - the parties are unable to agree because they are holding different sets of values but not articulating those values as part of the discussion.

4. Past History/Personalities - the parties have a previous unresolved conflict that is negatively affecting their ability to work together.

All of these types of conflict are based on either conscious or unconscious failure to be truthful... and therefore the different parties have incompatible perceptions of reality. The Agile Work axiom "Reality is Perceived" then gives us a hint as to how to resolve all of these types of conflict. Find a way to share perception among the parties in conflict so that they have a compatible view of reality.

Posted by Mishkin Berteig at 10:52 PM | | | TrackBack

May 05, 2005

Change is Natural - "Embrace Change"

Kent Beck's book "Extreme Programming Explained : Embrace Change" provides a good introduction to how software development can embrace the constant change that affects our world. Some of the practices he introduces are very software-specific. However, the overall basic message is sound and provides a foundational principle for all agile work. (By the way, the book is excellent.)

Change really does occur everywhere. Change is constant. A google search for "embrace change" or "change is constant" will both turn up an incredible variety of articles, papers, discussions, books and viewpoints that all affirm the constant nature of change and the need to embrace it.

Nevertheless, it is sometimes difficult to accomodate change when we also have a legitimate and deep desire to know what is coming next.

For many teams, the environment in which they work is constantly changing. This change can be caused by competition between organizations, scientific or technological advances, fads and cultural shifts, major events in people's personal lives or even just a change of opinion with a stakeholder. Any change, even small change, can invalidate a planned course of action. However, goals (as distinct from plans) are more stable and often survive even major environmental changes. Therefore, rather than trying to plan the future, an agile team can focus on being able to respond to change while still reaching a goal.

Nevertheless, a team needs some sense of what it will do in the near future. A team can work with a “horizon of predictability”. This is the distance into the future which a team can be reasonably certain that plans will be stable. Depending on the environment, this may be as little as a few minutes, or as long as a month. It is rarely longer. The horizon of predictability is not a precise demarcation, rather, expect change with a probability based on the horizon of predictability. Then, plan to respond to change. Be detached from the concrete details of a plan, particularly if they occur outside the horizon of predictability.

Responding to change requires a major mental shift for many people that is difficult and takes time and environmental support. People are often penalized socially or formally for being flexible or adaptable. This quality can appear to be “wishy-washy”, uncertain, indecisive, uncommitted or even rebellious.

The terms “agility” or “agile work” refer to this principle of embracing constant change since it is the most visible of the principles. However, the ability to respond to change relies on the establishment of agile work disciplines and practices.

Posted by Mishkin Berteig at 06:57 PM | |

April 28, 2005

Plan Methods Oppose Agile Work Axioms

Plan driven methodologies which attempt to mechanize the process of doing work are in opposition to the three Agile Work Principles.

We are Creators
A plan methodology attempts to define intermediate and end work products independently of the input and effort of those who perform the work of creating the work products. This disenfranchises people from their work and leads to low morale. It also establishes a heirarchy of value for the people working on an effort where those who create the plans are perceived as more important or valuable than those who execute on the plans.

Change is Natural
This principle is usually acknowledged, but is usually described as a "problem" to be dealt with rather than as a basic principle to be fully embraced. A plan methodology has "change control" or "change management" and "risk management" and puts the whole notion of change in a negative light. This approach also disenfranchises people because they are constantly placed in opposition to reality.

Reality is Perceived
Plans attempt to legislate reality. "Thus and so must the project go" results in a constant struggle between the plan and peoples' perception of reality. Plans marginalize the importance of perception on the belief that reality can be objectively understood. If reality can be objectively understood, then it can be mechanistically manipulated. Thus results can be pre-determined without regard for the perception of those results.

Plan Principles.gif

Posted by Mishkin Berteig at 10:54 PM | |

April 26, 2005

Truthfulness and the Three Agile Axioms

A few more words are in order about how Truthfulness is the foundation upon which the three Agile Axioms rest. Taking them one at a time:

1. We are Creators

Truthfulness operates at a very deep level for this agile principle. People typically are not aware of their own need to shape reality, to create things. Developing truthfulness helps a person to uncover this fundamental capacity and bring it to fruition. Truthfulness also helps a person reflect on the results of their creative work. This is essential for learning how to become a more effective creator. In an agile team, truthfulness is also essential in developing the interpersonal trust necessary to know when the process of creation is going aright or awry.

2. Reality is Perceived

This principle is the most obvious domain where Truthfulness plays a role. In this instance, being able to express one's perceptions and share them with others in a truthful manner allows others to develop empathy and formulate an honest response. If Truthfulness is missing, then perception will be based on something other than reality (well,... technically it will be based on the reality of an untruth). In an agile environment, where the value of communication and collaboration is extremely high, truthfulness helps to develop a shared perception for a team.

3. Change is Natural

Here the role of Truthfulness is simple: an agile team cannot function if it is not Truthful about change. Recognizing and communicating change so that a team can embrace it and adapt to it depends completely on people being forthright and truthful about change.

Much of my thinking about Truthfulness comes from the study of a passage from the Sacred Scriptures of the Baha'i Faith: "Truthfulness is the foundation of all human virtues." I have also had substantial discussions with other agile coaches about the importance of truthfulness and its key role in developing trust.

Posted by Mishkin Berteig at 11:51 PM | |

April 19, 2005

Considering the Agile Manifesto and the Axioms of Agile Work

The Agile Manifesto, aimed squarely at software development, is inaccurate when considered against the more general target of Agile Work. The Agile Software Manifesto reads in part:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

Having studied Scrum, and attempted to apply agile practices on non-software projects in non-corporate, non-new-product-development efforts, I am painfully aware that the Agile Software Manifesto needs some re-jigging to become the Agile Work Manifesto. My first cut at doing this was to remove the software implications from the above four statements of value. This resulted in the following three statements of value:

Individuals and Interactions are preferred over Processes and Tools
Moving Towards a Valued Goal is preferred over Producing Ephemera
Responding to Change is preferred over Following a Plan

I removed the part about customer collaboration because I felt that it was strongly implied by "Individuals and Interactions" and "Moving Towards a Valued Goal" and because not all efforts have identifiable customers in the sense that a business effort usually does.

Once I got to this point, I started to feel like the statements of value were not really getting to the fundamental assumptions or principles or axioms of Agile Work. I thought quite a bit about each value and what it was really saying at a very basic level. For example, "Individuals and Interactions over Processes and Tools" is partly about the value and power of human beings. What is that power? "Moving Towards a Valued Goal over Producing Ephemera" begs the questions of what is a valued goal? and can ephemera be valued? and for that matter, what exactly constitutes ephemera and its opposite? Finally, "Responding to Change over Following a Plan" is really saying that plans don't tend to work. And why is that? So in order to answer those questsions, I have come up with the following three Agile Work Axioms:

People are Creators
Perception Mediates Reality
Change is Constant

People are creators and that's why its so important for us to improve ourselves and our interactions with others. Perception mediates reality and that's why we must produce results that are perceived as valuable to those who care about our results. Change is constant and that's why following a plan never works... unless you "embrace change" (Beck). But there is still something missing. There is a foundation necessary to make these principles work together in real human environments.

Truthfulness is the Foundation of Agile Work

Posted by Mishkin Berteig at 10:32 PM | |

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

August 17, 2005

The Viable Systems Model

August 12, 2005

Just-In-Time Value Delivery and Waste Elimination

August 08, 2005

Value redux (more on business value added)

August 06, 2005

Generalizing Specialists

August 04, 2005

Just In Case You Haven't Seen It Yet

August 02, 2005

Memory and Mystery

August 01, 2005

Broadcast Mode Communication

July 25, 2005

Applicability Matrix Tool for Iterative Delivery

July 23, 2005

The True Cost of Software

July 21, 2005

Waste and Value: Basic Lean Concepts

July 12, 2005

Why Should Business-People Care About Continuous Integration?

July 06, 2005

Some Comments on the Three Agile Axioms

June 22, 2005

Agile Enterprise Reference Model

June 16, 2005

Engaging the Environment

June 13, 2005

Reality is Perceived - So What?

June 05, 2005

Scrum Evolution: What's it all about?

June 02, 2005

A Little Something from The Theory of Constraints

May 31, 2005

Scrum and its Relationship to Other Management Techniques

May 28, 2005