Hot swapping people in a scrum team

Question

In a company, the scrum teams are partly on-shore and partly off-shore. Usually this is 50-50 or 60-40. The teams in their current composition have been mostly going on in a scrum fashion just over a year, with minor leaves/replacements because people join or resign, and that's fine.

However lately, the test manager has hired two additional people at the offshore teams to help with parallel activities (sign-offs, UAT, regression testing activities) without informing the SM, PO or most people in the team. He did inform the "test team" though, that is all the testers from the scrum teams.

The scrum master found out by luck, and was called to accommodate these two new people in the teams, given than they won't be 100% allocated to the teams, because of their parallel activities (managed by the test manager).

Additionally, because one of the offshore scrum team members is about to leave for a month, the dev manager decided to replace him with another one offshore, having been reassured that he has been part of another team (for argument's sake DevOps), knows the software, and will do a very good job. This was communicated via an email sent on a day saying "this guy will replace that guy for one month".

The scrum master doesn't like this approach for a variety of reasons, some of them being team composition, team building, skillset, team confusion etc. He highlighter this to his manager both times and the counter argument is that the business needs the resource and cannot afford to lose time.

Is the scrum master right? Is it good/bad/neutral thing to hot swap resources (especially in a distributed team). Any similar experiences?

Answer 1

The situation you describe is Scrum Zombie, not Scrum. My answer will try to organize a few of the aspects you mentioned.

Software developers are not resources

business needs the resource and cannot afford to lose time

One of the perpetual problem of our industry is to simply assume that people are interchangeable cogs in the machine. In the situation you describe the only guarantee you get with a new person on the team is that:

• This new person will spend time/use budget
• This person will decrease productivity of the other team members (training, setting up environment)
• This new person will change the group dynamics (see stages of group development)

"Hot swaping" people is going to guarantee that you'll spend your money and not get work done.

Adding people to a delayed project will delay it even more

Test manager has hired two additional people at the offshore teams to help with parallel activities (sign-offs, UAT, regression testing activities) without informing the SM, PO or most people in the team.

There is this saying:

9 women can't give birth to a child in one month

Throwing more people at the problem means there will be more communication overhead and as described above will initially delay work. On top of this adding more people won't scale linearly.

You're probably not using Scrum - your SM is right!

Reading the situation you describe:

• Management adding/taking people without the team knowing about it
• Mysterious "test team" that is partially matrixed into Scrum team
• Lack of basic understanding of the value behind Scrum in management team

You're facing a Cargo Cult Scrum. You're just doing some of the practices without the actual benefits and principles behind them. Probably your company just ran "agile transformation" and now it claims to be agile.

What to do?

Help your SM. Assure him/her that you see and understand the all above problems.

Then try to educate/influence this manager. Without their buy-in and basic understanding of the Agile Manifesto and Scrum Values you're doomed in your effort to run an agile team.

Try to convince the manager to read Peopleware by Tom DeMarco. This book should make them aware that:

• developers are PEOPLE
• building a team is hard and you can't just interchange people without a productivity impact
• you won't "bring in" a timeline by adding more people to a delayed project

That's the best book for a beginner manager to understand how to build a successful team.

Answer 2

Teams go through a life-cycle of Forming, Storming, Norming and Performing. Whenever you change the team composition you actually go back to the forming-phase.

Not replacing someone in the team might be more effective than adding a random new person (for a short time) who might challenge how to the team works.

Take into account Brook's Law:

adding manpower to a late software project makes it later

This works the same with changing people. The new people probably will be a drag on the old people, just wasting their time. The effect of extra manpower is a long-term one. On the short-term it will just slow you down.

This blog tips on these topics in combination with remote workers: http://blogs.atlassian.com/2013/07/how-atlassian-does-it-3-tips-for-remote-teamwork/

QA should be part of the Development-Team. Part-time resources are very sub-optimal. I would assign these extra two guys dedicated on a team, not as a shared resources. Depending on people that might have time is not a solid way to finished PBI's within the team. Either you are part of the team or your not. So certainly their time should be managed by themselves or the team and not a test-manager. Self-organising teams do not need command-and-control managers, they need facilitating managers.

Welcome the resources, but make sure the team utilizes them and make sure that do not become a blocking handover point. The primary measure of progress is working (and tested) software delivered to clients on a regular interval.

Answer 3

First of all, Agile is not for the ordinary software developer. An Agile project requires excellent, experienced developers. No galley slaves there, all team members are captains.

Why is that so?

Because Agile is all about being...agile. This might be a big (and unpleasant) surprise for all the management guys. The team needs to be agile, it needs to be able to decide, on very short short notice, how to proceed, adjust plans, adjust strategies, all according to the team's understanding on what is needed. After all, the team is at the core of the problem, spending all day working on it and having the collective experience of (probably) decades in similar projects. Can a typical management guy grok the complete complex workings in a project in a 15 minute meeting and issue a new plan/strategy (within the same meeting)? Nope, most likely not. That's why the team decides, six or seven brilliant guys working at the core of the problem, with a deeper understanding than six or seven management guys.

Scrum adds the Scrum Master and a set of pre-defined rules, to allow an Agile team to get onto the Agile path more smoothly. Still, in Scrum the team decides - the SM is not a manager or a boss in the traditional way. This is not just a disturbing thought for upper management, it's outright alarming. The team managing themselves, totally out of control? Nope. They control themselves, because they are just THE brilliant software development team for exactly this job.

If your upper management is committed to Scrum, they will know that the team decides. The Scrum Master, as the spokesperson of the team, is therefore always right.

In real life, however, so-called "Scrum projects" are getting set up wrongly by management right from the start.

"The team decides? We can't have that in our company culture."

"Yes, we will use the best and most brilliant software developers...let's see who is available...yeah, Mr. Dumbman is available, no one else wanted him..."

"We will use an IMPROVED Scrum method...based on Scrum plus our 40 years of management knowledge and experience on how to successfully manage zero-defect IT projects..."

"But my Scrum book said that Agile is the new silver bullet...it didn't say anything about the need for brilliant people. The second paragraph in the foreword? No, I didn't read THAT far!"