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:
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:
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:
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::
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:
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.