At Net Objectives we’ve trained tens of thousands in Scrum and Kanban.  We don’t really play sides in which method we use.  Our own experience is that hybrid methods are typically needed in large scale transitions – which is our specialty.  Regardless of which method our clients employ, we always suggest a system-thinking approach within the context of Lean-thinking.

Lean-thinking is actually a kind of systems thinking.  It suggests that most of the problems that are encountered are due to faults in the system.  That we should not blame people for errors, but rather look to see how the system they are in is working. 

A variant of this would be to look how a systems thinker would approach the problem of Scrum-but and Kanban-but. As an aside, I want to point out the Kanban community discourages the use of the term Kanban-but since it focuses on the people aspect of not doing Kanban. Systems thinkers would also  discourage the use of Scrum-but as a derogatory term for the people not doing Scrum properly.   He wouldn’t suggest that people are doing Scrum-but because they aren’t motivated enough, he would ask “why are they not doing Scrum properly?”  Is it they don’t understand the benefit of the Scrum practice they are not doing?  Is it that it would be too difficult to do it? What is it about Scrum itself that contributes to these challenges? 

By focusing on the system, we avoid putting the blame on the people.  Now it may be that the people aren’t motivated enough.  But as soon as you draw that conclusion, you have lost all power in helping them.  It is one reason the Fundamental Attribution Error is so deadly and being aware of it can be so powerful.  Regardless of whether the judgment is true, once it has been made there is little that can be done.

Instead of finding what is wrong with someone that is not doing what they are supposed to, systems thinkers look for what the people experiencing challenges are looking at (or not looking at) that has them make poor choices. We assume they are a good, intelligent, motivated person looking at the wrong things and therefore making bad decisions.  Not that there is something wrong in their character such as a lack of motivation or persistence or courage.

In software development, the “system” is often the workflow they find themselves in.  In other words, if we’re talking about a developer, when do they get the opportunity to talk to customers, to testers?  Do they get requirements and the validation for these requirements at the same time via Acceptance Test-Driven Development or not?  These are choices often outside of their control.

My suggestion is that if you are using a method that has a common set of challenges, that perhaps one should look at modifying the method to avoid the challenges instead of trying to motivate your people into putting more effort into overcoming them.  I’m not suggesting motivation isn’t important – it is. And sometimes working harder and having more courage is the only route to success available.  But my experience is that people in this field are very motivated.  The question is, how can we best take advantage of that motivation?