Any skill that is really useful in life takes time to master. Sometimes, when you are first learning, you can make great progress. The danger is thinking that your surface understanding is deeper than it is. Wise people will keep pressing in to learn and improve so that they can handle the inevitable challenges. You need to be prepared when the crisis comes - that's not the time to begin the preparations.
Scrum is a really useful approach. It seems simple and yet it, too, requires skill and determination. How many people have taken a two-day "Mastering Scrum" course and think they can go forth and do it... only to struggle and even fail? The superficial understanding they receive from many Scrum trainings under-prepares them. We know this, and yet there is still this belief in the Scrum community that a simple approach is sufficient. It is not. You have to keep learning. To be prepared, you do have to understand the principles and practices so that you can adapt and address the challenges you will face.
In this blog entry, I want to mention some misunderstandings I have seen many people in the industry have and how we, as practitioners, can get beyond them. I have also included a few things many Scrum trainers believe that I don't agree with.
Misunderstanding: You can do Scrum without doing automated acceptance testing or up-front unit testing. Well you can, but you'll soon be faced with degrading code that's hard to change and dangerous to change as well. For whatever reason, the Scrum community has neglected to focus on this as much as they (in my mind) should. Lean's principle of "build quality in" provides guidance here.
Scrum Belief That Isn't True: When deciding what to build, start with stories. Release planning is a process of selecting stories to include in your release. It's actually better to start with the big picture. In particular, a minimum marketable feature (MMF) as described in Software By Numbers (Denne, Cleland-Huang). If you find yourself losing the big picture while working on little pieces, this misunderstanding may be why. Lean's principle of "optimizing the whole" helps provide guidance here.
Misunderstanding: Teams need to be protected from management. I've never heard the creator of Scrum (Jeff Sutherland) say this, so this is a clear misunderstanding of the Scrum mandate to protect the team from interruptions. Perhaps there is an assumption that it is management that causes most of the interruptions and therefore it is management whom we must protect the team against. This exacerbates the us (developers) vs. them (management) conflict that causes so many problems in this industry. Lean's attitude of management supporting the team while the team creates their process provides guidance here.
Misunderstanding: Management should not prod teams for information if the teams decide they don't need to give it. This goes along with the fallacy that self-directed teams don't need management help. They do. In fact, purely self-directed teams have a history of not succeeding well. In any event, the visual controls used by most teams (including burn-up charts) should provide information to both the team and to management. Management has a right and need to understand what is happening in the team. This is a lot of the purpose of Scrum. If it is difficult for teams to show this, then there is something wrong in how they are tracking their work. Lean's use of visual controls provides guidance here.
Misunderstanding: Self-directed teams, alone, can improve their processes. This clearly relates to the prior misconceptions involving management. Continuous Process Improvement is a partnership between teams and management. In fact, the Lean Enterprise Institute, in a 2006 webinar, described the crucial role that middle management plays, asking intelligent questions and establishing an environment in which there is both leadership and collaboration, that there is a need to avoid both the autocrat and the hands-off manager. Lean's paradigm of management providing leadership to teams that continuously improve their process provides guidance here.
Scrum Belief That Isn't True: The product owner is the "one wringable neck" for what the product should be. Actually, no one's neck should be wringable. In any event, while the product owner is the keeper of priorities, it is the entire team that is responsible for building a quality product. Lean's Product Champion provides a superior view.
Misunderstanding: Every Sprint needs to deliver value to the customer. Until the software is released, there is no value delivered. While every Sprint should include something that is built, it is not necessarily true that the sprint is always for the customer's benefit. There are cases where one needs to learn something about the system. While these don't occur as often as some developers think, sometimes the biggest risk is not in building what the customer needs, but in not discovering something about the system. In these cases, building what will mitigate your risk the most may be more appropriate. Lean's principle of "optimizing the whole" provides guidance here.
Misunderstanding: Never plan beyond the current sprint. Oh, if this were truly possible! On small teams and small projects, it is. As you get larger, it gets more difficult. A sprint backlog (visual control) sophisticated enough to handle multi-sprint and multi-team stories can manage this and isn't really that complicated (ask us :) ). Lean's larger view helps here.
Scrum Belief That Isn't True: You can use Scrum-of-Scrums to coordinate teams. In many situations, "Scrum of Scrums" simply doesn't work well when the pressure is on and when teams have different motivations. We know of the problems of creating teams from individuals. Creating an organization from individual teams has the same problem. Having a product integration team that looks across teams can solve this. Lean's principle of "optimize the whole" can provide guidance.
OK, if you can relate to the above, where can you go?
A lot of good information can be found in our upcoming book - Lean Software Development: Scaling Agile to the Enterprise. In particular, read the chapters An Agile Developer's Guide to Lean Software Development and An Overview of Scrum# (our version of Scrum guided by Lean principles).
If you would like a more interactive approach, check out our free, on-line Lean Software Development training.
Scrum, when done properly, is wonderful. It creates a way to learn and move forward. When it is thought to be an answer beyond the agile project management method that it is, it can be counter-productive. Scrum should be used appropriately and by people who understand why it works. Unfortunately, a 2-day Scrum Master training does little to provide this understanding, but is more likely to get one to think that to get Scrum to work for your team you merely need to follow a certain set of practices. Yes, I know that any Scrum Master Trainer certified by the Scrum Alliance will tell you that Scrum is merely a start and the Certification part as well as the Mastery part are merely a beginning and not a qualification. But the reality is that there are many teams who try to use Scrum without understanding all that is required. We in the Scrum community do them a disservice when we leave them to these misunderstandings.
Let me know what you think. Comments on our Lean-Agile-Scrum Yahoo group is a great place to comment.
CEO, Net Objectives
Achieving Enterprise and Team Agility