« June 2005 | Main | August 2005 »

July 31, 2005

Another Excellent Blog: Reforming Project Management

Good stuff, in particular about lean, at Reforming Project Management. Applicable to agile work in many circumstances.

Posted by Mishkin Berteig at 12:45 PM | |

July 30, 2005

A Simple Rule of Thumb

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

Posted by Mishkin Berteig at 11:09 PM | |

July 28, 2005

Applicability Matrix Tool for Colocated Team

AMT-ColocatedTeam.png

Notes:

1. Individuals are automatically co-located with themselves.

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

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

Posted by Mishkin Berteig at 11:46 PM | |

July 25, 2005

Applicability Matrix Tool for Iterative Delivery

AMT-IterativeDelivery.png

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

Book Review - "The Tipping Point"

Overview

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

Contents:

Assessment

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

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

Relevance

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

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

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

Posted by Mishkin Berteig at 09:59 AM | |

July 22, 2005

Applicability Matrix Tool for Self-Steering Team

AMT-Self-SteeringTeam.png

Notes:

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

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

Posted by Mishkin Berteig at 06:38 PM | |

July 21, 2005

Waste and Value: Basic Lean Concepts

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

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

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

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

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

  1. Customer Value-Added (CVA) Questions:
    • Does the task add a form or feature to the product or service?
    • Does the task enable a competitive advantage (reduce price, faster delivery, fewer defects)?
    • Would the customer be willing to pay extra or prefer us over the competition if he or she know we were doing this task?
  2. Business Value-Added (BVA) Questions:
    In addition to customer value-added activities, the business may require you to perform some functions that add no value from the customer's perspective.
    • Is this task required by law or regulation?
    • Does this task reduce the financial risk of the owner(s)?
    • Does this task support financial reporting requirements?
    • Would the process break down if this task were removed?
    Recognize that these activities are really non-value-added but you are currently forced to perform them. You need to try to eliminate or at least reduce their cost.
  3. Non-Value-Added (NVA) Questions:
    • Does the task include any of the following activities: counting, handling, inspecting, transporting, moving, delaying, storing, all rework loops, expediting, multiple signatures?
    • ...
 (p 52-53)
Links:

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

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

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

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

Posted by Mishkin Berteig at 04:22 PM | |

July 20, 2005

The Roots of Lean - Fabulous Article

The Roots of Lean [PDF] is a fabulous history of how lean principles and practices originated in WWI shipyards in the United States, grew through WWII, were transferred to the Japanese and then lost in the United States.

Posted by Mishkin Berteig at 06:10 PM | |

July 19, 2005

Applicability Matrix Tool for Adaptive Planning

AMT-AdaptivePlanning.png

Notes:

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

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

Posted by Mishkin Berteig at 10:39 PM | |

July 18, 2005

Sociometry and Team Building

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

Team Building

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

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

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

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

Posted by Mishkin Berteig at 11:09 AM | |

July 17, 2005

A Nice Little Intervention

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

Posted by Mishkin Berteig at 02:42 PM | |

July 16, 2005

Applicability Matrix Tool for Information Radiators

AMT for Information Radiators

Notes:

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

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

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

Posted by Mishkin Berteig at 06:45 PM | |

July 15, 2005

Applicability Matrix Tool

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

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

Agile Work Applicability Matrix Tool

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

See Also Applicability Matrix Tool for:

Colocated Team
Iterative Delivery
Self-Steering Team
Adaptive Planning
- Information Radiators

Posted by Mishkin Berteig at 11:49 PM | |

July 14, 2005

Innovative Teams and Change Agents

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

Posted by Mishkin Berteig at 10:08 PM | |

July 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 11, 2005

People are Creators - The Artist's Way

I have just started reading The Artist's Way by Julia Cameron. I found it interesting how affirming it is of the first of the Agile Axioms. The following are all quotations taken from the first couple of chapters of the book:

Through my own experience - and that of countless others that I have shared - I have come to believe that creativity is our true nature...
What you are doing is creating pathways in your consciousness through which the creative forces can operate. Once you agree to clearing these pathways, your creativity emerges. In a sense, your creativity is like your blood. Just as blood is a fact of your physical body and nothing you invented, creativity is a fact of your spiritual body and nothing that you must invent.
And few ideas are worse than the ones we have about art.
Why should we all use our crative power . . . ? Because there is nothing that makes people so generous, joyful, lively, bold and compassionate, so indifferent to fighting and the accumulation of objects and money. (Brenda Ueland)

Posted by Mishkin Berteig at 11:17 PM | |

July 10, 2005

Amplifying Your Effectiveness

At the Scrum Gathering in May, Esther Derby advised me that the AYE Conference is a great place to learn and meet other like-minded people. From the web site:

AYE is a conference that's designed to increase your effectiveness -- in leadership, coaching, managing, influencing, and working in teams.

The AYE Conference is for people who work in arenas where problem solving is a key skill -- environments such as systems development, product development, quality assurance, information technology infrastructure, customer service and consulting.

Posted by Mishkin Berteig at 10:25 PM | |

July 08, 2005

Interesting Study about Office Organization

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

Posted by Mishkin Berteig at 11:12 AM | |

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

July 04, 2005

Reporting for Accountability - Article by Geoffrey Slinker

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

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

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

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

TeamReporting.png

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

SelfSteeringTeam.png

Posted by Mishkin Berteig at 09:30 PM | |

July 03, 2005

Quotation from the ScrumDevelopment Group

On scrumdevelopment, Mike Dwyer wrote:

Agile is NOT about a logic tree, or a series of causal situations that can be expressed in a state table. Agile is about the management of the anomalous and the leveraging of failure into mind bending, industry shifting, success.

Posted by Mishkin Berteig at 05:31 PM | |

July 02, 2005

Agile Stickiness


In the book, The Tipping Point: How Little Things Can Make a Big Difference by Malcolm Gladwell, the author describes the idea of stickiness this way:

...the content of the message matters too. And the specific quality that a message needs to be successful is the quality of "stickiness." Is the message - or the food, or the movie, or the product - memorable? Is it so memorable, in fact, that it can create change, that it can spur someone to action?

What is it about agile that is its essential stickiness? What aspect or aspects of agile are both memorable and easy to act upon?

In the agile software domain, two examples of stickiness stand out. The first is the Extreme Programming (XP) methodology. The name, as well as some of the more controversial practices of XP such as pair programming and evolving design combine to be memorable and relatively easy to try out. The second example of stickiness is the Agile Software Manifesto. In this manifesto, the four values seem to resonate strongly with IT professionals and software developers... so strongly that many encounter them and then become hooked on trying to implement agile software development in their own sphere of influence.

For agile work in general, the term "agile" itself has some stickiness. The implications of speed, flexibility, responding to change, lack of bureaucracy, and skill rather than chaos are all very integral parts of the word when it is applied to a method of working.

Posted by Mishkin Berteig at 12:15 PM | |

July 01, 2005

Agile Project Management

Sanjiv Augustine, with whom I have had the pleasure of working, has created a neat little web site about Agile Project Management, a very close relation to Agile Work. From the site:

Agile principles are also being applied very successfully to non-software development projects. In particular, the underlying values of Agile Project Management (APM) as laid out in the Declaration of Interdependence are being applied in many organizations large and small to deliver value - reductions in time to market, reduced waste; and increased efficiency, collaboration and customer satisfaction.

The main difference is the explicit role of a manager. Agile Work fits with Agile Project Management, but is more generic: any person or team can adopt and adapt Agile Work practices and principles regardless of the existence of management.

Posted by Mishkin Berteig at 11:55 AM | |