Agile High-tech Product Development with a very mixed Group (Seniors & Novices)
Hello Scrum Masters,
I’m already a (certified) Scrum Master of a SW Development group 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) are working for years on this very complex software based product. I guess you need at least one year to be somewhat productive (I think three years would be more accurate).
Now two job starters (directly from the 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?
Thanks in advance.
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?
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?
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.)
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?