This is a translation. Original, in Russian, is here:

A long time ago, in the year 10, in the city far, far away, named Kiev, I was working in a small but proud software company called [censored]. This company, in turn, was working for a small-town investment bank from a Swiss village called Zurich. And, at some point, somebody from above got an idea — let’s merrily fuck away some moneyhire some cool con sultans (like Craig Larman, for example), and create Agile Teams!

No sooner said than done. I wasn’t quite in time to see the start of this process, but the “how it goes” I’ve seen alright. Now I have to tell you something about [censored]. It has a distinctive feature: it really is fucking HUGE. [censored]

It’s IT department also employs quite a fucking lot of people; literally thousands of programmers from all over the world, from NjuJork to Bangalore via some Londons, Zurichs and other green pastures.

Advertisement

Presence of Bangalore in this list already defines the quality of the product’s intestines. So, inspired by “We need YOU!” banner, this guys decided, that the SCRUM it must be, and then everything would be fucking awesome.

Now, what exactly is “SCRUM”. First thing I saw was a scrumboard, used to jerking off to burndownhanging stickers. A common scrumboard consists of a few sections like

Advertisement

  • Planned
  • In progress
  • Done

sometimes with a flavor of “Tested” — but that’s for hardcore fans (remember, we are agile — you’ll hear that everywhere).

Advertisement

On the second board there is usually a diagram, called “burndown”, which kinda shows the team, how awfulawesome is our fuckupsuccess in this sprint.

Sprint, if you wonder, is an iteration (yes, salt is salty), when in N days you have to do something. Something means, usually, one or more heavy acid tripstasks, invented by the so called product-owner (in a layman terms, a guy, who didn’t manage to evade this position, and who really doesn’t give a fuck about all this — he has his own job) in order to make everyone march to the bright new dawn.

Advertisement

All this tasks are stacked in the so called backlog, which is a list of those tasks, aka user-stories, sorted by priorities. And those priorities can be changed on a whim — remember, we are agile.

Oh, the main point! This tasks are estimated in “story points”! If you ask a scrum follower — what are the storypoints — he would likely give you some buzzwords about all tasks being different, but we don’t know how are they different, because we never did any of them, and, in order to estimate something we don’t know — we introduce some intuitive metrics, saying that one task is two times more complicated than the other, and after that we — upsy-daisy — sort them. Storypoints are taken from the Fibonacci sequence (you know, 1-2-3-5-8-13-21), with “1” meaning “nothing at all”. In plain English — dream it up.

Advertisement

How to tell, how many tasks the team can do in a single sprint? Let me remind you, that we don’t know shit about this tasks, seeing that this is a Very Big Bank, with gigabytes of code in java, c++, cobol (it’s not a joke, I’ve seen it myself), python and other dragons. Scrum followers decided — let’s say the team has it’s own velocity, in storypoints.

You see the grand design here? Estimate an unknown amount of work in some abstract furlongs, estimate how much the team can do in the same furlongs — and deduce from it that the team can take, for example, tasks A and B.

Advertisement

Will it work? Immediately no. But! We are agile! And it’s a bank — and banks don’t count money. (well, actually, they do; buying a license for IntelliJ IDEA or JRebel is a big deal, and in the end we still didn’t get them. Talk about irony). So, to get away with it, consultant guys said — it’s temporary, it’s gonna work itself out!

So, the new team is guaranteed to fuck upunderperform in the first 5-10 sprints — and that’s considered OK. Given that the sprint is 2 weeks — 1 to 3 months the team would not make the promised stuff in time.

Advertisement

A small detail — the longer the team is working in some area, the better it is in predicting it’s own workload and setting the right deadlines for itself. Secondly, when it’s transfered to the new project, it would suffer the same kind of fuckups, for obvious reasons.

Now, about the burndown. You have to understand, that classic SCRUM is not about hours. Because how it can be about hours, when tasks are estimated in furlongs? On the other hand, software consultants are billing the client for hours, not furlongs. Now watch closely.

Advertisement

