For every complex problem there is a solution that is simple, neat and wrong. H.L. Mencken

In a twittersation with David Koontz I made a comment that methods/frameworks that rely on values and practices alone will necessarily have problems.  To truly answer this well probably requires several blogs:

• A few laws of software development
• Values and Practices Are Not Enough – why guidelines are essential
• When you have troubles with your guidelines you must go to your laws

However, I must admit I don’t have the time for that so will try to state succinctly, what I meant in one condensed blog where I just state my opinions and don’t necessarily try to explain how I got to them.  I can tell you that all of this is based on observing what has happened to the 100s of companies I’ve seen over the last dozen years attempt to do Agile with varying degrees of success and challenge.

First, a synopsis of this blog:

• practices apply only in particular contexts
• principles are guidelines that apply in broader contexts than practices, but still are not universal
• laws are universal and are created by the universe, not us
• values are created by us individually but apply everywhere
• since there is no silver bullet then no practice applies everywhere.
• This implies that any method that requires particular practices will not always be the most effective way to do things.
• Understanding principles will help you modify your practices to work in your situation.
• Understanding the laws of software development will help you understand which principles to use
• if you follow an approach that tells you to modify your organization based on its practices (e.g., Scrum), you may end up with an effective approach but you run the risk that it was an expensive way to get there

Now in English.

In a nutshell, the problem with a value and practice based approach is, you are left not sure what to do when your practices don’t work in your situation.  There are two common approaches to transitioning organizations now in the Agile community:

• Adopt a method that we know works and change your organization as needed to do so
• See where you are and adopt your practices to best fit your problem, organization and culture

Scrum takes the first approach, Kanban the second.  This does not mean one approach is better than the other – in fact, each approach has its own place.  I do find that for larger organizations the second approach tends to make much more sense.  I like to see which makes more sense – that is, understand the limits and best applications of both approaches.  Many in the Scrum community do not like to admit any places where Scrum will not works claiming “Scrum works wherever people will follow its practices.”  To me, however, this is like saying “I can get from Seattle to Miami by walking - anybody can, if they just do it.”  True, anybody could, but why would anybody want to?

Our goal should not be to use Scrum or Kanban or Lean.  It should be to be effective.  If being effective is your goal then I believe it’s useful for you to first, know there are several methods available to you and and second, learn how to tell which one is best for you.  Just picking a method to use without an exploration of available methods is a high risk approach.  The question is – “how does one do this”.  The answer is not as difficult as it at first appears.

Getting back to my assertion – methods based primarily on values and practices are risky, let's discuss practices a little. Practices are things you are to do.  These practices, of course, should be consistent with your values.  But practices only work in particular contexts.  Not in every context.  If they did, they would represent a silver bullet and we all know one does not exist. Scrum is a framework to make your challenges visible quickly.  That is, to surface impediments in a much faster time frame than you might find in a waterfall method. The problem is, once you see what your problem is, Scrum often doesn’t tell you how to solve it. 

If at this point it were OK to abandon the practices to see how best solve the impediments uncovered, we'd be fine.  But we are told that we must stick to the practices and change the organization or how we work to remove the impediments. There seems to be an underlying belief that if we have good values and practices that work in an ideal situation then all we have to do is do these practices to be in good shape to create that ideal situation.  There is some truth to this.  There is little question that if you have cross-functional, self-organizing teams across an organization that collaborate with trust and respect, you will accomplish great things.  But how does one get there if you don't already have this?  I don't question that Scrum will get you to effective development if you'd "just do it".  However, it may be like walking to Miami - not the most effective method of getting there.

The problem is (no pun intended) is that sometimes the solution to your problems is to not follow Scrum’s practices.  But you are now in a catch 22 situation.  Impediments show up as problems.  I would suggest that some of your problems need to be solved using Scrum's practices and some of your problems can be more readily solved with other practices - e.g., using explicit policies, managing work in progress, following principles of flow.Thus, sometimes we have to follow Scrum's practices and sometimes we shouldn't. But Scrum doesn’t give you any indication of how to tell which type of impediment you have!  It mandates following certain practices all of the time (e.g., time-boxed sprints, cross-functional teams). This is what can get you into trouble.

Many using Scrum have found that adopting principles from Lean helps to some extent.  A few of these are::

• Manage your work in progress
• Attend to flow for the entire value stream, not just the team
• Expand where explicit policies are used (e.g., define acceptance criteria before starting a sprint, define what done means)

This is a good first step.  Moving from practices to principles increases the scope of where things may work.  But principles (guidelines actually) are still limited in where they apply.  It is important is to understand the laws of software development on which these guidelines were based. Some of these include:

• Task switching lowers one’s productivity
• Working on too many things literally creates extra work for you
• Making decisions before you need to creates extra work
• The longer it takes to detect an error, the more effort it will take to fix it
• Hand-offs cause waste
• Lowering cycle time will both improve quality and lower your overall cost as well as achieve a quicker time to market
• People doing the work have insights about the work that others do not know
• People tend to respond adversely to too much change

The bottom line is one can start with values (good) and even with some practices.  But if you are having troubles applying the practices, don’t assume it is because of something you are doing wrong.  You may find there is a better way to achieve what you need.  You will likely need an understanding of principles and the laws on which they are based to do so.  There is no such thing as a best practice everywhere.  So it shouldn’t be surprising that any method based on practices won’t be best everywhere. Including Lean principles within Scrum will help.  But at some point you may need to decide you want to focus on what works, not on a particular method.

Alan Shalloway, CEO, Net Objectives

BTW:

If you found this blog of interest, I am sure you will find our new webinar series: Lean-Agile at Scale and at the Team: The Value Stream Series of value.

Here are some pages you might find useful.

• The Scrum-Clinic.  In particular Principles and Practices all Agile Teams (Including Scrum) Should Know and Follow
• Scrum/Kanban Series: Where to Start (blog)
• Mindsets: Waterfall, 1st & 2nd Generation Agile (blog)
• The Lean-Kanban Manifesto (blog)
• The Real Differences between Kanban and Scrum (blog)
• It’s not just “Does it work?” Ask, “Is it right for me?” (blog)
• Where to Begin Your Transition to Lean-Agile (article)