The Risk of Mostly Value and Practice Based Methods

June 4, 2012 — Posted by Al Shalloway

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


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.



Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban