November 29, 2015

10 common Scrum misconceptions (part 1 of 2)

Throughout my career, I’ve seen many teams struggle to apply Scrum or Agile practices and ultimately failing, and for the most part, these struggles come from common misconceptions about what the framework is, and how to apply it. In this article, I’d like to address the most important Scrum misconceptions I’ve met, and how to handle them. Please take your time. This is a long read.

I have seen more than one software project where the understanding about what Scrum is and how it works diverged considerably between the organization’s management, the project’s designated Scrum Master (in this situation, typically without Scrum certification), and the actual definition of Scrum. An example situation is illustrated by the graph at the right. In this case, typically a mixture of what management and the Scrum Master takes as “Scrum’s definition” is then applied (let’s call it the “violet belt”). The further apart from each other these circles lie, the worse the situation presents itself, typically resulting in an improper implementation of Scrum and its eventual failure. Why would this happen? Is Scrum such a complex framework?

Scrum is sometimes described as “easy to learn, but difficult to master”. Indeed, its concepts and its set of rules, as established in the Scrum Guide, are all simple and few in numbers – the Guide being only 16 pages long. In my experience, this has led to the false assumption that introducing the framework to a project is simple, following its rules is easy, requiring few adaptations of existing processes only. Unfortunately, this is very wrong!

Applying Scrum means introducing a whole new mindset, based on transparency and collaboration. This is a disruptive framework which aims to questioning existing structures and processes, thus clearing the way for ever-ongoing improvement and adaptation in how the team works together to accomplish its goals.

Scrum has been developed by some of the most experienced minds in software industry, and has proven highly advantageous by some of the most successful IT companies. Those, however, who are not ready to share, and to adapt, will fail to successfully apply this agile framework.

Over the years, some misconceptions about Scrum have been established, probably backed by failed Scrum experiences. These misconceptions, as I will address them presently, did however often arise from improper use of the framework or incomplete understanding of its underlying concepts.

In this article, I’d like to address some of the most wide-spread misconceptions; I hope it will help your project to keep its “Scrum circles” closely together:

Introducing Scrum solves any problems in your project / organization

Not at all. You will not solve any problems solely by introducing Scrum in your project or organization. Instead, due to its disruptive nature, Scrum will help you maximize transparency and thus identify potential problems on a methodological, organizational or communication level; it is then up to you, as the entire Scrum Team, to address these problems. Typical misuse of Scrum includes modifying the framework in a way which hinders it from exhibiting potential problems in the organization which, in this situation, stay hidden instead of being addressed transparently.

As Scrum does by intention not provide any means to solve problems in a project, it must not be blamed for not doing so.

Let’s take the example situation where a team is not able to deliver functionality in time. Scrum is being introduced in order to “solve” this problem. After introduction, the team’s progress throughout an iteration is transparently shown on a burndown chart. This information can be used by the team to e.g. identify potential bottlenecks. If however, the team fails to interpret this information, or even worse, the burndown chart is manipulated in a way to convince the customer, or management, that the project is doing better than it does, the project will head for failure regardless of its underlying methodology.

As a rule of thumb, if a Scrum project fails to reach an iteration’s goal, transparency should be further increased, not decreased, and team-wide communication should be improved, searching for actions towards improvement.

Scrum can or should be partially applied or tailored to your project's / organization's needs

No, this is wrong, and the Scrum Guide expresses this very clearly: “Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.” Through the experience of its creators, Scrum has been carefully designed to provide a robust framework for a highly productive process workflow. If you alter any of its rules, you risk to lesser its effectiveness, or even introduce a counter-productive effect.

As mentioned earlier, achieving mastery in Scrum is hard, and it is so because although it consists of rather simple rules and elements, those play together in a complex manner, and only as a whole, they are effective. Choosing to omit any part is like trying out a new recipe, but leaving out a crucial part just because you feel it doesn’t fit in.

Unless you are a software development process expert, you should not change what you don’t know, not even a small thing. Scrum is a well-established industry standard, and if you really think you could improve its design, you should probably write an article about it, because process engineers all over the world would be interested in it. Please leave a link in the comments section below.

In that same category falls the infamous notion of the “ScrumBut” as in “We use Scrum, but...” There’s even a section about that practice on the website, so does that make it… legitimate? Not actually, as above citation from the Scrum Guide inhibits to call any incomplete implementation of that framework “Scrum”. But does that matter? Can’t you create a good process model, not based on Scrum, but on a “ScrumBut”? Well, you can try, but still everything mentioned in this section applies: Unless you have an experienced Scrum expert in your team, you just cannot be sure not to leave out any vital part when limiting yourself to a “ScrumBut” approach instead of applying full Scrum. In my personal experience, whenever a “ScrumBut” practice has been introduced, it aimed to hide away some circumstances impeding proper application of agile practices. In this situation, however, it would be better to identify why Scrum cannot be fully implemented in your organization and either address this problem, or resort to any applicable alternate process framework. Please refer to the next section as well for more details.

Finally, some people will claim that Scrum itself suggests to adapt the framework in line with the Scrum Team’s increased experience, as Scrum promotes “adaptation” as one of the framework’s key elements to a team’s success. They typically recommend the Scrum Retrospective meeting as a chance for doing so. However, the Scrum Guide forbids this very practice when explaining the Scrum Retrospective: “The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint.” As you can see, the Scrum framework is taken as immutable, for the very reasons I explained in this section. However, adaptation can and should be applied to any aspect of the development process itself.

