Good stuff, in particular about lean, at Reforming Project Management. Applicable to agile work in many circumstances.
Good stuff, in particular about lean, at Reforming Project Management. Applicable to agile work in many circumstances.
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).
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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:
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.
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.
Not all of the Agile Work Practices apply in all circumstances. The Applicability Matrix Tool is a very simple visual tool to indicate when a practice can be used. The matrix has two dimensions. The first is the size of the performing team: an individual, a tightly constituted team or a loosely constituted full community. The second dimension is the amount of innovation in the work being performed: rote work, adaptive work, or creative/experimental work.
Each of the nine combinations of the two dimensions in the matrix is given a value: Not Applicable, Apply with Caution, Applicable, Essential. Here is how it looks:
The Applicability Matrix Tool is based on the experience of people using agile practices but currently does not have academic research behind it to back it up. As such, please consider letting us know if you have suggestions for the tool itself, or about how the tool is applied to any of the Agile Work Practices. Over the next few weeks, this tool will be provided for each of the six Agile Work Practices.
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?