Scrum based High-tech Product Development with a very mixed Group (Seniors & Novices)

Question

I'm already a (certified) Scrum Master of a software Development Team and I'm going to/have to establish an agile product development process (Scrum is favored) with another group with four engineers.

Two engineers (PhD level) have been working for years on this very complex software based product. I'd guess you need at least one year to be somewhat productive (though three years may be more accurate).

Now two job starters (directly from university) will join the group. But they will need massive training: one in physics and math, the other one in software engineering and programming.

I already had some discussions with the designated group leader and Product Owner. While appreciating agile ideas, values and practices and Scrum in general, he thinks the idea of a time-boxed Sprint would produce additional stress in the beginning. He would prefer a more event-boxed Sprint (we finished this feature and now we can Sprint until the next feature is done).

I mentioned with this approach he will be missing the important aspect of synchronization in time. But on the other hand the novices will not be able to estimate the smallest feature at all. The designated group leader/Product Owner is willing to switch to a time-boxed sprint after the new group members are trained, productive and cross-functional.

What do you think? Is this possible? What is the best way to establish Scrum in this situation? Is there a better-suited agile process?

Answer 1

he thinks the idea of a time-boxed sprint would produce additional stress in the beginning.

I disagree with this assessment. The time boxed sprint is not intended to create a stressful deadline. Instead it is a natural break point that allows the team to get feedback and to inspect & adapt.

A Scrum team that is a mixture of experienced engineers and new job starters should not be a problem. The velocity of the team will adjust to allow for the training and mentoring. The result will be a sustainable pace of delivery that takes account of the mix of capability in the team.

Answer 2

Who has authority?

the designated group leader and Product Owner

Here's one of your problems. As a Scrum Master, it's your responsibility to ensure that the Scrum Team (including the Product Owner (PO)) understands and follows the Scrum process.

But the PO is your 'designated group leader'. Your boss. You need to clarify expectations from the management source that wants the company to follow Scrum. Are they following Scrum, and the Scrum Master has authority over the process? Or are they doing Scrumbut, and the 'group leader' has authority over the group that Scrum does not prescribe/allow?

---

It's your job to ensure everyone understands the benefits and goals of Scrum

As mentioned above, it's also your responsibility to ensure that the Scrum Team understands the Scrum process.

From the Scrum Guide:

The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort.

One of the advantages is predictability of releasable builds.

Another advantage is getting better at estimation itself. As you mentioned, "the novices will not be able to estimate the smallest feature at all". This is fine. No one is good at anything when they first start doing it - including estimation.

The first several Sprints, the new members will be awful at estimating. This is fine and expected. Over time, and with practice, they will get better.

---

Avoid blame

he thinks the idea of a time-boxed sprint would produce additional stress

As Scrum Master (again, assuming you actually are - see above), you need to educate him that this viewpoint is wrong.

Also from the Scrum Guide:

The Development Team works to forecast the functionality that will be developed during the Sprint.

Note the word 'forecast' here. It used to be 'commit'. It was changed meaningfully. The Scrum Team does not commit to their estimate for the Sprint, so missing it should not be cause for blame nor shame.

Answer 3

For the sake of argument, ignore for one second the two entry level developers. You now have a team of just the two experienced engineers. Do you see any issues in implementing Scrum now? Probably not. You will develop in sprints, you will have sprint planning, you will do refinement, you will have retrospectives and reviews, build and deploy product increments, collect feedback, inspect and adapt, etc.

Now, if you add the new comers into the mix what happens? The capacity of your team will decrease. The two experienced engineers will no longer be available 100%, but less, because they need to train the new people, offer support, etc. You will still do the same Scrum activities like above, but you will see a decrease in delivery. This is normal and unavoidable with new people being integrated into any team.

No matter what you do, and how you organize things, delivery will slow down. So if this is unavoidable, why would you do anything else than the Scrum you would do with just the experienced people?

All four people will eventually need to work together. Involving them in the actual work and processes is the best way to accomplish that. As the new people get more experience, the capacity of the team will increase because the experienced engineers will spend less on training. Then when the new people become proficient at what they do, the capacity of the team will increase even more. And all of this time you will be benefiting from what Scrum offers you.