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

Hi Florian, 

I think either time-boxed or milestone based could work for you. Do you have a general idea of how long a feature typically takes to develop in your context? 

Regardless of which you choose I'd expect your productivity to go down while the new hires are learning. Sprint's can be a good opportunity to keep them focused on a goal and pair with a team mate that has the same goal. Keep in mind the impact to productivity when deciding the Sprint Goal and the length of Sprint as well. 

The great thing about the Scrum Framework is that you can experiment with this for a while and adapt your processes to best suit the team as you inspect them. 

But on the other hand the novices will not be able to estimate the smallest feature at all. 

Why not? I'd suggest that they can estimate, or propose a means of doing so, even if it is very poor. Scrum is based on learning and continuous improvement, and collaboration between team members of greater and lesser experience. Does this present a problem?

Hi Tony, 

productivity is not an issue. We accept that the new co-workers have to learn and the project is a long term project. Do you have an idea how to adapt the framework to get the P.O. on board?

Hi Ian, 

I think the concerns of the P.O. is that there this new group is a very fragile social construct. For example the new co-workers will have to learn a complete new language (C++). They can estimate and they know it is a poor estimate. Will this push their confidence? 

Anyway I have to find a way with Scrum to slowly integrate Scrum in this group with every team member on boat (especially the P.O.)

Florian 

I asked about the typical time frame for a feature because if it's less than a month it shouldn't be too complicated to manage the work within 2-4 week Sprints. If your market is not incredibly volatile and you're okay with longer formal feedback loops you could explore a 1 month Sprint to help your P.O's concerns about added stress. 

As for estimates, having the new team members participate can help identify gaps in their knowledge and help create conversation around their understanding of what is being asked to better focus their training. 

They can estimate and they know it is a poor estimate. Will this push their confidence? 

Have they been given a safe environment in which to estimate and learn, and if so do they know it?

Sounds like the technical level of the engineers isn't truly a part of the equation of whether you should use Scrum or not. If you remove that element from the equation for a minute, you're left with the choice of working time based or event based in any framework.

In Scrum, you are a bit of both. Since this is a new team and duration of Sprint isn't quite known yet, have them create a Sprint Goal and have that represent the Event. Then build a Sprint Backlog with all the items necessary to achieve that goal. Finally, have the team come up with an estimated time in which they'd prefer to get some feedback. Have that duration be the first timebox. 

• Perhaps they think the work will take 3 weeks, but would like inspection every week. 
  • Go through all the events and run a one-week Sprint.
  • Refactor the Sprint Backlog to represent the first week's preferred load.
  • During Retro, allow the team to assess the duration and see if extending to 2 or 3 weeks is worth trying out instead.

The purpose of Scrum is continuously improve your product/processes/working environment.

Nobody should really care how fast or how long the work is taking or what's the best Sprint duration or how good are the estimates or even the synchronization. Instead, you should care about identifying the things that prevent the team from being as productive as they'd like to be, and creating the opportunity for them to be learning from their decisions/estimations over time. Sustaining pace will come later as the new engineers become more proficient, but for now the goal should be getting them to collaborate as equals, working together for a shared goal, visualizing their work and discussing daily what they plan to finish that day. 

While appreciating agile ideas, values and practices and Scrum in general (the PO) thinks the idea of a time-boxed sprint would produce additional stress in the beginning. 

What evidence is your PO basing their thinking on?   What Scrum training has this PO received?   What do they (or do they not) understand about the purpose and benefit of a time-boxed sprint?

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.

Who is making the determination around the "productivity" of new group members?   Why is cross-functionality of team members a pre-requisite for moving to time-boxed sprints?   Why is individual cross-functionality a goal at all?