“Andon” is the “stop the train”
system used in Lean Manufacturing to encourage teams to be aware and immediately raise any issue, no
matter how small, that might impact quality and value.
The heart of the system is the “Jidoka” mindset.
Jidoka is the attitude of
“Problems are Treasures” – the first response of leadership when the Andon is
pulled is to say “thank-you”. Regardless of whether a real issue or a false
alarm, the response is always, “thank-you”.
What does this mean for software teams?
Recently there
was a event that surfaced with one of the teams I was working with.
There had been a situation where
the normal test procedures/environment protocols were not followed. My
understanding was that things worked out, but should not have happened that
way.
There were a number of potential
“Andon moments” where "stopping the train" would have been useful:
- the
recognition of the underlying problems that necessitated the deviation,
- the
lack of satisfaction with regular “best” practice,
- the
decision to not follow procedure,
- dealing
with the difficulties of the work around,
- dealing
with the consequences arising from the deviation,
- the
moment it was mentioned in standup,
- scheduling
a follow-up to discover root cause,
- placing
on the improvement backlog the need for exploring countermeasures to the
root cause,
- recognizing
the need to improve the team’s best practices,
- etc
The key to implementing Andon effectively is to make it “trivial” to raise the concern. If there were a physical
visual management system, jot on a sticky note and put it up. Or perhaps send a
message on Slack. Something that requires “no effort” to do.
Next is the response. What are
the protocols you implement in response to “stop the train”? These protocols
will evolve (under leadership guidance) for each team/product/organization.
Does the team triage immediately? Address the issue? Place it on a backlog?
Ignore it? I recommend explicitly articulating (publishing, posting and
improving) the protocol.
For example, a team I worked with last year had created a three-level “Alert Box”, where anyone could
post (a sticky note) with any issue at any level of concern at the bottom level (in
addition to putting it on the team Slack channel). If by the time of the next
stand-up, the issue had not been dealt with, it was “moved up” to the next
level, etc. If it reached “the top” and was still unresolved the entire project
(33 people including on/off/near shore) would drop everything else until the
issue was dealt with one way or another.
They got to that system as a
balance between a number of forces/pressures on the project including the usual
suspects: behind schedule, over-promises, new technology, new team members,
off/near shore communication, etc.
Posting forced accountability.
It was incumbent on managers and senior technical personnel to respond. The
person who raised the issue, who “pulled the cord”, was empowered to accept or
reject the response.
In addition, senior managers and
even the business side Executive VP who was funding the project would routinely
visit the team’s Visual Management System to get a feel for how things were
going. The VP made it clear that he expected to be tasked to help fix anything
that got near the top.
So what would be the recommendation for you?
Pick something (that will be “wrong” and “won’t work”)
and constantly improve it. The first step is mindfulness, that is, everyone
simply being aware of what they are thinking and doing.
Celebrate each time the
train is stopped until everyone feels comfortable with raising issues. Say
“thank-you” when they are. Show on Leadership's visual management system how management is
responding to systemic issues. Etc.
Encourage everyone to constantly
ask the Three Questions:
- Is
this of value to the customer?
- Is
this the best way to do it?
- Are
we learning anything?
And if the answer is “no”, pull
the cord!
No comments:
Post a Comment