Ten Commandments for Minimising Medical Errors

Via Bob Sutton,

Dr. Michael Guiliano's Ten Commandments for Minimising Medical Errors:

1. I shall not believe everything I hear from the doctor
2. I shall first listen to the patient
3. I shall not fall in love with my first diagnosis
4. I shall not believe everything I hear about test results
5. I shall explain everything to everyone
6. I shall involve the patient in everything.
7. I shall communicate with peers precisely
8. I shall take personal responsibility for the patient’s clinical problem
9. I shall not believe everything the consults say.
10. I shall say “I DON’T KNOW” regularly and go get the answer

For innovation to flourish, measurement must rule

I'm continually surprised when people tell me that they don't know about Todd Hoff's High Scalability site.

The Amazon architecture section has a link to a fascinating series of blog posts by Greg Linden on the early days of Amazon. My favourite quote from one of the posts:

For innovation to flourish, measurement must rule

The next best thing to listening to John Shook in person

John Shook was the most impressive speaker at the Lean Summit I went to earlier this year.

The Lean Thinking Network have a couple podcasts with him on Toyota culture that you should check out:

• Part One
• Part Two
  

More thinking about "Agile" vs "Waterfall"

I was recently asked to comment on someone's presentation on the differences between "Agile" and "Waterfall", especially when one should choose one over the other.

Here are some things that I came up with:

Waterfall has been considered an obsolete life cycle for a long time now by experts and experienced professionals. Alistair Cockburn has a nice summary article at Crosstalk including a reference to a conference report from the first 1968 conference on software engineering where even then, people are bagging on the waterfall approach, though I don't believe it was named that yet. A more well known article also exists by Craig Larman and Victor Basili.

Be careful about saying that Waterfall is more disciplined. The waterfall model is simple and structured but the "discipline" is in following prescribed steps as opposed to "discipline" in thinking. The second kind of discipline is by far the more important.

Fixed scope isn't sufficient to decide to use Waterfall. You essentially want close to zero risk which would include fixed scope, well-known technology, well-known capabilities, and limited competitive pressure. The other models (iterative, incremental, agile) guarantee higher cost in exchange for better risk management. If none of the risks eventuate, waterfall is cheaper. In his 1970 paper, Royce's argument was that when systems get big, that's not the bet you want to take.

An unavailable product manager and/or segregated teams do not lend to Waterfall. One would instead expect an iterative and/or incremental model to manage the risk of integration and validation problems. By definition with an unavailable product manager and/or segregated teams, it's not really Agile.

There are many sources of iteration. Misunderstandings about the technology, mistakes by the team, change in market place due to competitive pressure.

Set-based Concurrent Engineering (SBCE) is a sequential, non-serial, non-iterative life cycle. SBCE is a sequential parallel approach which doesn't iterate but instead explores multiple options and weeds them out according to a preset timeline. Development does start before all the requirements are known though because the solution space is being explored at the same time as the problem space is being explored. Everything starts high level and vague and successively refines together.

Agile principles I would suggest as a refinement of the values (borrowed and modified from XP):

• Open, honest communication
• Rapid, concrete feedback
• Prefer and create simplicity
• Courage to play to win
• Respect and develop people
• Reflect and improve forever

Triggers for when to use Agile (any one could trigger):

• There's an advantage to get something partial out now rather than everything later
• Not familiar with technology - want to reduce risk
• Want to engage and develop staff
• Competitive pressure for adaptation and faster delivery
  

It will be difficult to be effective if you have unskilled, untrained employees though in this case a more disciplined Agile approach, specifically XP should be preferred. See Ralph Johnson's experience. Agile creates more pressure than Waterfall to develop competence and experience. Thinking about the long-term performance of the organisation, you should prefer this. I would say that XP provides an explicit path for teams to respond to that pressure.

Co-location is not a factor to choose Agile; it's a requirement for it. However, that doesn't mean you need co-location to be effective. Open Source teams are not typically co-located. Toyota's product development approach does not require co-location (though I think they're preferring it now). If you don't have co-location, you need to compensate... but you can also flip it around and say co-location is compensating for a lack of discipline in other things. I'm okay with either interpretation. The important thing is understanding the trade-offs. You can be effective with so-called Distributed Agile.

Test? I don't think that word means what you think it means.

What is meant when someone says "test"?

Does it mean "verify"?  Making sure something works as you expect.

Does it mean "specify"?  This could be in the sense of a document in a V-Model life cycle or an executable specification in the sense of Test Driven Development or Behaviour Driven Development.