Let’s say there are tasks A and B taken for the sprint. In total, that means, say, 5+8=13 points per sprint. Then, stories A and B are, at the sprint start, disassembled into tasks (like, create this class with that interface, find out how to integrate all that, append something to the database...). This tasks are invented by the whole team. And then they are estimated again, but... in hours. And if one man says “2 hours”, and another says “8” — there is discussion about why; maybe the one who says “2” knows something others don’t. Or the guy with “8” sees some hidden fishhooks ahead. After a long brawldiscussion some average is decided. And there is an unwritten rule: tasks can’t take more than 6 hours, those should be disassembled further.

And, after all tasks are planned and broomed together, the burndown is drawn, with two lines; one is a theoretical performance of the team (N guys times M hours a day, with M<=8). And the second line is everything that was taken for this sprint.

Advertisement

Then, every day, in the morning, they determine, which tasks were done yesterday, something is calculated somehow, and the result is a collection of dots, which, when connected, becomes a performance graph.

Advertisement

Ideally it should all converge to 0.

There is more. Scrum also has a thing called standupcomedy, when, again, every morning the team assembles to pray to Schwabertell, what was yesterday and what is planned for today, what hardships and asperities were overcome and what were created and then overcome. This usually takes from 15 minutes to half an hour.

Advertisement

This is followed by a meeting(s) with a productowner. To make sure that while we were developing the battle plans, they didn’t change the whole landscape with a shovel. This takes 1-2 hours average.

Scrum also declares the absence of management, like “team decides”, which, in theory, means that the team can cancel the sprint altogether, if some meeting left it in complete disarray.

Advertisement

And, lastly, there is a thing called “retrospection”, which takes place after the fucked upsuccessfully finished sprint in order to find out, what was wrong and how to fix it.

What can we make from all that?

1) The team that consists of real professionals, with real knowledge of the subject — doesn’t need scrum.

Advertisement

2) Scrum allows facilitating some processes, for example — calling meetings, holding discussions, communicating with the client, drinking coffee. And if there is more than one guy like that in a team — everything is lost. The team can fucking expel one guy; two are a lost cause.

3) In consulting work, scrum is good when client’s brain is already messed up by couchers and he is ready to pay for all these meetings and other cargo cult. In real development work, scrum is rather hurtful than useful.

Advertisement

4) As all other methodologies, scrum is no better or worse then the rest. A good team would do a good work in scrum as well as in waterfall. A bad team would do a shitty job in scrum, in rup, or in canban equally.

UPD

Some commenters noticed that I didn’t say anything about getting tasks from backlog. In an ideal world the backlog contains exactly what is needed for the task. In real world, however, backlog is full of tasks like that:

  • Add to the counterparty list stock market identifiers from APAC. 13 pts.
  • Change market messages format, add a NeedReconciliation field, update the rules in Drools. 8 pts.

Advertisement

As you can see, neither of these tasks contains a single bit of information for developers. At all. What’s more, even product owner often has no idea what it is. But, since the team already did 20 points in the previous sprint, it can take both. Because team capacity allows.

After planning, the team starts frantically searching for clues — what is that list and where to get one. And what kinds of stocks are there. And what can be done with them. They find out, that Ellie knows about stocks, but she’s in NjuJork and still sleeping. And Ramjesh knows about the list, but he’s in Bangalor and already left to worship Krishna. And later, when you get hold of Ellie, it’d turn out that she doesn’t know shit, you were misinformed by the productowner. And she doesn’t know who does know, but it could be Maria. Who is on vacation until next week. And Ramjesh is not the right Ramjesh, because the right Ramjesh diedquit in 2005. Absolute collapse and information deprivation.

Advertisement

We had a situation once with a fucking hell of a Java code that was created in 2004, with no tests, nobody who understands or at least has some idea how it works, because the description of internal protocols was already lost. And this task was estimated as 5 points.

Therefore 8 times out of 10 all the tasks that were taken for the sprint weren’t the right tasks. The owls are not what they seem (c)Twin Peaks. And a week of the team’s time goes to finding out — what is it that has to be done, and how to do it.

Advertisement

Best case scenario — you need to change two characters in a CSV file, which was last touched 7 years ago. When it was first added to version control. Worst case scenario — is like my task for 2 points, which was given to me on my second week there. I found it on the board in the “work in progress” section, when I visited [censored] again for some reason three years after quitting.