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. http://blog.gdinwiddie.com/2011/07/11/process-standards/ "

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.

Reflections from LSSC12 conference in Boston

The LSSC conference was held in Boston May 13 - May 18 at Seaport Boston Hotel

The Venue was the beautiful Seaport World Trade Center

The Lean Systems and Software conference held in Boston was a mind blowing positive experience - I am completely filled with inspirations and reflections from the conference, and I have decided to blog some of the topics here. The conference repeated the point to balance demand to capacity, which is easy to understand, and yet in everyday life often  hard to adopt to.

Overall topic: Balance demand to capacity
When we look at pictures of freeways we understand that we don't want to optimize for utilization but rather for fast throughput or low waiting time. When we use computers we understand that starting many programs at the same time competing for the ressources, at a certain point will make the throughput significantly slower. Business and projects also need to limit work in progress to capacity but is often challenged to do more. In general the advice is to either a)  increase capability, or b) reduce demand, in particular failure demand. For example by ensuring that the problems we solve, are the right problems to solve, or c) finally it was suggested that it is possible to some extend to shape the demand, for example by talking with a customer and client to discuss what the right demand is. I think this picture makes the point:

Kanban and Scrum are execellent methods for teams to visualize what the teams capacity is, and facilitates this way the creation of realistic plans. The concept of product owner in Scrum and a prioritized backlog in Scrum or prioritized tasklist in Kanban is a way to ensure that demand is reduced to the most valuable or relevant tasks.

Insights and reflections in a map
I have grouped my insights and reflections on the map below, and within the next weeks, I will write additional blogs for each topic presented here:

A. I did a two day tutorial titled "Strategic Innovation on Demand". The core point is that all innovations are about solving a problem for a customer or the environment, and this tutorial presented a great way to identify  current and future problems for customers, using a disciplined approach. Often innovation is thought of as a right brain activity, like when a musician improvises or a painter paints. This tutorial showed convincingly that  there are left brain activities, in other words structured disciplined activities, that can guide you to the points where you could exercise right brain creativity. The core message is you can use a disciplined approach to identify problems and then apply creativity in solving these problems.

B. Many of the presentations addressed  the question: "How have we validated, that we are solving the right problem?". Steven Spears talked about having expectations and be surprised, and presented the example: "How can we improve this milkshake". The example showed that even the best experts can be wrong about what the problem really is.

C. Problem Solving by professionals, was a point carried by Mary Poppendieck, and she urges implementers to reclaim responsibility for design. The presentation ended with an outstanding good discussion comparing "set-based development" and "Lean startup", expressed in the two questions: "When does it make sense to develop multiple options?" and "How do we remember what we have learned?".

D.  Another hot topic at the conference was Lean Startup. The recent focus on Lean startup creates an increasing need for projects to be able to do continuous delivery as opposed to just continuous integration and test. Lean startup provides guidance on how to validate that the right need and problem is addressed.

E. Another topic mentioned several times was flow in work. It applies to the entire value chain but is in particular an interesting topic for projects doing maintenance and operations work. Kanban can be used as a structured way to visualize work and establish explicit policies to improve flow and other lean measures.

Impressions from Agile 2011 in Salt Lake City 2011

The Agile 2011 conference was held at the Grand America Hotel in Salt Lake City. A great party of 1600+ people from more than 40 coúntries met to share ideas and experiences on Agile. It was a great week with many friends and a lot of learning.