Rediscovering the Obvious

…stumbling in the footsteps of greatness

That’s not X!

without comments

Mark Graban has a great post [1] over at Lean Blog today. His overall premise is one we see over and over again in software: People take a good tool, apply it poorly or in the wrong context, and then blame the tool. Worse, they occasionally broadcast their blame, causing people to have a lower reputation of the tool.

In software, this is most recently seen in the certification discussion and in the “Scrum vs. kanban” conversation. As a result, I very much want to call out a couple of things Mark says in the healthcare context that apply equally well in the software context:

But the difference I draw from the Lean critics:

  1. They see L.A.M.E. and leap to the conclusion that Lean is inherently bad. They throw Lean under the bus and take the tone that these leaders are “idiots.”
  2. I see that Lean works well when leaders learn about and embrace the full management system. I work to try to educate healthcare leaders who are smart, but have a different viewpoint on management.

This is absolutely what I see with agile, lean, scrum, and kanban quite frequently. Teams try, fail, and blame the tool. Yes, it’s quite possible the team tried the wrong tool. It’s also quite possible they didn’t actually use the tool the way it was intended. [2] It could be their context is wrong for that tool in the first place, or that they changed their labels but didn’t change anything they actually do, or that they did things right but ran into a management wall, or faced struggles scaling out to other teams, or any of the hundreds of other reasons that adoptions “fail”.

We amplify this with the way our labels and language creates lines rather than identifying a body of perspectives and tools. It’s time to take a cue from BDD and define some scenarios and well-formed outcomes of the adoption. Mark presents a great list from a nursing perspective…

Why would nurses WANT Lean? When organizations really embrace Lean:

  1. Nurses say, “Finally! Management is seeing the problems we face every day and we’re going to work together on fixing things.” Instead of feeling neglected, they are being properly supported and involved in process improvement.
  2. The culture changes to fix routine “Every Day” problems – instead of jumping through hoops and constantly fighting the same fires, they get to focus more time on patient care.
  3. Lean helps support save care – proven documented examples include reduced patient falls, fewer infections, and fewer cases of V.A.P. — nurses want the best for their patients.
  4. With Lean, the space is designed and sized to match the processes for nursing care, instead of nurses being forced into spaces that don’t have enough bed/equipment storage space, for example.
  5. They get to design their own standardized work and can improve it through daily huddles and kaizen boards.
  6. The nurses get to work as part of a team (such as ThedaCare’s Collaborative Care model, where the RN helps direct doctors and pharmacists.
  7. Nurses work less overtime because they have more time during the day to do proper charting instead of batching it at the end of the day.

These sure feel like things I can see and validate against when they happen. What’s our list look like for software? Here’s a few that come to mind immediately:

  • When a stakeholder asks for a release, it’s done quickly, easily, and with a minimum of fuss.
  • When a stakeholder identifies an opportunity related to the current application [3], it’s not painful to make it into reality.
  • When a problem is discovered with the app, it’s professionally and quickly fixed without attacks or defensiveness.
  • Simple and appropriate improvements are accepted and implemented with a minimum of fuss regardless of source.
  • Teams work in ways that suit them while still respecting their organization
  • People go home, have families, and maintain good balance despite loving their jobs
  • People care about the end result, not just their own specific job
  • Individuals are respectful across specializations, and attempt to use a shared language and goals rather than engaging in “legalese” or “geekspeak”.

What else?

[1] All quotes attributed to “Mark” are from this post, used with permission:

[2] Personally, this is where I stop because I feel like I’m approaching the “If it works, it’s Scrum, if it doesn’t, you did it wrong” perspective, but that’s not useful, so I’ll continue.

[3] Using “application” as shorthand for “software stuff we build” including systems, services, apps, etc.

Written by erwilleke

November 9th, 2010 at 4:00 pm

Posted in Uncategorized

Leave a Reply