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 (Romania) airport. He made me think about this problem.

The first thing to say is: Scrum is not a panacea.  It requires hard work.  Often people expect Scrum to magically make things better, by itself, with no effort.  Well, yes, it can have a huge impact.  But it requires 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.

Similarly, this advantage of Scrum is captured one of Ken Schwaber’s famous sympathetic quotes.  “You suck, and that makes me sad.”  That is, if you are in a bad situation, at least you can see that (if you are willing to look).  And hopefully fix it.

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

1. A good-enough Team.  A real Team that is stable, at least for the duration of the Release or the project.  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, or clearly needs improvement.  The person may have been great at his or her prior job, but is not yet a good 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 my opinion, that means 3 good days at a minimum.  It is true that a few really good ScrumMasters can explain Scrum to the Team, and the Team 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. But most people do, if the Team makes a reasonable accommodation to each 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. It might never happen. One version of this is that firms will not fix impediments fast enough (to enable project success in tough circumstances).
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.  Asking for a ‘reasonable business situation’ to include almost no change is not on.  Equally, expecting to succeed in a totally wild situation is probably 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 missing one key skill set, and that can lead to failure.  Note that (b) is similar to #1 above. Perhaps by now, you see it a different way.
6. Adding the needed things to Scrum.  Many people seem to think 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, as one example, not adding sufficient good engineering practices can be a problem. I 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, and 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.’

We must add: You can easily have the opposite of the 6 items above with waterfall (or another process or method).  So, even if you have problems, with Scrum you might still be better than you were before.  Except that you can now see how screwed up things are. Sometimes a painful feeling.

Hope these ideas 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.

 

« « Impediments – Charleston || Agile Contracts – Question 1 » »