Get best of the week

SCRUM: a poem about love and pain



If he is so good, then why does not everyone work only according to this methodology? And those who supposedly implemented it often show off a monstrous ScrumBut. A true SCRUM leaves scars, wounds and marks on your heart, and now I will tell about mine.

Scrum pain


When I first tried, I was already young and understood this. I just fell in love with the book Jeff Sutherland SCRUM: The Art of Doing Twice the Work in Half the Time. True, towards the end he seemed a little fanatical to me when he began to tell how the methodology helps in school and in medicine. But I really learned a lot from Sutherland and immediately decided to try this technique on my team. Scarce pains began.

Delays and delays in meetings


What if you want to meet the 10-minute stand-ups, and someone is 15 minutes late? First, everyone is waiting for him, and then I want to go into the details, and the standup is delayed for an hour. And if someone has not reached any meeting, then he is now out of touch with the events and asks everything again. All this leads to the fact that no one has yet begun to work, but everyone is already tired of a viscous meeting. First of all, I had to work on discipline: without delay, without argument, without going into details. To be honest for 5-10 minutes, the scrum invigorates, but how does it differ then from the traditional Soviet meetings from the morning?

Disputes, detailed discussions and goals


You tell the team “we have 5-10 minutes”, and they tell you that if we do not work out this petty squiggle, we will not be able to move on, and it will block us all. Or even worse: we need to see a general concept and strategy, we cannot work without it, so let's crush excrement in a mortar around. A strategy and a general concept are needed, they need to be taken care of before the start, if they are not there, then you should not go in cycles and slow down the work of disputes.

We are faced with the fact that it is very difficult to start a sprint without understanding the global goal of the company as a whole team:

Scrum master: “Let's formulate the goal of the sprint: measurable, understandable, achievable!”
Skeptic: “And why should this goal be just that? Where did you get her? ”
... and there was an argument for an hour.

Scrum master: “The goal of our product is to eliminate people from measurements. Let's state the goal of the sprint! ”
Peppy: “Let's gash a mini-module that will take the counters and put them on the plate.”
Skeptic: “Well, no, but suddenly it turns out that this is an extra work, you need to understand the project as a whole. I want to keep the whole project in mind! ”
Scrum master shoots himself in the mouth with a shotgun ... I will

write again briefly the conditions for starting the sprint:

  1. No delays
  2. No passes
  3. Without delaying the meeting
  4. No argument
  5. No small parts
  6. The global goal is clear, with which the whole team agrees.
  7. There is a willingness that the mini-sprint will be erroneous, and that the sprint goal is chosen incorrectly.

It all hurts a lot, a lot of pain!

Keep the whole project in mind!


... the Scrum master who has just come to his senses in intensive care again falls into a coma ...

There is no project and cannot be in the head, since the world around is constantly changing. Everything in my head is just an illusion. No need to be afraid to do too much unnecessary and wrong as part of the sprint. We are moving in small steps, so there is always the opportunity to correct mistakes. Than to argue for two weeks, let's catch two sprints during this time, let's make a mistake, test hypotheses and win the fight!

That is why we leave all disputes and democracy to sprint planning. When the sprint started, let's not argue - the results will judge us very soon. Ready for change is part of Agile Manifesto!

Do not tell me what you did yesterday!


When you and your team are running a sprint in the scrum, then you have a side that what is left behind you! Moreover, often at stand-ups everyone is drawn to tell who did what yesterday. Why is that? Yes, because it is much more difficult to tell what you want to do today, how it will bring you closer to the sprint goal and what blocks you.

By the way, if we discuss only plans for today, then there’s practically nothing to talk about. The future has far fewer people loaded with emotions than the past. Sprint is looking to the future. If you follow this principle, stand-ups will take no more than 10 minutes.

Grooming difficulties


When the monkeys ate enough and sexed, they sit down to comb insects from each other's wool. Team members, like them, comb out small tasks with legs from the general stream, trying to make them as short as possible.

It often turns out that the task is not properly scheduled when the work has already started. Nobody wants to comb out anything. As a result, everyone cries with bloody tears due to being too lazy at the start. The smaller the task, the more understandable and the more difficult it is to make a mistake.

I usually sit down with developers outside the sprint and read each user story aloud in chorus.

The team itself chooses the tasks!


But this is a real pain for scoops. How so? After all, it is much easier to assign tasks directively. As you know, the Soviet, that is, the Russian people is not ready for democracy, there will be chaos!

And then it turns out that there are tasty and interesting tasks, but there are boring and routine ones. And it also happens: there is your task, you specialize in this. And then suddenly someone non-core grabs it from under your nose, because it is so tasty and interesting.

Let it hurt a lot for managers, but when team members choose their own tasks, we get better performance and better quality.

... Scrum master smiles without leaving a coma ...

Cross functionality


The command of the special forces may be a doctor, radio operator, commander, mechanic. But what if someone is killed? Then their functions will be picked up by other fighters. This principle is used in the SCRUM team so that there are no “bottlenecks”. If everything is stuck on one or the other, then the rest of the team should quit their job and take up tasks unusual for them.

Scrum brings a lot of pain to your professional pride: “I’ve studied for so many years not to screw the curtain rod.”

Failures