Does it mean "validate"? "Are we building the right thing?" vs "Are we building the thing right?"

Does it mean "describe"?  That is using the tests as an executable description of the existing system.

Does it mean "explore"?  This could be in the sense of understanding how an existing system works or in the Lean Product Development sense of understanding the boundaries of potential solutions (aka Test then Design).  This latter is more about asking the question "Are we building this the right way?" more often than the question "Did we build this the right way?".

Toyota, combinatorics, team sizes, and purpose

For some reason, some old posts from Gemba Panta Rei started showing up again in Google Reader.  One of them referenced a post by Pete Abilla using combinatorics to explain the issues of increasing team size due to exponential growth of communication links.

Jon Miller also references the average team size at Toyota, 4 - 8.

Don't remember why, but I recently re-read Corey Ladas's "Lean scales differently than Agile" post from last year:

A consequence of Scrum and the “scrum of scrums” is that such a small span of control will create a deep hierarchy as you scale up. That’s not very lean. A lean organization ought to be pretty flat, and a span of control of 40 is very flat indeed.

 I found those odd statements given that Toyota uses team sizes of 4 - 8.  David Anderson  responded to Corey's post and asked how big an effective standup could be.  I responded in the comments referencing what I've tried with Fishbowl Standups.

Since then, I've visited a Toyota plant and learned that they run daily production meetings.  I also recently stumbled upon Joe Ely's posts on daily startup meetings.  So here's my current thinking, which I'll modify from a phrase that Joe used...

The purpose is not to meet; the purpose is to improve.

The large stand-ups and for that matter large teams don't allow enough engagement to have all individuals support that purpose.

Tactical vs Strategic misses the point

Here's the dilemma.

We have time constrained market opportunity. We have budget constraints. We have limited knowledge in whether a more complicated design will work. Therefore, we generally prefer the simpler or at least more well-known design.

This is rejected because the solution is "tactical" and doesn't address enterprise standards.

We've run multiple projects over the years. Each project only does enough to satisfy the project's goals. New projects are taking longer and have more problems due to the confused and inconsistent way things are done on existing systems. Therefore, we want to have designs that look beyond the single project and consider the health of the enterprise architecture.

By the time the right enterprise solution is determined, the opportunity is lost, the project budget is blown... and many times the more complex solution doesn't actually work anyway.

We have a common objective, presumably the success of the organisation, but we have two responses that are apparently contradictory and ineffective.

What's wrong?

The entire way of thinking about this is wrong. The problem is not about tactical vs strategic solutions.

Let's say I have a system that consists of 3 components. Each component has an 80% chance of success, where success means that it works and that it is completed on time.

This means that we have (0.8) * (0.8) * (0.8) = 0.512 => 51.2% chance of success.

If we instead choose simpler components that are more likely to be successful, let's say 90%:

(0.9) * (0.9) * (0.9) = 0.729 => 72.9% chance of success.

This is why that if we are interested in project success, we so aggressively prefer simplicity.

Well, instead of looking at single point solutions, what if we instead have multiple options? So for every component, I have at least a very likely backup (>90%) as well as one or more that better satisfy enterprise goals.

Now for an insurance premium, which is known through timeboxing, of maintaining multiple options, I guarantee that I have the highest probability of being successful. The alternatives to this approach are immediate failure (too complicated design to satisfy enterprise needs so project fails), eventual failure (too many tactical designs that enterprise architecture becomes a mud ball), or some combination of immediate and eventual failures.

To summarise, in situations where the simplest solution is not optimal for strategic goals, you should nonetheless always maintain the simplest solution as a backup option to protect the success of the project. As better but more sophisticated solutions are proven, then we swap them in. This is not about "tactical" vs "strategic". This is about effective risk management and getting as close as you can get to guaranteed success.

It's not my fault, it's the vendor's fault

I've recently been encountering the old perception that Fixed Price Contracts means that the contractor or vendor takes on all the risk and responsibility for the project.

Let's think about this.

Presumably the project is supposed to satisfy some business goal.  So when the system doesn't work or isn't ready in time, what do you say when the customer of that business goal complains?

"Oh, it's not my fault, it's the vendor's fault"

I wonder if customers care more about whose fault it is or more about whether they can achieve their goals?

I think it's time to think less like an administrator and more like an engineer.  When you delegate risk, the risk doesn't go away.  All that happens is that you are now accepting unknown risk.  Being able to wave a contract at someone when a risk eventuates is not a valid risk mitigation strategy.

