The propensity where you might
really benefit from dealing with me, is on the make-it-work creative
edge, on the innovative end of the spectrum. Yes, I can do very well
at the perfectionist end, and a lot of business stuff doesn't
necessarily fit the innovator-perfecting model. Still, my personality
and the benefits for you lie in bigger changes. Well, key small
changes with big effects are nicer. Or more key benefits in a shorter
time. These success patterns match the agile development pattern and
the entrepreneur pattern.
To make it work, we start at the bottom
of the wimpy tree, (it's called a just-barely-good-enuf-tree). Or a lean tree if you like. We
seed things, develop some basic roots, and come up with the most
important stuff to do first. This puts us where the two side branches
go off. They symbolize options, or aims, and a place for the low
hanging fruit.
In agile, we work on this first most
important stuff as a team for a week. It's commonly called a sprint
and the length of time varies. At the end of the week we show the
results for wider review, and maybe put them into production. Just
like a startup company, we want fast apt early results to verify that
we did it right, to get paid, to please the client, and to adjust via
our review of our learnings from doing it. If you're into wicked problems, this is a design pattern for handling them.
Now we're at the second set of
branches. We arrange a new package of most important stuff to do in
the next sprint, and do it. If you are getting personal coaching we
often don't want too many choices, three is optimal. Whereas Toyota
might have a set of twenty choices at each stage when it's designing
cars. My forte in consulting is finding choices, and then we rework
to a socially/culturally acceptable set. It all depends. The basic
idea is to have just enough most important work, a reasonable set of
branches to ensure fruit, and just good enough quality. We learn by
doing and adapt to fit. The key phrase is
“Decisionmaking of every sort is
far, far better with diverse views of any flavor. Period.” --
Tom Peters
If you have any conifer trees around
you might go out and count the number of branches in a set. You'll
see that each set, it's actually called a whorl, actually spirals up
a bit along the tree trunk. If the top of the tree is broken one of
the upper branches will start bending up and become the new top or
leader. That's the pattern we want for handling failure in our
process. We want fast success and we want to be able to fail fast.
Learning by doing as we go. It's also "go see for yourself" as in TPS/lean. In a natural pattern – hey I'm a Taoist
country bumpkin, natural is good. Just in case, failure/errors are
good, they are teachings and should be seized to grow success.
If we over-plan, over document, we
tether our choices, and we produce too many leaves, and they hide the
basic success pattern. We're apt to get lost in the woods, and fruit
tastes better than leaves.
If you don't like trees we can do it
sideways. More like a simple frugal graph. Or the available options
each step of the way as we're developing something. You might think of it like 'swarming' the matter with choices early on. Then less variation as
it finishes and gets polished. Bring in your MBA/six sigma over on the right side.
Or we might blend it into a more
realistic graph of production over time, so it wiggles.
Simple, visual, lean.
Routing across your map
It can be worked into routing across a
map when we look at adding intersecting options. A famous paper by
Christopher Alexander is called “A City is Not a Tree” because
living city complexity is beyond simple logical planner tree-option
thinking. The natural city pattern is a web, that keeps growing
beyond any city map. If an organization is a community it's probably
really a web too. If we're coaching several people at the same time,
and successfully introducing changes into your organization, they are
probably growing a new web of relationships.
Anyway, the pattern is that we
produce things fast, fail fast, learn, and adjust as we go. Don't
over plan so we can factor in the learnings. Adapt to the market,
which also means being sensitive to the market.
The actual planning documentation can
be done on a wall or white board, some place you look at, with
three headings: To do, Doing, Done. Put stick-its with
very basic descriptions, called stories – what you're gonna do,
under each heading. Move the stick-its as you go. A typical agile
team talks through the higher priority stories in the To do
section, selects & estimates what it can do in a normal cycle,
called a sprint - maybe a week long, and starts work on those stories. TPS and lean call this kanban, which has a Japanese and Chinese meaning like "look at the stuff on the wall."
To Do Doing Done
As the team does them, the stories go from To
Do to Doing and the finished ones go into Done. At
the end of the sprint/cycle the Done stories are demonstrated,
and may be placed in full service. Simply show what you gained. Add a
review for learnings – inspect and adapt. Then they repeat
with the next set of stories. This is a lot more visual than most arrangements, and the visual simplicity helps it's success. We want continuous improvement, just like TPS/lean.
The agile pattern works for coaching,
solopreneurs, entrepreneurs, social entrepreneurs, many kinds of
projects and consulting, and me. It's a design pattern, for creating things in community, in close touch with their native community.
Daily Standup Meeting
Another kick at the can. The Todo Doing Done is also addressed daily. In a scrum meeting where everybody stands up - keeping to the point of the short meeting. Everybody answers three simple questions, like:
- Things I have done since yesterday's meeting
- Things I will do today
- Obstacles that I need someone to remove
We make it work for you.
Another kick at things. I use
processwork psychology/thinking, with Solutions Focused (SF)
thinking. One aspect of SF is that we find something that works,
narrow it down to a working solution, and use that. The diagram below
shows the process, going from all-over-the-place, exploring choices,
and maybe following fads, into following what fits you. The SF process
is basically the same as the agile process and the same as we follow
when we discover your High Performance Pattern – under the surface
they share natural patterns. Many human situations and many other situations are considered to be 'wicked problems', and this scheme works through such wicked problems - almost by accident.
This next is entirely compatible, and different to read:
Nonaka
believes that business “problems” (and something of their solution) are originally known tacitly by an individual (Nonaka, 1991). He offers a “spiral” process towards solution that begins in part-time, problem-focused work teams, which he calls “microcommunities of knowledge.” Members engage in “dialogues” between the tacit and explicit ways they hold knowledge; they engage in practices which first dis-embody and then re-embody tacit knowledge. The spiral describes stages in a process by which knowledge is converted first, among various tacit forms, second, from tacit to explicit states, third, among competing explicit possibilities, and, finally, from explicit existence back to tacit knowledge. Each knowledge conversion stage is distinct; each involves a different self-transcending experience for participants, and each calls for differing styles of personnel management. Organizational knowledge is created by the completion of all four conversations/conversions.
( in Tacit Knowledge And The Work Of Ikujiro Nonaka: Adaptations of Polanyi in a Business Context William D. Stillwell )
Using coaching:
An agile team should be peer-to-peer coaching each other, and may have an in-house or an outside coach. There are a whole swack of coaching models. I think the right model/way can make a big difference. For example many teams stall, they don't adapt well. I like to address things with a Five Phases model, like the
version below. Partially because it goes beyond the normal grid-type
spreadsheet logic. Beyond being 'right'. 'Right' locks us in place, instead we need to keep adapting. We can naturally correlate
it with our five senses and five fingers, and make coaching real.
It matches the simple utility of stand-up meetings. Real arrives with more fruitful walking-doing towards your
solution/goal. Use your variation of it in your coaching.
Now workshops.
Many agile
workshops follow the agile pattern. Start off with a first set, then
gather the team around and the team chooses the most important stuff
for the next set, then do that set. Rinse, repeat. Naturally, I like
that. If I can I also have members of the team teach it. I introduce
peer teaching, so one member of the group tutors the others. Peer to
peer is very often more effective than top-down or servant leader
teaching, partially because the self-teaching runs deeper in the
learning river. Many times I end up cycling between coaching
interpersonal skills, helping speakers and listeners learn, and
teaching the formal workshop material. The workshop shouldn't just
end, what we want is continued learning in the agile pattern. Given
choice we ensure in-house peer to peer coaching keeps the learning
tree growing, often with some outside coaching. You might also look
at the Agile Business Coach material.
Questions? Try 604-657-9595 or Vic@windwaterwine.com
