Fred Nickols wrote:
> A while back the CEO asked me to design a process for use in developing
> the company's strategic research plan. Typically, processes are defined
> in terms of the input-process-output or state-change paradigm, the
> conversion or transformation of one thing or form into another. The
> state-change model is fine for materials, data and even some information
> processing applications. In my view, it does not work as well with
> knowledge-based processes. So, I began by defining "process" in the
> context of strategic planning as "a set of recurring, patterned
> conversations." Such a definition leads quickly to a concern with
> conversation-related matters such as venue, agenda, discussants, timing
> and so on. Process design, then, becomes a matter of structuring and
> organizing these patterned conversations. (I also happen to think that
> many efforts wearing the label "knowledge management" could be greatly
> improved upon if knowledge management were viewed as a process consisting
> of patterned conversations, but that's a different story.)
>
This is in agreement with my experience. (See the "SCRUM Socializes
Knowledge" pattern at the end of this note. This pattern won't tell you
the whole story, because to do so I would need to include the whole
pattern language, which is my submission to PLOP98.)
Meetings and meeting formats, together with the definition of roles and
their relationships (inside and outside these meetings), can be very
powerful, specially when they are tailored to a particular purpose.
I believe their power is partly associated with the fact that they are
operate at a higher meta-level, that somewhat makes them more constant
than the "process". (For example, you know you are going to have Scrums,
regardless of the process created by the assigned tasks at hand. That
adds certainty to the meta-process, not to the process itself, which can
vary widely.)
I also find that these meetings are great "culture builders". If you are
getting results with them, they become addictive!
>From the anthropological view, they are the "rituals" of the particular
subculture. They have associated "shared language", they define roles and
relationships, and their outcomes and artifacts have associated
"meanings". All of these things combined help in the creation, change or
preservation of a culture, so they help create or preserve "corporate
memory".
This is important, because "processes" in general are easy to forget,
because we humans are not tuned to remember "processes". But we are tuned
to remember things that recur in time, because that's how our mind works.
We are creatures of habit, and our mind remembers and more naturally
reacts to recurring patterns! (Gestalt, Piaget, etc.)
>From the knowledge management perspective, "structured meetings"
(rituals) can provide a community with a way to "rapidly socialize tacit
knowledge", and therefore they can make a truly operate as a "learning
org".....
Fred Nickols wrote:
> One very positive thing I can tell you about our current effort
> is that everyone takes an immediate liking to the definition of
> knowledge-based processes as "sets of recurring, patterned
> conversations." It is almost as though words have been given
> to something they have always known to be true.
When I talk about Scrum with others that have experienced
hyper-productivity, they always say things like:
"We didn't do it so formally, but we
were doing something similar".
or they say:
"We did something similar through email...", etc.
I agree with your assessment, and in fact fits very
well the definition of a pattern:
"It is almost as though words have been given to
something they have always known to be true."
(Btw, many other org patterns connected to the SCRUM meetings, concentrate
on the roles and their relationships surrounding SCRUMs: ScrumMaster,
Sprints, BackLog, etc.)
Fred, I hope you decide in time to document your "patterned meetings" as
Org Patterns, you might be breaking new ground in Strategic Management
indeed.
- Mike Beedle
http://www.fti-cosulting.com/users/beedlem/
[draft: to be submitted to the PLOP98 conference]
Name - SCRUM Socializes Knowledge
Context
You are engaged in an activity that is difficult to control because its
predictability is limited. For example, the activity may require constant
change in directions, it may add new tasks as it unfolds, or it may
require unforeseen interactions with many participants.
Activities such as scientific research, innovation, invention,
architecture, engineering of any kind and software development typically
exhibit such behavior common to "creative tasks". As such, you may be a
"knowledge worker", and engineer, a writer, a research scientist, a
software developer or an artist; or a coach or leader that is overseeing
the activities of a team such as a Coach, a Team Leader, a ScrumMaster, a
Manager or a Firewall in a development team, etc. (From: Case Team,
Developer Controls Process [OrgPatt])
Problem
What is the best way to control an empirical and unpredictable process
such as software development, scientific research, artistic projects or
innovative designs?
Forces
- Project plans in medium to large software projects typically fail
because estimates for assignments are hard to come up with.
- It is not always possible to determine a deterministic process for a
task.
- Estimation is important. One must be able to determine what are the
future tasks within some time horizon.
- Planning and reprioritizing tasks take time. Using too much of the
knowledge workers' time in planning meeting decreases productivity.
Solution
Meet with the team members for a short time in a daily SCRUM meeting. A
SCRUM meeting is a 15. minutes meeting where each participant only answers
the following 3 questions:
1) What they worked in the last 24 hrs. The ScrumMaster
logs what tasks have been completed and what remains
undone.
2) What blocks if any they found in performing their
tasks within the last 24 hrs. The ScrumMaster logs
all Blocks and later finds a way to resolve the Blocks.
3) What they will be working in the next 24 hrs. The
ScrumMaster helps the team members choosing the
appropriate tasks to work on. Because the tasks are
schedule in a 24 hr basis the tasks are typically small
(Small Assignments).
The SCRUM meetings typically take place at the same time and place every
day. The ScrumMaster leads the meetings and he logs all the tasks from
every member of the team into a global project Backlog. He also logs
every Block and he resolves each Block while the everyone works on the new
assignments.
SCRUMs can also be held by self-directed teams, in that case someone is
designated as the scribe and also logs the completed and planned
activities of the Backlog and the existing Blocks. All activities from
the Backlog and the Blocks are then distributed among the team members for
resolution.
The format of the Backlog and the Blocks can also vary, ranging from a
list of items in a piece of paper all the way through software
implementations over the I NTERNET/INTRANET [Schwaber97]. The Scrum cycle
can be adjusted according to needs but typically does not exceed the 48
hr. cycle or decreasing lower than 2 hrs.
Scrum meetings allow knowledge workers to accomplish mid-term goals
typically allocated in Sprints that last for about a month.
Rationale
Because it is very easy to under- or over- shoot an estimate, that either
leads to idle time or to delays in the completion of an assignments
respectively, it is better to sample frequently the status of small
assignments. In other words, processes with a high degree of
unpredictability cannot use traditional project planning techniques only,
such as Gantt or PERT charts because the rate of change on what is being
analyzed, accomplished or created is too high. Instead, constant
reprioritization of tasks offers an adaptive mechanism that provides
sampling of "systemic knowledge" over short periods of time. SCRUM
meetings help also in the creation of an "anticipating" culture
[Weinberg97], because they encourage "productive values":
- increase the overall sense of urgency,
- promote the sharing of knowledge,
- encourage dense communications and
- facilitate "honesty" among developers i.e. everyone has to give a daily
status.
Simultaneously, this same mechanism, encourages the team members to
socialize, externalize, internalize and combine technical knowledge on an
ongoing basis, thus allowing technical expertise to become "community
property" for the community of practice [Nonaka95]. SCRUM is therefore a
ritual with a deep cultural transcendence.
Seen from the System Dynamics point of view [Senge94], software
development has "scheduling" problem, because the nature of programming
assignments has a rather "probabilistic" nature and estimates are hard to
come by because:
1) inexperienced developers, managers and architects are
involved in making the estimates
2) there are typically interlocking architectural
dependencies that are hard to manage
3) there are unknown or poorly documented requirements, or
4) there are unforeseen technical challenges
etc.
And therefore software development becomes a chaotic "beer game", where it
is hard to estimate and control the "inventory of available developer's
time", unless increased monitoring of small assignments is implemented
[Goldratt90], [Senge90]. In that sense SCRUM meeting become the
equivalent of a "thermometer" that constantly sample the new team
temperature [Schwaber97-2].
Examples
At Nike Securities in Chicago we are using SCRUM meetings since February
of 1997 to run all of our projects including BPR and software development.
Everyone involved in these projects receives a week of training in SCRUM
techniques.
Resulting Context
A structure such as CaseTeam or a Self-managed team is jelled into a
highly adaptable and hyperproductive organizational structure.
(Connections: ScrumMaster, Sprint)
References
[Goldratt90] E. Goldratt, Theory of Constraints, North River
Press, Great Burlington (MA), 1990.
[Nonaka95] I. Nonaka and H. Takeuchi, The Knowledge Creating
Company, Oxford University Press, New York, 1995.
[OrgPatt] Org Patterns web site:
http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns?ProjectIndex
[Schwaber97] K. Schwaber's, SCRUM web page:
http://www.controlchaos.com
[Schwaber97-2] personal communication.
[Senge90] P. Senge, The Fifth Discipline - The art and Practice
of the Learning Organization, Doubleday/Currency, New York, 1990.
[Sutherland97] J. Sutherland, SCRUM web page:
http://www.tiac.net/users/jsuth/scrum.html
[Weinberg97] G. Weinberg, Quality Software Management - Vol 4.,
Anticipating Change, Dorset House, New York, 1997.
--"Michael A. Beedle" <beedlem@fti-consulting.com>
Learning-org -- Hosted by Rick Karash <rkarash@karash.com> Public Dialog on Learning Organizations -- <http://www.learning-org.com>