THINGS ABOUT SCRUM THAT NOBODY LIKES TO TALK ABOUT
3 Elephants In the Scrum Room (Part 1)
Reality is different than theory
The likelihood that you will encounter a “real Scrum” is like winning a lottery. Very low. The 3 elephants are:
- Story points are time estimations
- Frequent context switching
- Who is paying for this? (Part 2)
1. Story points are time estimations
According to the theory:
- Story points are not time estimations but a relative comparison of complexity. They are not mandatory.
- A sprint is a time-boxed event.
- The sprint scope is usually determined by the “projected capacity of the Development Team during the Sprint” (story points).
So, story points affect forecasts. There is no way around this: story points are “converted” to time in the end.
There is also no way around this: your “forecasts” of sprints are seen as expectations on what the team should deliver. Failure to deliver on “forecasts” is a strong performance indicator for some management. It is possible that your team will be evaluated against the ability to predict.
Even Scrum.org recognizes this problem: story points are meant for teams’ internal use. It should be up to the Product Owner if he/she wants to expose this externally. Stakeholders should care about the end results.
Some management looks at the story points as their ROI (Return of Investment). They know how much they are paying for the team and they want to get the most for their money. Because “you get what you measure”, people become obsessed with velocity.
There are various tactics for increasing velocity. A famous one is “stretch goals”, meaning that the team should take more story points in a sprint than they can achieve. Some managers don’t understand that stretch goals almost guarantee failure. You can’t overachieve constantly (unless you constantly overestimate). As a result, a team that doesn’t have a long history of success and praise — will feel each failure.
First, make sure that the team is excellent at what they do, recognized, publicly praised, and acknowledged for a few months — before even thinking about the stretch goals of story points. Or even better, don’t ask about the story points, just the end result and how does it bring value to the business.
If managers talk about delivered story points, increasing velocity, and other metrics, instead of how we make money — then something is wrong. When you deliver things that make money, people are going to talk about that and won’t even mention your metrics.
The IT community should come up with other metrics for Scrum teams and ideas are already in place.
2. Frequent context switching
A list of meetings: daily stand-up, retrospective, sprint planning, refinements, and very likely multiple internal and external sessions. Then there can be pair programming, coaching, meetings about technical dependencies with other teams, and more.
All of these are interruptions. A team member has to completely switch her/his focus from the current work to what is being discussed. That is the nature of Scrum: development and research go in parallel, activities overlap and people have to switch the context often. There is a price for that.
Programming sometimes requires a super-deep focus for multiple days. Programmers can literally dream data structures, algorithms, and whatnot. I am not joking. A programmer must keep in their mind a good amount of variable information (for hours) and must form cause-effect relationships between them (“if this changes, how will it affect other things that I connected it to”).
They have to re-learn this every time they start working. Braking that even for a minute requires a programmer to re-learn the structure again. It’s like almost finishing a level of a video game when someone suddenly plugs your computer out. You must play the level again. It’s a similar kind of frustration, except your job performance, salary and career depend on the “game”.
Some companies, like Basecamp, have their way. For example, they take 2 weeks to refine, tinker, work on technical debt, and thoroughly prepare for the next 6 weeks of work. And then they work (for 6 weeks) without so many interruptions, super focused. It works for them.
The best way of working depends on the circumstances. There is no universal solution, but Scrum is a highly context-switching process for programmers. It can work well for some teams. It can be very ineffective and stressful if not managed properly. And it’s not easy to find a good Scrum Master.
3. Who is paying for this? (Part 2)
The sponsor can be internal (in the same company) or external (another company). More about this in Part 2.