What if Scrum is not working for you?

I was speaking to a smart guy who had taken (some while ago) my CSM course.  We were both waiting at the Cluj airport. He made me think about this problem.

The first thing to say is that Scrum is not a panacea.  It requires hard work. Often people expect Scrum to magically make things better.  And it can have a huge impact.  But it requires a lot of effort in several ways.

One advantage of Scrum is that a manager (and the Team itself) can quickly see if a Team is not doing well.  If they are willing to look and they know where and how to look.

Here are some of the things Scrum requires to be successful.

1. A good-enough Team.  A real Team that is stable, at least for the duration of the project or the Release.  And a Team that has the ability to get the job done.
   
2. A good-enough Product Owner.  Often the Product Owner is not good enough.  The person may have been great at his or her prior job, but is not suitable for Product Owner.  There can be many problems, such as insufficient time allocation to be Product Owner, or insufficient knowledge of the role, or insufficient knowledge of Scrum. Some POs are indecisive, and some just can not organize the User Stories (or PBIs) fast enough and well enough.
   
3. A Team that understands and wants to play Scrum.  Many Teams are never given good training on Scrum.  In our opinion, that means 3 good days at a minimum.  It is true that a few (very few) really good ScrumMasters can explain Scrum to the Team, and they can do it pretty well with that ‘start’.  But it is rare.  Usually the whole Team needs direct training. Often some Team members have heard about Scrum or even played ‘scrum-butt’, and have decided they do not like it.  (Indeed one can understand that certain personality types would not like real Scrum, although most people do, if the Team makes a reasonable accommodation to the personality type.)  If a Team has 2 people (or more) who do not want to do Scrum, they can make it fail.
   
4. A willingness to engage and to improve.  In general, Business and Technology must be willing to work together (collaborate).  In general, the people in the Team must be willing to engage with each other and for the project. Often the people come from a place of distrust that does not fostered engagement.  These experiences could have happened some years ago.  So while Scrum in many ways supports and encourages engagement, Scrum alone may not be able to overcome the forces of disengagement.   Also, some firms and some people do not have the spirit for continuous improvement.  If so, leaders can possibly encourage and develop it, but this can take time. And might never happen. One version of this is that firms will not fix impediments fast enough (to enable project success).
   
5. A reasonable business situation.  Two parts to this: (a) The eventual scope, date, budget and quality constraints – as they turn out to be – are suitable for success vis-a-vis the situation of the Team.   Knowledge work is a process of continuous learning. So, for example, we must expect the Product Backlog to evolve and emerge over time. We must all sorts of things to change.  So, asking for a ‘reasonable business situation’ to include almost no change is not on.  But equally, expecting to succeed in a totally wild situation is not possible.(b) The situation includes also the Team’s suitability to the work. You can have a Team that is great for one project, and not right for the new work. The Team can be just missing one key skill set, and that can lead to failure.  Note that (b) is similar to #1 above. But perhaps by now, you see it a different way.
   
6. Adding the needed things to Scrum.  Many people seem to think that Scrum by itself, if we think of Scrum simply as Process, that Scrum itself is enough. But any Team needs more than Scrum to be successful. Often people add things to Scrum, but without even noticing.  Sometimes this is enough. Others talk explicitly about adding XP and Lean and other practices. So, not adding sufficient good engineering practices can be a problem, for example. We recommend XP engineering practices, such as adding automated Functional Testing, A-TDD, and Continuous Integration.  These often can be key to real success, or to releasing much more value from Scrum.As another example, the Team must add a technique (or 5) for reaching decisions quickly, but still with usually correct decisions. Scrum assumes that these things come up and are dealt with as part of impediment removal, but not all Teams figure this out.

These are 6 key factors for success. Usually that is 5 more than I can deal with today.  If you can get one or more of these fixed, perhaps it will ‘work for you.’

Hope they help you or a friend. I am curious as to your first 5 or 6 guesses as to why others may feel ‘scrum is not working for me.’  Or more, what could they do about it?

Another way of looking at this issue is the Scrum-Butt Test. Which I have already written about extensively.

And hello to my friend and all my friends in Cluj.