November 29, 2015

10 common Scrum misconceptions (part 2 of 2)

Pages: 1 2

Scrum provides clear guidance to organize work and manage the project or the development process

This is another very common misconception which hits many newly-established Scrum Teams in an organization with no former Scrum experience. Just as I wrote at the beginning of this article, Scrum’s apparent simplicity and its small set of rules may lead to the wrong assumption that the framework is easily established and that it’s hard to go wrong if you follow some simple rules.

However, Scrum is not a software development methodology, but a framework. The difference is, that Scrum does not provide specific software development-related processes or practices. This is advantageous in that it is flexible enough to be used for many purposes, and you are free to include any accompanying practice of your choice in the framework; a common example being the Extreme Programming methodology (XP). The bad thing is that Scrum does not intend to help you with everyday software development and process management tasks. Thus, even if you apply every single one of Scrum’s rules perfectly, your development process can still go terribly wrong.

Over the years, many useful techniques have been established to facilitate Scrum’s central processes, such as the famous “Planning Poker” for workload estimates, and the “Burndown Chart” for Sprint forecasts. (Yes, not even Burndown Charts are officially part of the definition of Scrum!)

Thus, one common error for Scrum-“rookies” is to kickstart full-blown Scrum on Day X, hoping to get productive right away. Typically, near the end of Sprint 1, they will start panicking as they realize they have essentially no idea how to run their Scrum processes and events and that they are left in utter vacuum. Of course, one might say that that’s actually the Scrum way: They will learn from their former mistakes, they will establish their own rules, and eventually get better, Sprint by Sprint. While this is theoretically right, this is not a very economic solution.

Personally, I would suggest two main measures to aspiring Scrum Teams: The first one is to employ an experienced Scrum expert’s coaching services throughout the first few Sprints. This is a person which is at least Scrum-certified and ideally has been former Scrum Master of multiple Scrum projects. He will not take the role of the Scrum Master. Instead, he will stay at the Scrum Team’s service as an external consultant, and he will especially teach the Scrum Master how to fulfill his role. He will accompany the Team through its first Scrum events, give tips and show potential problems. After the Team and the Scrum Master gained enough confidence, the coach leaves the Team.

My second suggestion is starting off the project with a “Sprint 0”. In this initial Sprint, the Team will behave as if the project has fully started, but they will primarily use their time to establish their processes and try out Scrum practices. Note that this time is not wasted! There are typically many things which can be done weeks before a project actually starts: development tools need to be set up, document templates need to be prepared; maybe you can work on some technical proof-of-concept-tryouts, or there’s even some requirements engineering which has already started. You can take these activities and turn them into an actual Sprint, with the desired outcome (e.g. IDE set up, initial requirements gathered) filling the Sprint Backlog. This is an excellent, however somewhat relaxed, way to start a Scrum project and try all those new Scrum processes and practices!

Scrum is not applicable for fixed price projects

This topic has been discussed lengthy in many articles. This post on the website suggests that it’s important to distinguish between what actually are the “fixed” parts of a project in order to assess Scrum’s applicability. For typical “fixed price” projects, it’s indeed implied that not only the price (cost, resources), but also the time to finish as well as the scope (quantity of functionality) is “fixed”, speaking in classical project management terms. But other project configurations are possible as well, so let’s take a closer look at these possibilities.

Scrum “by default” works with fixed time (based on a Sprint as a time-box, and with a pre-negotiated total number of Sprints), fixed costs, and fixed quality (the Definition of Done for each tasks strictly defines the quality). This does indeed work very well because for the customer, the three critical factors time, price, and quality are fixed. The only moving part is thus the scope, as defined by the Product Backlog. It is therefore of utmost importance for the customer to sort the Product Backlog by priority such that high-priority items get “done” first, before “time” or “costs” are consumed by the fixed “quality”. This is a legitimate contract model for agile projects (with the option to extend project runtime later to build in more scope).

Fixing everything but the time (the number of Sprints) is possible as well. In this model, essentially, the project team works, Sprint by Sprint, until the customer says “Stop”. In practice, there is the well-known variant known as “money for nothing / changes for free” which especially takes into account the desire to lock down costs as well. This model is guided by three simple rules:
  • Before project start, a total cost estimate is made and these costs are accepted by both parties as fixed.
  • During the project, the customer (Product Owner) is free to make changes (not additions!) to the scope at will (within the Scrum process), thus allowing him to react on new developments and lessons learnt from earlier Sprints. This is the “changes for free” part.
  • If the Development Team happens to satisfy the Product Owner’s expectation earlier than the negotiated total runtime of the project, the Product Owner may choose to halt development at that point and is usually charged a fee according to the remaining estimated runtime. This allows the customer to apply a 80/20 rule for cost efficiency. This is the “money for nothing” part.
