In an earlier blog (The 5-whys of Lean as an Answer to the But of Scrum ) someone suggested I was implying that we and our clients are infallible.  Unfortunately, that's not true. Not all of our clients' efforts succeed.  But when they don't we can usually pin-point why, and that's half the battle.  That was actually my point with my earlier blog.  When we refer to failed Scrum endeavors as "Scrum but" and stop looking into what is happening we are really saying - this is a failed process the team is following but we're not really sure why. 

It's kind of like instinct. Ever ask someone why birds fly south for the winter?  They say "instinct."  Does that really tell you anything?  I heard someone define instinct as "scientists way of explaining something where it sounded like they knew what they were saying but didn't really explain anything." Ever ask someone "how do you know to do that?" and get "experience" back as an answer?  Did that really tell you anything?  "Why did that project fail?"  "They used Scrum-but."  My point of the other blog is that we need to explore why we get failures and go deeper than the easy answer of blaming someone or the entire team.  In other words, when impediments don't get removed we shouldn't just say "management isn't involved properly" or "the team is following Scrum-but."  We need to dig deeper.

Let me give an example of one of our own failures (yes we do have them).  One of our consultants went into a large organization and kicked off several teams a little over a year ago.  They were pretty excited with what we showed them and the results of some teams were extraordinary.  A few months ago they asked us to come back and do an assessment of the teams.  Our consultant found that some had continued doing well and some were basically where they were a year before. Looking for the reason why wasn' t that hard.  The question is - "what was the unsuccessful team doing or not doing differently from the others?" (and why did this matter?).

Bottom line, the issue was one of visibility.  The team that had not achieved success never really got into a full incremental delivery model.  They wanted to build things only once they were completely told what was needed.  The management of the team didn't want to have to bother with breaking things down.  They said "why do all this extra work?  We want all of it anyway."  So there was a destructive reinforcing cycle of the team wanting it all and product management wanting to give it all - so things got specified in big batches and feedback of what was happening was very limited. 

What happened? Late in the project things were discovered to be off-track but it was too late to correct. What was the root cause of the failure? No appreciation that the lack of visibility was a high risk situation.  Now we've learned something that we can use to help the teams.  Giving them this knowledge can change behavior.  Saying they weren't motivated enough or disciplined enough doesn't do anything for them or the organization.  Behavior changes when people have better ways to manage themselves.  To me, this is real respect for people - give them what they need to do their job.  Don't assume because they aren't they don't care.

Now, the reality is, not everybody does care.  Sometimes a particular person is an impediment and that can lead to tough decisions.  But I can guarantee you that if you start out the attitude that a person is an impediment you are virtually guaranteeing that they will remain one.  Better to assume the best - and you'll often find the best. BTW: If you want to learn a little bit more about how to do this, look at our Coaching resources section. In particular look at What To Say When Someone Just Doesn't Get it . 

Technorati Tags: Lean Managing Lean-Agile

tag with del.icio.us