During my time away from this website, I earned a Scrum-Master certification and participated in several Scrum projects. My experiences were usually poor, as the other team members and Scrum Masters often did not seem to understand Scrum, were too set on going by the letter instead of the spirit, failed to reflect on what purpose a particular Scrum activity/role/whatnot had (with the consequence that this purpose was not fulfilled), had little true interest in “inspect and adapt” (which I view as the core of Scrum), etc.
I set about writing down some of my experiences and thoughts around Scrum, but never completed these writings. (In part, because I had little time available and little opportunity to actually publish; in part, because later projects were largely Scrum-less.) The following page is (at least, for the time being) based on the first and largest of these writings. Clean-up and improvements have not been extensive, so take it for what it is worth.
After the early portions, I found more keywords than text. I have attempted to expand these keywords (based on context and vague memories); however, the contents are thinner that if I had written the text to end in 2013, and I make reservations for memory errors. Some keywords were outright omitted, because they were too vague for me to write anything sensible without resorting to wild guessing.
I capitalize certain terms with a standard meaning in Scrum, in order to better differentiate them from terms from outside Scrum. (If in doubt, to make it easier for the outsider to know what terms to look up.)
I use three abbreviations, “SM” for “Scrum Master”, “PO” for “Product Owner” and “Team” for “Development Team” (as opposed to “Scrum Team”).
I use “task” a little sloppily (and without capitalisation). Depending on context it can imply a unit of work in a Sprint (the stricter meaning), an entry in the Product Backlog, something intermediate, or something matching the everyday meaning of the word. This in part to not over-complicate the text for those new to Scrum; in part, because some claims can apply to more than one meaning; in part, frankly, because the original draft was sloppy in this regard.
The tense used might be inconsistent, depending on when what sentence was written or modified.
A particularly poor Scrum experience (from another project) is featured in a separate discussion of the (alleged) wisdom of crowds. Several old Wordpress texts also have some Scrum-related contents (TODO import and link).
After having earned my SM certification, I was keen on starting my new project—the first in which Scrum was actually used: Theory and practical experience are both necessary for true mastery.
I was set to start specifically on 2013-03-05 (a Tuesday and the third working day of the month), rather than on the first working day of the month or week for one single reason: This was the first day of the next two-week Sprint.
In the context of Scrum, this is not necessarily a bad idea, even if I might have favored the Monday to, by implication, catch the end of the previous Sprint.
However, this idea was entirely invalidated by the extension of that previous Sprint (cf. below). I made no note of when the Sprint eventually ended, but, going by the below, it would have been approximately one month after I entered the project—as opposed to the “one day before” that the plan dictated.
During this first day, I experienced a > 30 minutes “daily Scrum” (by the book there is a 15 minute upper limit), learned that the development team was now at 10 persons (max of 9 by the book), and that the sprint had been extended by one week (an absolute no-no).
At the time of writing, 2013-03-31, this sprint is not yet concluded (although it likely will be in the next few days), being tripled in length and exceeding the maximum allowable length (four weeks) by 50 percent...
As was to be expected, these problems were symptomatic for other Scrum roles/artifacts/meetings/whatnot. Below I give some detail.
I assume that the reader has at least some familiarity with Scrum. For those who do not, a quick Internet search for “Scrum” should give good-but-brief pointers, including regarding terminology. The official “Scrum Guide” is a particularly good entry point, but a little lengthier.
Not doing Scrum by the book is not necessarily and automatically wrong: What works in theory is often unpractical or needs to be modified due to local or individual circumstances.
However, rules should only be broken when understood and events have made manifestly clear that the project leader (a role it self not compatible with Scrum; also see below) does not understand the rules of Scrum, what purpose they serve, and what the consequences of breaking them can (and are likely to) be. The same appears to apply to the alleged SM (note that my own role in this project is that of a regular team member, not SM). Here, we have a situation where a label of “Scrum” is slapped on the process without truly doing Scrum, and, more generally, labels of this-and-that are slapped on various other things, which only rarely truly are what they are labelled as, often are so only to a very rough approximation, and sometimes miss the mark entirely.
In my original draft, the last sentence read:
All in all, Scrum is approached in a “cargo cult” manner, where the form is imitated—but the actual content has been left out.
This “cargo cult” aspect has, in my personal experiences, been the norm and not the exception in other Scrum projects, it remains worthy of mention, and I have, indeed, often used the term “cargo cult” in conjuncture with Scrum.
With this first project, however, it is too weak a term and the new formulation with labels comes closer to the mark. Looking back, but with great reservations for memory, I cannot suppress the suspicion that a dictate of “Thou shalt do Scrum!” came from above and that the project leader set about circumventing this dictate by trying to keep everything as close to his old approaches as he could without being in obvious violation of the dictate in the eyes of the issuer.
Scrum has a “division of power” slightly similar to that of the U.S. constitution: The PO decides what features should be added to the product in what order; however, he is very explicitly not allowed to tell the development team how to do this; further, he is not allowed to make changes to the requirements of the on-going sprint.
While Scrum does not support the role of project leader (at least not in the conventional sense), there are settings where having one does not undermine the framework entirely. Unfortunately, the role of PO is the very, very worst to combine with that of such a project leader: This removes the division of power in a catastrophic manner and makes Scrum near unworkable. (Consider aspects like stability of requirements during a sprint, the team’s commitment to and responsibility for a sprint goal, and team empowerment. Generally, the strived for “self-organization” of the team is immediately nullified. A particular danger is that even a well-meaning PO would lose the ability to deny “urgent” requests from outsiders and higher-ups, thereby also weakening his own ability to fulfill the role of PO.)
As stated above, this project does have an identity PO / project leader—and the person filling these dual roles is particularly unsuitable through a poor understanding of Scrum, a too authoritative management style, and, in my impression to date, a major overestimation of his own abilities, understanding, and suitability.
Moreover, the project leader saw himself as a Scrum arbiter, which further intruded on the role of the SM.
The SM was both incompetent and lacking in spine. He failed to be a counterweight to the PO, failed to enforce Scrum principles, and failed to serve as a shield for the rest of the developers. (The role of shield might normally be more closely associated with the PO role, but with the current PO the PO was the source of problems from which we needed a shield.)
He, too, failed in being too authoritative (relative the developers).
Scrum done right is based on arguments and reason—not “Because I said so!”. In particular, both PO and SM are roles of a functional nature, neither of which makes for a “boss”. The SM, in particular, should ideally influence through arguments and previously earned respect as someone competent and insightful. (Neither of PO and SM were actually competent and insightful.)
At least the PO can make many decisions (notably, what is added to the Product Backlog with what priority) on his own and/or as gateway to various stakeholders from outside the Team. However, (a) even here, he would be a fool to ignore the advice of the Team, (b) these decisions are limited to his own “sphere”. For instance, the Team might choose not to include a high-priority Backlog entry in the next Sprint, even should the PO see the inclusion as vital. (But, vice versa, the Team should have good actual reasons for such a decision—not just a fool’s insistence on ignoring the advice of the PO with a “Because we said so!”. Consider a situation where lack of vital information prevents a reasonable implementation.)
Time boxing, including for the length of a Sprint is important in Scrum, for reasons that include easier planning and less waste of time. For instance, imagine that a deadline looms, that you are in a meeting, and you do not know when the meeting (at the latest) will end. Time boxing gives an upper limit. Likewise, in a meeting, different participants can have different ideas and different levels of urgency to end the meeting. A time box ensures that everyone (who follows Scrum) strives to end the meeting by a certain point, even when they might have more to say. (Generally, meetings without deadlines tend to result in waste of time.)
Time boxing, however, was not taken seriously in this project. The aforementioned Sprint extensions were the most horrifying example that I have ever encountered in Scrum—and worse than almost everything that I have encountered outside of Scrum. Scrum has a clear cycle of short sprints, each guaranteed to deliver a certain promised value at a certain time. When the guarantee is at risk of failing, the prescribed procedure is to negotiate a reduction of scope, and to follow it with analysis of what went wrong, what to do better, etc. At worst, in an extreme situation like here, the Sprint should have been outright interrupted, and a new Sprint begun with a smaller set of tasks (and, of course, an even deeper analysis).
It might seem that going from 9 to 10 is a trivial violation—and I would certainly view it as far lesser than the immense sprint extension. However, 9 was already an upper end of an interval. If 9 had been the ideal size, going to 10 would have been a trifle, just as going away slightly from any ideal, but this was not the case. By analogy, chances are that a kid an inch shy of “must be this tall to ride” a certain ride would still be fine, but the limit is not there to, e.g., “be mean to short kids”—it is there because an actual risk is present below a certain height.
Looking back at my own experiences, in- and outside Scrum, I might view even 9 as problematic for a closely cooperating team, and would prefer teams to be as small as possible with an eye at the work that must be done in a certain time frame.
Larger teams, in particular, create coordination problems, be it in terms of the left hand (not) knowing what the right hand does, meetings that last longer (time boxing!), consensus that is harder to reach (with an increased risk of “majority decides”), greater difficulties with keeping the team members physically close to each other (and without resorting to developer-hostile “open plan” solutions), whatnot. Large teams can also be a sign that the project at hand is simply too large and would benefit from division into smaller pieces. (One of the advantages of Scrum is, indeed, that it is more likely that too large projects, too large tasks, whatnot, are divided into more manageable pieces.)
Here, the team should have been split into two teams, each of a “legal” size.
A secondary concern is that when a limit is weakened, further weakening often follows. If 10 were OK, 11 might not be, 12 even less so, etc. Or, to return to, the kids: What if one kid, half-an-inch too short, is let through, and the mother of the kid behind him throws a fit when her kid, another half-an-inch shorter is not accepted? When and where do we draw the line, once we begin to fiddle?
This the more so, as the problems involved can be gradual. Going from 9 to 10, e.g., will not lead to the end of the world, but it can still lead to worse outcomes. What now, if someone reasons that “going from 9 to 10 did not end the world; ergo, going from 10 to 11 will not do so either”? (Etc.) For each increment, the outcomes worsen again. The kid half-an-inch too short will not face certain death, but he will be at greater risk, and by allowing shorter and shorter kids, problems will follow, be it because a safety margin is eventually used up or because the likelihood of an accident increases with every decrease in height.
One of the core ideas of Scrum is to be transparent so that we can inspect and to inspect so that we can adapt. Failure at one or more of these items were a recurring theme.
My original draft used the German “Ist” and “Soll”, which are standard German idioms for “what is” and “what should be”. I have yet to find good English replacements. Below, “Is” and “Should” are used as improvised translations, together with some re-formulation to fit English better.
A particular issue was a failure to keep track of and to separate “Is” and “Should”: Good procedures, be it in- or outside Scrum, in development or project management, whatnot, benefit from understanding and tracking the difference between “Is” and “Should”. In Scrum, for instance, we can make a plan that we “Should” accomplish this-and-that by the end of the sprint; in order to reach that goal, we “Should” reach certain sub-goals by certain earlier times; etc. If we now look at the “Is”, we might find that what “Should” be after the first week is, in fact, not. Good news: Because we looked, we know that something did not go as planned and that further measures might be needed to get us back on track—we can now think of and implement such measures. In this project, the “Shoulds” were wishy-washy, too little looking took place, conclusions were not drawn when an “Is” and a “Should” deviated, etc.
Three keywords/-phrases “empty product backlog”, “no estimates”, “new tasks/bugs/etc.”, point to issues with and around the Product Backlog. Unfortunately, the lack of detail and my vagueness of memory prevent a deeper discussion than “this was yet another area with problems in the project at hand”.
Speaking more generally, however, I note that an empty product backlog would prevent sensible planning, while a lack of estimates can be devastating, e.g., through making it hard to say when the Sprint schedule is full and no further tasks must be added. Another complication is that, without estimates, some tasks might be too big and in need of sub-division. Yet another, that a lack of estimates is likely to lead to exactly the type of “Is” vs. “Should” problems discussed above.
Failing at either is amateur hour—must not happen.
This with two reservations:
Firstly, that a Product Backlog may be empty at the very beginning of a project, before the first Sprint is planned, and at the very end of the project, when no further Sprints will follow. Neither applied here.
Secondly, that estimates need only be present, at any given time, for those (Product Backlog) tasks that have sufficient priority/urgency and for sufficiently many tasks to ensure that a Sprint can be filled up with value-bringing tasks. As new tasks are usually continually added, as tasks differ in both priority and urgency, as making estimates takes time, as some estimates might be easier in light of experiences not yet made, etc., it is not realistic to demand that all tasks have estimates.