Scrum on constantly shifting projects, team structure and unknown code

Question

I worked for a company where the following circumstances held:

• sprints were two weeks long
• on each new sprint, the team I was heading was changing in members.
• on each new sprint, the team changed completely codebases (that is, on one sprint, they worked on software Foo using python and Qt, on the next sprint, they had to work on software Bar with Javascript and React, and on the third sprint, they had to work with terraform and node). Developers were mostly junior.
• none of the team members had any knowledge of the code, so planning was pretty much a big game of guesswork as we could not give an effort value to code and goals we knew nothing about.
• During one of the sprints, the team was performing work on two unrelated codebases at the same time. I internally divided the team in two, as their work was completely orthogonal.
• End of sprint were treated as deadlines.

The results were poor, but I am unable to say what of the above elements are expected and I simply could not cope with them due to lack of experience in these circumstances, and which are completely broken and the poor results are the consequence of forces outside my control.

Given the scenario, what is the possible course of action to salvage the situation as much as possible?

Answer 1

It feels like there is a lot more context to the story to get a full perspective, but what you are describing is not Scrum at pretty much any level.

First, changing teams (while not expressly forbidden by Scrum) is deeply problematic as it prevents the team from ever norming and self-organizing (which is a requirement in Scrum).

Changing products and codebases is not completely uncommon, but to that degree is kind of absurd. This isn't a Scrum issue per se. It's just common sense that this has a massive toll and there better be some amazing value to pay that kind of price.

Similarly, dev team members with no experience every sprint is a situation that no one could think was a good idea. Imagine getting a new kitchen of cooks that have never used that kitchen before and don't know the menu every night. It might make an amusing gameshow, but I'm pretty sure a restaurant that ran that way would go out of business in a week.

Your split team question is tricky. I mean, you shouldn't have sub-teams in Scrum. You want shared ownership and splitting the team inhibits that. On the other hand, other things destroyed any code ownership so this point seems moot.

Finally, the deadline thing. This is perhaps the only nuanced point here. There is a sort of commitment for the end of the sprint. The team does try to meet the sprint goal and not doing it too often is problematic. That is different than a deadline though as the term deadline implies more significant consequences than I think anyone would recommend in Scrum.

Oh, 2-week sprints are fine.

There's a lot of theory under the surface here about empirical process control, emergent design, and adaptive product development that these things you mention sabotage, but really, this situation is so off the rails it's hard to even talk about those points in a way that connects effectively to this context.

Answer 2

As Scrum Master, it's your job to explain Scrum to the business. It sounds as though Scrum as has been shoe-horned onto an existing set of processes & practices, and expected to give all the usual benefits, but without conforming to the basics that Scrum demands - stable teams, mastery through practice on a given system. You need to go back to your stakeholders, and explain how the process is broken. Even if you set it up as a kanban system, to allow more flexibility and perhaps smaller teams of developers working on projects more continually, this might help. Best of luck.