This is truly an ingenious way to build a software development contract which satisfies both customer and developer, and gives them maximum flexibility. It has been established by Scrum co-founder Jeff Sutherland. This is thus another legitimate contract model for agile projects.

Now, let’s take a look at the incipiently discussed case where costs, time, and scope are fixed. This is indeed an unfortunate situation as we can clearly see that the only movable part here is software quality. From a Scrum perspective, this means that there are no fixed “Definitions of Done” as  the Development Team can decide to ignore them in order to save costs, time, or scope. This of course is ridiculous and the only expected outcome is that both the customer as well as the developers will end up frustrated (given that developers wish to build high quality products).

Unfortunately, throughout my career, I’ve seen quite a view projects starting out of this latter configuration, or even worse, with a management which actually expects that they can fix costs, time, scope, and quality at the same time. Of course, basic project management knowledge teaches us that this is utopistic thinking. Actually, this wouldn’t work regardless of the project management framework applied. As the article previously referred to states: this is “a recipe for a death-march project”.

Of course, this realization has to come well before project start, at the contract negotiation level. Otherwise, development teams get stuck with a project which is mathematically impossible to succeed, leaving developers and customers dissatisfied. There are indeed great contract models for agile projects, especially for fixed price projects, so please don’t choose once which is impossible to succeed.

Scrum is not applicable for big projects

This is yet another highly disputed topic: Does Scrum scale for bigger projects? Short answer: it does.

The Scrum Guide recommends Development Team sizes between three and nine members. Reasons for this best practice is also provided (and nicely illustrated) by the Scrum Dzone refcard (“Scaling” section): “Communication pathways increase geometrically with team size”. This refcard also explains the most common strategy for dealing with big-sized Scrum Teams: The famous “Scrum of Scrums” – where the team is divided into sub-teams which work according to Scrum’s rules and synchronize with each other via a delegate sent to the daily “Scrum of Scrums”. For a more complete adaptation of these principles, you may also want to take a look at the Nexus framework, or the Less framework, ready-to-use implementations of business-proven large-scale Scrum applications.

The important thing is that you realize that you are in fact obliged to apply an appropriate strategy if you want to run Scrum on Development Team sizes outside the range recommended by the Scrum Guide. Otherwise, in fact, the execution of Scrum may be severely impeded or eventually fail.

Scrum really builds on the effectiveness of one-to-one-communication, and this just doesn’t work with a dozen of people or more. This is most prominently shown in the conduction of the Daily Scrum where time is wasted because people are forced to discuss topics which don’t concern their daily work.

Scrum experts will clearly advise that when dividing a big team into sub-teams, you should keep these sub-teams cross-functional, thus forming so-called “feature teams”. However, I have observed in practice that this is especially challenging for organizations which newly introduce Scrum as they typically consist of individual departments, split technically (e.g. a requirements engineering team, a Java team, a database team), and breaking and redistributing these well-oiled teams is a difficult step. In this situation, I would really recommend to start off with these technical teams as sub-teams given that their interfaces are clearly defined through solid project-wide Definitions of Done, and that information is shared freely between the teams using a “Scrum of Scrums” approach.

This still is much better than just trying to squeeze in a clearly oversized development team into a “Scrum container”, sacrificing the framework’s efficiency and flexibility. Over time, communication flow will naturally show opportunities to come to a more feature-centric, interdisciplinary sub-team organization.

One important limitation to this approach, as I would recommend it, is to not isolate a requirements engineering team, as this would not be a technical, but a functional division, and you risk your “requirements engineering team” becoming the pseudo-Product Owner for the other sub-teams, building a classical “ivory tower” architecture. Instead, it’s important that requirements engineers and software developers work closely together to build solutions. Maybe your requirements engineers could even specialize themselves for working with a UI, a service interface, or a backend team.

A Scrum project does not need, or does not allow (broad) documentation

This seems to be a common misconception about Agile in general, and it is derived from a misunderstanding of the Agile Manifesto promoting “working software over comprehensive documentation”, but disregarding the important statement that “while there is value in the items on the right, we value the items on the left more.” Also, it may seem that when compared with heavy-weight process models such as RUP, Scrum in particular imposes only a few written artifacts.