When starting a project, establishing a target cost and date with general objectives makes sense.  Establishing contractually-obligated cost, date, and scope at the start of any significantly sized project is the height of foolishness.

Work together, establish trust, use processes and techniques that have a higher likelihood of delivering the right thing, at the right time, for the right price, at the right quality.  Don't allow anything to interfere with that, including simplistic contracts.

When ethical funds exist, you must expect the opposite

Via Signal vs Noise,

The Vice Fund...

The Vice Fund invests in companies, both domestic and foreign, engaged in the aerospace and defense industries, owners and operators of casinos and gaming facilities, manufacturers of gaming equipment such as slot machines, manufacturers of cigarettes and other tobacco products, and brewers, distillers, vintners and producers of other alcoholic beverages.

This is just wacky... and if you look at the fact sheet, they're not actually doing that well anyway. Unless you have the time and money to be sophisticated, I say just stick to index funds, dollar cost average (or perhaps value average if you have the time), ride it out, and think long term.  Avoid the gimmicks.

HTTP headers and status codes

Via rest-discuss,

Trying to get your head around which HTTP status code to return when?  Alan Dean has an activity diagram showing the resolution of response status codes given various headers.

Respect, develop, collaborate

A recent rough sketch on what should happen if respecting, developing, and collaborating with people is valued:

The role of expert knowledge in winning leaders

Via Bob Sutton, a Cornell paper studying whether experience and success as a player is related to success as a coach:

On average, teams with former all-stars as coaches placed six spots higher in league rankings than teams with coaches who had never played in the NBA, a huge bump-up in a league with only 29 total teams during the years studied.

Some things are going to cost a lot of money, and they aren't going to work

From a quite interesting IEEE Spectrum article on countering IEDs:

“That’s why we pay the generals the big bucks. It takes risk. Some things are going to cost a lot of money, and they aren’t going to work. Get over it.”

-- Lt. Col. Jeremy G. Mansfield, director of Canadian Forces EOD

What if an MBA prepared John McCain's visuals?

Garr Reynolds blogs about the effectiveness of John McCain's recent address to the Republican National Convention.

The funniest part is the what if scenarios at the end.  What if an MBA prepared the visuals? Lawrence Lessig?  Takahashi? Apple?

The problem isn't intelligence

The problem isn't intelligence; the problem is initiative.

I know this because I can't really systematically destroy people's intelligence but I can systematically destroy their initiative.

Pixar on management, risk, creativity, and innovation

Via Clarke Ching,

There's a Harvard Business Review article where Ed Catmull, president of Pixar, talks about how things work at Pixar:

Talent is rare. Management’s job is not to prevent risk but to build the capability to recover when failures occur. It must be safe to tell the truth.

Target utility before appearance

An entry at the Web Form Design book blog points to a thread at the IxDA discussion forum about whether to use an explicit "optional" or a more subtle visual indicator in a web form:

That said, we recently did similar prototype testing on several search forms with a mixture of required and optional fields. On the team we were split on the best approach, so we tried to distinct methods: one with optional spelled out, the other with those fields having a different visual indicator. Though the sample size was limited, the "Optional" won hands-down. Remarkably, some participants even commented on how much they liked that it said "optional right there".


I know our UI team was not thrilled, but it was extremely advantageous to spell it out rather than use an icon or other visual indicators.

Utility comes first... and then after a few other things, take a look at appearance.

Mandate and legitimacy vs engagement and consensus

When a government is elected with a significant portion of the votes, they are said to have been given a mandate to enact their policies.

We may also talk about a government's legitimacy or where it derives its authority.

Mandate and legitimacy are about power.  Democracy is not about mandate and legitimacy; democracy is about engagement and consensus.

The language of power has no place in a true democracy.

Thinking about the important factors in automated testing

Communication - Providing an answer to the question "What are we testing?". Especially for product owners, customers, test managers, business analyst and generally any stakeholder that is not familiar with the test code.

Performance - How long does it take to get feedback from the automated test suite?

Safety - How confident should we be that passed tests mean that the feature actually works?

Skills and training required - Developing and maintaining an automated test suite of any considerable size requires programming ability.  Anyone who tells you different is trying to sell something.

Maintainability - Same rules apply to a maintainable test code base as do a maintainable application code base.  It has to work, no duplication, communicates intent, and has no superfluous parts.

Scalability - With a handful of tests, you can pretty much do anything.  When we're talking hundreds or thousands of tests, skill, discipline, and effective design matter.  Many tools and teams are not prepared for this.