Project-Based Scrum - is it normal to structure Scrum Teams around projects?

Question

My company suddenly introduced a new change to our workflow. They call it Project-Based Scrum (they claim that this Scrum is the real Scrum by the book).

So how this thing works:

1. There will be multiple projects
2. each project will have different team members
3. after the project is done the team will be disbanded
4. each project will have different stand-up, grooming, and planning meetings
5. A Product Manager will handle multiple projects
6. Idle team members will focus on a maintenance/bug board
7. Tech leads will lead the Project teams and will select the team members

Does anyone here know what company uses this kind of Scrum? Or it is true that this kind of Scrum is the real Scrum?

I'm confused about how this Project-Based Scrum will work.

Answer 1

This is not Scrum.

Scrum has a definition in the Scrum Guide. This is a living document - it's reviewed, maintained, and updated based on feedback from people using it and experiences. This is "real Scrum".

Now, what the Scrum Guide provides is a framework. There are a couple of rules. You can add things to Scrum. In fact, you almost have to add things to Scrum since it doesn't get into the details of how to do most of what is suggested. However, you cannot remove any of the events, roles, or artifacts as the end result would no longer be Scrum. That doesn't mean that removing something is bad, it's just that you shouldn't be calling the end result Scrum anymore.

The Scrum Guide is short - the November 2019 edition (the most recent as I'm writing this post) is 19 pages. That 19 pages includes a title page, a table of contents, and the bulk of the last page is acknowledgments and credits - the guide itself is roughly 16 pages of content. If you aren't sure what Scrum is, the guide is the best starting point.

Answer 2

I've worked with quite a few organizations that use Scrum like this and I've coached some of those teams, however, none call it "Project-based Scrum".

I would highly recommend that you look at the Scrum Guide. It is fairly short and will tell you what is and isn't Scrum. While you will probably get a lot of the benefits, there are a couple challenges you will most definitely face with the points you've provided and a few that you may face in this sort of circumstance.

1) Having a team lead head and select a team nearly always interferes with self-organization. An expert-style leader inhibits self-organization and since most team leads have a high level of technical knowledge and little, if any, leadership training, they predominantly use expert-style leadership.

2) Product Ownership is hard. It sounds like you will have people with the job title of Product Manager in the Product Owner role. Being asked to do this for multiple teams is very, very difficult and demanding. There just aren't enough hours in the day to do a good job.

3) Hopefully #2 means each project will have its own cross-functional, dedicated team. This is ideal. One of the challenges with these project based teams is that often times there is spill-over from old projects and then team members get pulled back to old work. You can, to a degree, mitigate this by bringing hold-over work to the new team, but then it will impact the new project. It gets a little tricky. The general advise is to bring a new project to an existing team rather than reforming, but it doesn't sound like your organization wants to take that route.

4) Tuckman's model of team forming tells us that every team goes through a series of phases: Forming, Storming, Norming, Performing. We also know from research by Katzenbach and Smith that teams have a baseline productivity that dips in the early stages of team formation. This dip is usually made up for by the extra productivity a team gains in late stages. However, this process usually takes months or years. Constantly forming and reforming teams will likely result in a situation where the productivity of the teams will always be lower than the sum of their individual output.

5) The big benefit to the organization of Scrum and Agile is that they can pivot with new learnings. Many companies who take this project-based Scrum approach keep to fixed-scope projects with all of the work decided up-front. This means that the workers get a lot of benefits that they normally enjoy with Scrum as far as a more organized and sustainable work environment, closer relationships to coworkers, high levels of success celebration etc. However, the organization rarely realizes any significant value from the change.

Answer 3

Generally agree with Daniel's answer above, but wanted to expand on his point about team formation:

3. after the project is done the team will be disbanded

Good grief, why would anyone do this??

Team dynamics are critical to team-based work, and it takes time for a new team to work through forming/storming/norming to get to performing.

I've heard of orgs that take the approach of disbanding teams that are not performing as strongly, and remixing them in hopes of getting better team dynamics, but that is different from arbitrarily disbanding at the end of a project.

If the org doesn't take the team unit seriously, why should the team members?

Answer 4

There is no such thing as "the true Scrum", Scrum is a framework, which has some rules / guidelines. How and if at all you exactly follow those guidelines is up to you and your team.

If you deviate from the guidelines too much, this usually is called "Scrum-But" which is a short-form for "We do Scrum, but... we dont do X, we do Y in this way, ... we have twice as much Z...".

There are best practices for Scrum, which have shown to work most of the time, those seem to be the ones that they are referring to as "Scrum by the book" in your case.

So a lot of companies do the Scrum you are describing, if this is the best version of Scrum is open to debate, but usually "what works, works".