Of course, my first sprint ended in failure. And almost every first sprint with a new team ends in failure. Most often, the reason is that the sprint goal was incorrectly formulated. It turns out that it was unattainable and incomprehensible, the team overestimated its strength, and most of the work was blocked by the customer.

The most interesting thing is a retrospective of a failed sprint when time is up and goals are not achieved. No, no, we will not extend the sprint for the day, no, we will not work at night! We acknowledge the failure and we will analyze what we were wrong with, what happened successfully, and what could be improved.

Usually after such a debriefing, everyone gathers and the next sprint is super successful. In the second retrospective, the whole team begins to get a real buzz from work, and therefore from life in general. You set yourself measurable, achievable, understandable, but complex goals and now you are blissed out by their achievement.

The fact that the sprint will be completed with any result reduces anxiety and allows you to concentrate on local tasks, and this improves the quality of execution.

... wow, our Scrum masters are already transferring from intensive care to therapy, coma behind ...

SCRUM is like a flame, it burns you when it's hot


Professional burnout! Scrum is the best way to speed it up! If you do not take a break after each sprint, then everyone will quickly get tired, stand-ups will turn into a routine, and work will slide into complete trash.

Life satisfaction comes when you set bold goals, fight, experience failure, get back on your feet and achieve results. You can’t live in this mode forever. They completed the sprint - took a week-long break: they raked up routine tasks, went on vacation, switched to other projects, and regained strength for a new battle. To fall in love again, you need to lick a little wounds from previous experience, and you're ready. Although many are drawn towards polyamory, and this is polybola!

We connect the client to SCRUM


Even if the client is not a programmer, he will get high, I promise! Only everything should be honest. A true SCRUM: you cannot throw away important parts, turning everything into the godless ScrumBut. Project goal, backlog, sprint goal, the team selects tasks and gives an assessment, daily stand-ups, retrospectives, breaks between sprints. If at least something is thrown out of this, then everything stops working, and the customer is disappointed in a flexible methodology.

Be like Sutherland, be fanatical when you are told: “Oh, this is all so inconvenient, SCRUM is good, we will work on it, but it’s not necessary to follow all its principles.”

Often team members tell me: “How can I, because the customer will see the unfinished work and will swear.” That’s the whole point! The rougher the prototype - the easier it is to criticize, the sooner you hear criticism - the less time and effort you spend on edits and improvements!

This is exactly what Agile Manifesto tells us:

People and interaction - daily stand-ups with the customer and the team!
Collaboration with the customer is also about this.
Willingness to change - the sooner we make changes, the better!

So rosy? And where is the pain? Ha! Everywhere: management is afraid and postpones the start of the sprint with the client, worries that the client will see the non-finished work. There are customers who want to buy the finished product, like in a store, and they think that developers need the standups, not them. And once they told me: “We want everything to be flexible, and the price to be tough”

The price is tough, tasks are flexible


... in this place the Scrum master already conducts the scrum from the hospital remotely.
Wait, is that really possible? Scientists are still arguing about this ...

Show me a developer who would not be afraid of such a statement. In his head, the prospects of lifelong slavery are immediately born. The Director General, with these words, imagines the bankruptcy of the company and the collapse of the business. Is this the main pain?

It turns out that you can make the customer tough prices with flexible tasks! We fix the money, evaluate the tasks and understand which ones fit into the budget and which do not. Here, of course, you walk along the blade of a knife. The client will argue with the assessment of individual tasks, and the manager will try to give an assessment instead of the developers. This can only be done if everyone agrees with the principle: whoever does it evaluates. For this principle, you have to fight hard with management and customers.

Large-scale projects


Some people think that happiness and bliss are in big projects.
Some fools fool themselves, I guess
They're not foolin 'me
I know it isn't true I know it isn't true
Large-scale projects are just a lie that ends in a blue face. According to statistics, mostly small projects survive.
To turn the world around, a small team is enough.

Usually a successful large-scale project is a series of small cool ones. The main thing is a working product, as the manifest tells us. Let's not chase the scale, but start with a small, but fast, flexible and working.

The larger the company, the larger the project, the less flexibility they have. That is why SCRUM focuses on a small project that can be done in one sprint from 1 to 3 weeks and a small team from 2 to 7 people.

At the same time, very large teams and very large tasks can still be done according to a flexible methodology, for this you need to cut everything into small tasks and small teams.

In the dry residue:


  1. Scrum work hurts.
  2. It is necessary to work in Scrum, as win guaranteed.
  3. You need to follow the methodology clearly and fanatically without slipping into ScrumBut - this is the most difficult and painful.
  4. We involve clients and management in SCRUM to the maximum; this is not as painful as it seems.
  5. We cut all large-scale projects into small ones, although this hurts a lot.

Sources of pleasure:


  1. Manifesto for Agile Software Development
  2. What is ScrumBut?
  3. SCRUM HURTS song

An explanation for the pain, especially for Masha:


The pain is usually that you have to change everything that you are used to. The pain causes a feeling of loss of control and an uncontrollable process when you entrust your favorite tasks to team members and are afraid that they will overwhelm the project. The pain comes when you step on the throat of your own song and break up large-scale projects.

The pain passes when the tasks are super-small, and even the fierce fakapa of the participants do not overwhelm the entire project. It becomes easier when you stop worrying and spread straw on the entire project right away, when you relax and cut one task at a time.

More articles:


All Articles