Hence, introducing Agile or Scrum has been taken as a convenient excuse to lessen documentation effort, especially in the matter of requirements, decision making, and source code documentation.

And this is of course very wrong. Scrum isn’t a magical tool providing full efficiency with only half the effort. As described earlier, it’s not actually a tool at all: It’s a framework, and you can and must run your tools and processes within it in order to render it effective.

As documentation is a vital part of software development, it’s only logical and good engineering practice to stick to it where sensible, regardless of the process management framework applied. That famous line from the Agile Manifesto really means, in short, to get rid of documentation tasks which do not add value to the end product.

Actually, as documenting is the only way to really fix an agreement, an idea, or an observation for future reference, it is really an important part of Scrum as well which is all about revisiting and reassessing former decisions, and in order to do that, they must be fixed bindingly. This especially applies to:
  • Whatever is part of the contract with the Product Owner
  • The Product Backlog / Sprint Backlog and the Definition of Done for every Product Backlog item
  • Decisions concerning processes and tools
  • Technical decisions
  • Sprint retrospective outcome
As for the individual Product Backlog items, it’s another common myth that agile processes imply replacing classic Use cases with User Stories to describe individual elements of a software system. Whilst it is true that agile methodologies led to wide-spread use of User stories as a tool for development planning, they aren’t designed to replace Use cases, and you are free to use whatever tool you feel most comfortable with when applying Scrum, as the Scrum Guide doesn’t mention either of them.

In fact, these tools have a different purpose: Whilst Use cases are a tool for modeling software functionality (business requirements perspective), User stories are designed to plan feature development (business value and technical perspective), as it is here explained in more details by Mike Cohn.

In a real world project, these tools can be efficiently used in conjunction:
  • Top-down: Define the use case and split it in different (e.g. technical) user stories
  • Bottom-up: Start with individual user stories as “slices” of an “epic” which as a whole describes a complete use case.
So if you feel comfortable with use cases, start off by defining them, and break them into Product Backlog items, which will essentially yield user story-like slices. However, because we value “working software over comprehensive documentation”, note that use case documentation should be as lightweight as possible, so get rid of diagrams and complicated sequence hierarchies unless they add value.

The Sprint Backlog can be modified freely throughout the Sprint

No, it cannot. The Scrum Guide does indeed allow the Sprint Backlog to be updated throughout the Sprint as more is learned, but with the important constraint that “only the Development Team can change its Sprint Backlog during a Sprint” whilst “scope may be clarified and re-negotiated between the Product Owner and Development Team”.

This means that whilst the Product Owner can give input to the current Sprint planning, it’s at the Development Team’s discretion to apply actual changes to the current Sprint Backlog.

Actually, this is an essential prerequisite for the Sprint to stay a time-boxed unit which in turn is vital to ensure traceability: if the planning was allowed to alter freely, initial planning and observed effort cannot be compared, which impedes the all-important empirical learning process.

This is typically violated in projects with a very unclear Product Owner role, e.g. if a “project manager” takes the role of the Product Owner by dictating his own development plans. He may then whish to apply “last minute changes” even during development in order to reinforce control over the development process. This clearly is by no means Agile nor Scrum.


If there’s one important advice I would give to aspiring Scrum users, it’s this: it’s the Scrum Guide which describes what Scrum is, and everything which is not described in the Scrum guide is not part of Scrum (although it can be helpful), and everything which contradicts the Scrum Guide impedes Scrum from working properly. Verifying Scrum compatibility is thus as easy as reading the 16-pages guide and comparing it with its application in the project in question. Both seminars and coaching may be useful, but first of all, your team has to agree on what Scrum is, and that is what the Scrum Guide provides.

Furthermore, in order for Scrum to succeed, it’s vital that every member of the Scrum Team acknowledges the value of its underlying mindset, namely shared effort, collaboration, transparency, and ever-ongoing (self-)improvement. If your team does not agree on these values, Scrum will not suit you.

Learning Scrum really is how learning about tools in general works: Study it, use it, and only if experience shows that the way you’re taught to use it doesn’t work in your situation, you may start thinking about changing it. And, as always, applying modifications make you lose its warranty.

I hope this article helped you learning more about how to apply Scrum in practice, and how to overcome issues which come from its improper application and common misconceptions.

Thank you for your interest in this article. Please feel free to share your thoughts and critics in the comments section below, or mention any other common Scrum misconception I may have missed.

Pages: 1 2

No comments:

Post a Comment