Tuesday, January 8, 2019

What is the software "Andon" cord?


“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:
  1. the recognition of the underlying problems that necessitated the deviation,
  2. the lack of satisfaction with regular “best” practice,
  3. the decision to not follow procedure,
  4. dealing with the difficulties of the work around,
  5. dealing with the consequences arising from the deviation,
  6. the moment it was mentioned in standup,
  7. scheduling a follow-up to discover root cause,
  8. placing on the improvement backlog the need for exploring countermeasures to the root cause,
  9. recognizing the need to improve the team’s best practices,
  10. 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 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:
  1. Is this of value to the customer?
  2. Is this the best way to do it?
  3. Are we learning anything?
And if the answer is “no”, pull the cord!

No comments:

Post a Comment