Like in Agile Software Development
Outside look in
I provide an outside look in, from an
agile or entrepreneur perspective. The basic pattern is to look for
better ways ahead. Better ways and alternate ways, choose and try,
again as needed. Inspect and adapt.
Some suggest agile helps with
“improving business value”, others “improving revenues”, and
others suggest “reducing costs.” I concur, and suggest thatiit's a blend or mix
that varies from “lean and mean” to sur/petition where the
business adopts features lifting it above normal competition.
There often is a
big thinking-doing gap between software developers and business people. They speak differently, they may dress differently,
their goals and their personal reward systems probably differ. The
business people and the techies effectively work in different silos.
If you scatter the techie software people around inside the business
to change their awareness and bonding, you ruin their tech
teamworking. You're much better off to do agile work in a common team
room, where much of the knowledge is implicitly/tacitly passed
around. Jumping to a similar model, Crew Resource
Management, nobody scatters aircrew around inside aircraft, they all
go in the cockpit. Together.
Do it together.
A good first step is training techies
to talk business and to understand the business. We can directly do
that, and I prefer to add an indirect approach. Have more
business-aware techies teach techies and business people meet
techies, in gatherings and in patrols, for two ways learning. We
naturally patrol out to our boundaries, so encourage visitors to find
a tad of time to cross silos and chat. Grow growing relationships.
Wash through obstinacy and inertia and divergent thinking. Agile
software development includes something called pair programming, so
do some of that after-a-fashion at business desks while working on
business. Peer to peer learning can be extremely effective and
particularly in this case matches mentoring and the ancient process
of learning a craft. I help you help that happen, in an agile way.
Better Relationships
One of the normal goals, and outcomes,
is a better business to development team relationship, more effective
communications, and faster better software development. Some like
better ROI. Again, I like sur/petition, rising above competition with an
edge factor.
A.G.I.L.E. (A)daptive (G)oal
driven (I)terative (L)ean (E)mergent
As we develop a richer perspective and
better relationships, we can gain a better awareness of the overall
business situation, and ways to improve the situation. Done well we
may well grow the agile process outside the teamwork into some teams
that network together. We use the agile – entrepreneur process as a
discovery process and extend it in our patrols. It becomes a living
learning network.
The outside look in often yields ways
to improve flows, to adopt lean ways and improve the overall process.
It's very common for silos to have differing goals and divergent
interpretation of goals, and some of that can be mended.
Sometimes it's all reversed. In a
startup or just developing a new product the business team is
entrepreneurial/agile but the techies want Big Design Up Front. You
might also mimic this with an expert who has his ways that dominate
the developments instead of adapting to current reality. Some big
Japanese companies only let the experts in after other people have
massaged things into shape first.
Another aspect that I have done a lot
is working with cross-cultural, cross-lingual learnings. You may have
teams where the 'silo' is caused by other-country culture or
language. That pattern is similar and the similar goal is effective
communications, perfect needs to be well off in the background.
Effects of coaching emphasis
XP 'coaches' are often more akin to
mentor-trainers, directly imparting knowledge, and they train in an
agile fashion. Agile business coaches work more with a business
angle and train in an agile fashion, more in the hard-to-handle soft
area in between and less techy. Bridging.
I can't predict your XP-tech skills,
and I prefer to have the software team hunt up XP type knowledge,
from books and the web, then teach it to each other. With my help.
They are smart so I can be quite dumb and it still works okay. When
done well, I'm guiding them in developing speaking – presentation
skills, and teamwork and meeting skills, under the XP learnings. They
learn stuff techies like, by doing it. Given a choice I make parts of
it like Toastmasters and suggest that people also do Toastmasters
after work. Part of the pattern is to network learning, to minimise
single source silo learning, and to grow ongoing self-reliant
learning in the team. People in the business should be adopting a
growing 'inspect and adapt' process. The equivalent medical doctor saying is "See one. Do one. Teach one." (bury two).
Hero's Journey
Follow Your Bliss
An underlying pattern for developing
agile teams matches Joseph Campbell's “Hero's Journey” and or
his “follow your bliss.” Learning and appreciating the Hero's
path, and using some apt quotes, can make the journey a lot more like
“follow your bliss” into success. Or you can just call it
teambuilding. If so, please add the journey and the vision beyond a
simple goal, add the tug. A fair number of people in various parts of
your organization might feel that tug so it becomes a common theme, a
thread in a web that pulls people together.
The tug blends 'the Formal and the
Informal' as expressed in the set below. Organically together. The
together result is an emotionally rich environment. Such relationship
based environments can do better, adapting to stresses and changes
like a tree grows in the wind. A living dynamic balance.
Formal and Informal
Formal Informal
Efficient Adaptive
Scalable Local
Predictable Innovative
Controlling Motivating
Clear Ambiguous
Disciplined Spontaneous
Hierarchical Collaborative
Rational Emotional
from “The Logic of the Formal; the
Magic of the Informal” in “Leading Outside the Lines How to Mobilize the Informal
Organization, Energize Your Team, and Get Better Results” by Katzenbach & Khan
People who feel the need for hierarchy,
control, engineering and efficiency tend toward the Formal, they
alter the yin yang balance towards their way.
Lean to TPS, and so on
Lean Toyota Production System (TPS) aka Thinking Production System (TPS)
MBA (old) MBA ( some, revised)
Engineering Art, Craft, Engineering
Project Management Project
Management, with relationships
Shan Zhai
This back and forth jumping of viewpoints is an
ancient process. Read "Outlaws of the Marsh" for one view, and the Agile Manifesto for a
modern Western version. Shan Zhai is the modern Chinese name for a rough equivalent of the "Outlaws of the Marsh." The Shan Zhai pattern is (in)famous in Shenzhen, and the pattern lives well in Guangdong. Shan zhai translates as 'mountain fortress', beyond official rules - doing things that work instead of just following rules - adapting to reality and into growing success. Shan zhai cell phones copy brand name ones at a much lower cost, partially by avoiding IP and research costs, and successful shan zhai outfits enlarge their successes, just like weeds take over a garden.
You can visualize the shan zhai approach as having the map in mind allowing you to take an alternate road on your daily commute when the radio reports a traffic problem. Some easily switch routes, others don't. Some want rails, others want the flexibility of roads. Explorers go right off-road, into the weeds.
Roads tend to get built following successful explorers, maybe rails if there's lots of heavy freight, developing things in an ancient innovating to doing to perfecting pattern.
If this is all too fuzzy, think of skunkworks, where they
deliberately isolate new stuff from the interference of traditional factory-thinking
ways.
Try 604-657-9595 or Vic@windwaterwine.com