Agile Advice: Agile Work Theory Archives

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.

Posted by Mishkin Berteig at 04:20 PM | |

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

Value

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.

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 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 principle "Perception mediates Reality" 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 Constant - "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 | |

May 04, 2005

Can dying plan-based projects be recussitated?

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

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

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

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

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

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

Timeboxing and Iteration

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

Daily Meetings and Iteration Review

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

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

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

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

Feature Lists, not Task Lists

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

Customer-Prioritized Features

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

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

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

He faints.

Smelling salts are brought.

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

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

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

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

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

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

"What does that mean," he asks.

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

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

"Yep."

"Please help me..."

Conclusion

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

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

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

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

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.

People 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 Constant
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.

Perception mediates Reality
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. Humans 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. Perception mediates Reality

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 Constant

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

April 13, 2005

Backlogs in an Organization - Levels of Queues

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

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

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

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

Queue Levels in an Organization.gif

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

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

Posted by Mishkin Berteig at 06:19 PM | |

April 06, 2005

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.

Typically, an agile team works by taking iteration-sized chunks of work off of the project backlog. 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 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 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. 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.

Posted by Mishkin Berteig at 11:58 PM | |

Agile Advice

Thoughts and experiences for practitioners following the Middle Way to Excellence.

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

Value

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

People are Creators - Effectiveness

May 27, 2005

Reality is Perceived

May 25, 2005

Agile Corporate Culture Change

May 24, 2005

People are Creators

May 20, 2005

Management and Business as Sources of Waste

May 09, 2005

Reasons for Conflict or Disagreement

May 05, 2005

Change is Constant - "Embrace Change"

May 04, 2005

Can dying plan-based projects be recussitated?

April 28, 2005