Scrum used as a timeboxed waterfall

Yes. This is unfortunately common. There a number of terms for this…SINO (Scrum in Name Only), Zombie Scrum, Mechanical Scrum, Scrum-erfall, Scrum-but, Scrum-ish…

As you mentioned, the empirical benefits of Scrum are lost when this happens. Teams are often just going through the motions.

Planned Sprints give a false sense of control. A security blanket. The only thing that is guaranteed when you have a plan, is that you have plan.

How often do those planned Sprints go exactly as planned? In my experience, never. A lot of pressure builds when Sprints are not going exactly as planned. A lot of time is spent moving work items between Sprints as more is learned and when work takes longer than expected. 

What I have done in the past is collect and use data as a mirror. Here is how often we have had to move backlog items between Sprints. Here is how often we have been wrong about how long we thought something would take. And so on. This has worked with some teams. It can open the door to discussions around complex work and why planning won’t work when there are more unknowns than knowns. 

Thanks Ryan for your response.

How often do those planned Sprints go exactly as planned? In my experience, never.

Exactly they fail and sometimes badly. I have faced cases where plans are made with some technology/tool in mind but lot of issues come up during the implementation and sometimes the technology/tools need to be changed altogether. In some scenarios even product owners are not empowered enough.

What I have done in the past is collect and use data as a mirror. Here is how often we have had to move backlog items between Sprints.

This is the approach I also follow but I have faced cases when teams are ok about spillovers. The idea is the release is after 4 months so nothing wrong when something spills over to the next sprint. They think lets take whatever we can so that we can relax during the last few sprints (sprints as in the plan) and sadly that never happens they end up struggling in the sprints before the release. This is more worrisome because you miss the opportunity to inspect shortcomings in your process/tools/people.

Even worse there are sprints which are just QA / regression sprints where it is all about testing and bug finding. This clearly to me is waterfall (Scrum fall as mentioned by you). Also the value part is sometimes missing it is all about getting features in.

Yes. Working in such a situation right now.

The philisophy and intention is good: an experiment where we mix 4 existing (component) teams into two cross-functional teams and have them each migrate one application in one week. Although I liked the idea of experimenting with cross-functional teams, the goal for the week has been determined by other people. The result is a very short 'sprint' with teams that are too large, and have not made any commitment to the sprint backlog (which is my strongest concern). This kills any sense of autonomy and self-management. You could even go as far as to calling it lack of trust, which is the foundation of scrum. 

Moreover, not all team members are familiar with scrum, some are even sceptical. By asking me to be the 'scrum master' this week, the message is that we're doing scrum. We're not. My first reaction was to refuse and emphasize why this ISN'T scrum. I was afraid that people would get a completely wrong image of scrum. In the end I agreed to do it on the conditions that I could explain to the teams that this in fact wasn't scrum, but that we were trying to learn as much as possible about this new form of cooperation.

Summing up: we're basically doing a timeboxed waterfall with a strict deadline, but I'm in a unique position to support the team members and use this example to explain how scrum would be different. I've already had invitations from other teams to come & explain my views on scrum and different ways of getting things done. So I'm happy with the results so far. 

Why do you think Scrum is misused this way 

Because, on the whole, people want change but they don't want to change. They would like different outcomes, but the process of going through empirical change is painful. The result is a veneer of agile practice.

A certain humility is needed when it is not your company to transform. You don't own it. What you can do is to illuminate the agile gap, and extend a hand over it to help others cross if they want to.

Finding sponsors who will establish a sense of urgency for change is important, so organizational gravity is overcome. Until then people have their day jobs to do.

A certain humility is needed when it is not your company to transform. You don't own it. What you can do is to illuminate the agile gap, and extend a hand over it to help others cross if they want to.

Thanks for your response Ian

They probably thought the type of work is not complex so they don't expect much sprint feedbacks or uncertainties that would impact the plan. I think they use Scrum only to have "Transparency" on the progress or work done by the team to mitigate risks if any to achieve the scope in committed timeline. So here Scrum is assumed as a process only to achieve the prepared plan and nothing to do with the plan itself. The plan is almost always fail because people committing may not be the one doing the work. if there is a contractual agreement behind it then the value of the product may not get maximised as there will be less chances for the team to inspect and adapt.i would suggest to highlight this risk to respective stakeholders who can own it.