Scrum is right for every project and every situation

This is certainly not true, and Scrum never claims to fulfill this vision.

I can shorten this paragraph considerably by simply citing what Michael James wrote on DZone’s excellent Scrum refcard about Scrum’s applicability: “Scrum is intended for the kinds of work defined processes have often failed to manage: uncertain requirements combined with unpredictable technology implementation risks. These conditions usually exist during new product development.”

As a rule of thumb, you might say that Scrum, just as other agile approaches, holds good for projects associated with a significant amount of unpredictability. This situation is also called the “unknown unknowns”. Because of the lack of specific experience, no “best practices” exist. This is where Scrum and other agile methodologies, being empirical, iterative approaches, shine. This typically applies to any new custom software development process.

If however you are in a situation which is highly predictable, and you have a well-known and broadly established knowledge base of all the components involved, a well-defined, Tayloristic approach will suffice. This situation is also called the “known knowns” or the “known unknowns”. In software development, this may apply to a “bug fixing” project where you know exactly and in advance which components of the system are erroneous and what exactly you have to do in order to fix the system.

Note that actually, unpredictability is the sole (main) prerequisite in Scrum’s applicability. All to often I’ve seen other “excuses” applied (e.g. by management) to not introduce Scrum in a project. One of those is having a customer which does not whish to collaborate closely with the Development Team, as discussed below in more details. However, in this situation, due to the customer’s behavior, unpredictability actually increases, thus making Scrum even more applicable. Here, Scrum would help your team identify the customer’s behavior as a critical impediment to the development process, and help your team find strategies to overcome this constraint. Applying any methodology which simply ignores the disadvantages this situation brings will not solve underlying problems such as difficult communication between team and customer and potential misunderstandings.

Scrum forces the customer to become a central part of the development process

This is actually true; however, it is wrong to blame Scrum as such to impose this as an additional restriction to the framework. As mentioned earlier, this is sometimes even used as an “excuse” to not introduce Scrum, because let’s face it, it’s always easy to blame the customer!

As discussed previously, Scrum is based entirely on proven best practices; if you omit any of Scrum’s ingredients, your are most likely to render it less effective or even harmful. The very same is true for the customer’s role within the development process. If you think about it: would you really trust any methodology which does not acknowledge a central place to the customer in the development process and stress the importance of common requirements understanding? This is especially true for custom software development – the “customer” is even referred to in the name of the thing!

Remember that Scrum aims to maximize transparency. Of course, transparent communication between the Development Team and the customer (the Product Owner) is most critical to the project’s success. Other methodologies which do not acknowledge this fact are simply hiding their inability to build up transparent communication with the customer and to adapt to his needs. But their ignorance will not shield you from negative consequences of this critical omission. Sooner or later, you will have to unveil everything you did to the customer; a situation in which you want to keep any chance to still react if you did not yet satisfy his requirements.

How to deal with customers who are not ready for transparent communication, close collaboration and shared effort? From the Scrum and Agile perspective, the answer is clear: you do not want to start any business relation with this type of customer as it is scheduled to fail. Unfortunately, this understanding is still not thoroughly present in all executive management positions. It’s the salesman’s job to foster the customer’s understanding of the advantages which come with agile methodologies and his close involvement in the software development process.

Scrum Master is a management position

This is very wrong, and in my experience it’s a very common misunderstanding. In the Scrum Guide, the Scrum Master’s tasks are explicitly outlined, and none of them requires, or implies, a management position. The Dzone refcard even clearly adds to the Scrum Master’s job description that “The ScrumMaster does these things (and more) without any authority on the Team. The ScrumMaster does not make business decisions or technical decisions, does not commit to work on behalf of the Team, etc.”

Violating this rule considerably harms two of Scrum’s main ingredients: That the Scrum Team is self-organizing, and that it understands its common responsibility of the project outcome (in other agile software development methodologies, these practices are referred to as “common (code) ownership”). If there was any distinguished individual (whether you call it the “Scrum Master” or a “Project leader” or a “Lead developer” or whatever) who makes decisions and thus takes sole responsibility for parts of the project, those essential ideas are lost, thus weakening the Team’s collaboration and individual motivation: Why should I care if I have no responsibility nor authority?

This is a concept especially hard to grasp for classically structured, highly hierarchical organizations. But there has to be someone in charge!, they say. Indeed, there is. It’s the Team in its entirety who is in charge and takes common, shared responsibility for the work of each individual Team member. And this makes actually perfectly sense. Software development is not warfare (usually). In military, the commander with most strategic experience becomes the one leading General. But in software development, there are far too many technologies, layers and stakeholders involved for a single individual to know the best strategy for everything. Scrum acknowledges this fact and thus gives responsibility to the Team as a whole which will organically yield its leading minds through its self-organizing behavior.

The Scrum Master, to round off this section, will actually help the Team by facilitating Scrum events and shielding it from any impediments.

Nevertheless, there is absolutely space for a “management” position in an organization whose development departments act as Scrum Teams, but management will not be part of the Scrum Team. Most certainly, management does not take the role of the Scrum Master as this would result in a conflict of interest. Not under any circumstances will line management take the role of the Scrum Master. In real world projects, management will either act as a proxy for the customer, thus taking the role and responsibility of the Product Owner, or, preferentially, it will manage the team’s surrounding with the actual Scrum Master as the main communicator between management and the Scrum Team.

Pages: 1 2