onsdag den 17. oktober 2012

Why do organizations want standards across teams?

October 17, 2012


Background for this particular blogpost

It all started with this tweet: why do organizations want standards across teams?

I read it on a beautiful morning while drinking my morning coffee and thought "I have an answer to this: There can be no Kaizen when there are no standard. Standards are the foundation for repeatability and innovation".

Almost immidiately I received the responses below, and knew that I would have to elaborate my argument and the context for my argument. :
"For Kaizen you need "standard work" within the team. That does not imply standardizing across the organization. Standardizing across teams interferes with the team making improvements. "

The blog asks the question "Why do organizations impose standards across teams". Another question to consider is "what standards if any should a team work according to".

Sometimes there are useful reasons for imposing standards

In some rare cases it may be useful to impose an external standard to a team - BUT in most cases this is not the case.

 Although I agree to a large degree to the argument, that teams should own and maintain their own processes, I think it serves well to state that there are situations where imposing a standard makes sense - but I think they are few and focussed. For example if you develop software to health care, like an electronic patient record system or if you develop software to run on-board an JSF fighter jet, you may want to impose (some) quality standards that are not owned by the team.

I once had a conversation with a naval officer, who said: "There are regimes (standards) that you want". There are often externally standards related to security imposed to the team of sailors. They are established on experiences from decades of sailing as opposed to invented by the team on this particular ship right now. Can the crew on a particular ship add or modify such standards - I don't know but I believe so.

The reason for such standards are often rooted in an argument on repeated performance. If you follow this standard we believe it will help you achieve the same performance as others have done in the past (fires or other hazards detected timely on ship, desired minimal clinical or operational quality in software to avoid unanticipated critical results e.g. like fatal wrong medication of a patient, or a plane falling down from the sky.

One size (standard) does not fit all

Standard work should be defined by those who do the work. Define only the standards needed, and assume talented people use the standard and decide how much is written into the standard.

So in some special situations I believe there are valid reasons to impose an external standard across teams - but often this is not the case.

I believe the main issues on the standards for a team is:
  • The team should have ownership to own "standard work"
  • Standards should be written by and to the competent people doing the work - in other words it is not a training manual for somebody else to learn the work, but something that the team finds helpful in doing a professional work.
One of the challenges, in talking about this topic, are some of the unspoken assumptions:
  • Organizational standards are made by somebody else than those doing the work
  • Organizational standards are generalized too much or are too specific to be useful
  • There is one and only one standard, and you have to follow it exactly as written
I believe there is another way, although examples are few, where:
  • Organizational standards are discovered and collected from those who do the job related to the standard
  • Standards are slim and document "just enough" to support a professional who is already trained or experienced in the work
  • The organization has identified the needed set of alternative standards and criteria for teams to select from these alternatives.
 I don't believe in all teams making all their own standards. Then a process like Scrum would have millions of different interpretations with their own priest. I suggest we have a shared understanding where core parts are agreed to. A very slim organizational Scrum standard could be: there are three roles PO, SM and Team, you do these few meetings and make sprint and product progress visible. Such a slim standard for Scrum leaves room for professional Product Owners and Scrum Masters and Teams to do what they do based on their competence and experience. However following the standard will ensure that 3 roles, relevant meetings and assets are established. On the other hand this standard did not mention velocity or empediments,  or many other aspects that could be considered part of the standard. Such aspects, if needed, will be be learned as experience with the standard is accumulated.

Another aspect of teams using organizational standards is that teams to tailor the organizational standard to the specific needs of the project. Following rougly the same standard in many projects allow for knowledge sharing and learning across many teams.

This approach is not: "We find that person who’s most productive, and have everyone else work the same way",  it is more something like: "Take into account the best knowledge you and your peers have created so far, and adapt this to your specific situation building on own experience and competence".

Organizational standards also serve a purpose to predict performance, and allows for evaluation of wheteher an improvement delivers improved performance. If you dont have a baseline of standard work you dont know if other ways of doing the work are improvements or just other ways.

We all agree that Taylorism and a "bad" organizational standard imposed is not the answer. I think the opposite approach: complete local ownership of standards by teams is also not the answer. Many people try to make the world binary - I believe there is a whole universe between 0 and 1. Across teams there may be few and slim standards, that also is part of the organizations accumulated learning. Teams start from this foundation but adapt the standard as need to the job. You may call that 0 or 1, I believe it is a sweetspot in between.