Struggling as Agile Leader
I'm struggling with finding the the best path to walk when I'm looking at description in the scrum guide and the agile manifesto. Or I'm overthinking and by doing that I loose the clear vision. But anyway I could really be helped by seeing how agile leaders/scrum master with much more experience as I have deal with this. I want to do it as good as Scrum describes but sometimes I'm a little lost in multiple principles from the manifesto
I'm thinking in actions like these which I've encountered
- 'when do you let the Scrum Team fix an issue themselves' and when 'has it become an impediment' that you as Agile Leader/Scrum Master needs to tackle.
- like for example work that keeps coming from outside of the team so the team can't succeed in their sprint (goal)
- when should you intervene when somebody from the development team doesn't feels heard and when or how should you let the scrum team let it tackle by themselves. Here they are all motivated but then they don't listen to him as well as he would like it..
- Is that lack of respect then that the Scrum Master should tackle?
- when you (and the team) feels that there is need to add a new developer to the team, who will do the recruiting?
- I'm sure that the team itself can best say/feel which developer can be added to the team and do the recruiting
- but that is time consuming and may hinder their work in the sprint (impediment?)
Also items like that the management want to know how the scrum teams are performing. The upper management needs to create a reliable forecast towards investors in what can/can't be done in the next year. But scrum is also about adapting and improving by customer feedback so what can you say what will happen within three months.. They also want to have it clear in 1 view how the teams are performing, so how can you really do that then?
I think that this comes from my situation where I sometimes feel located in the middle between the management and the scrum teams. I want to create nice report but for that I need the input of the teams. The teams are focusing on the near future (current sprint and max 2 in future) so they can't give a real good estimate on the upcoming projects.
- If work is coming from outside the team, it does not necessarily mean that the team has to do it. If it endangers the Sprint Goal then they should not. Coach team members to refer unsolicited work to the Product Owner. He or she can then determine if it is relevant and, if so, order it on the Product Backlog.
- If a team member feels they are not being heard, coach better soft skills to the team, such as active listening. A silence does not have to be filled.
- If a new team member is needed, encourage the team to self-organize this. Coach the organization and stakeholders to expect a short-term drop in productivity while this adjustment is made.
- If management wants to know how a team is performing, coach them to ask the Product Owner. Only he or she can account for whether or not adequate value is being delivered.
When do you let the Scrum (DEV?) Team fix an issue themselves.
-> If solving the issue has learning effects for the domain the teammembers are working in, and the sprint goal will not be in danger.
Like for example work that keeps coming from outside of the team so the team can't succeed in their sprint (goal)
-> Think about the value of your customer/user. Focus on that. Exceptions only when the team gains huge learnings, so it would be worth it. The backlog is owned by the PO, the sprintlog is owned by the DEvs. Work from outside could be adressed to the PO to maybe get implemented in the backlog. If you are worried, not doing this outside work in the middle of your sprint will have critically negative results, you have to work on roles and ressources, maybe an additional kanban team for emerging work? Keep complicated stuff away from your SCRUM-DEVs and let them do the complex work.
Is that lack of respect then that the Scrum Master should tackle?
-> Yes, you want to know the why, who and when. It would be a good practice to step out of the comfort zone to adress the issue in a (retro?) conversation. F.e. starting with the question: Do you guys feel like your voice is heard. Create a conversation and ask to the point questions. Make every teammembers perspective visible.
When you (and the team) feels that there is need to add a new developer to the team, who will do the recruiting?
-> Both of your arguments are valuable. I would walk into HR and ask for help. As an agile coach i would influence HR. The final choice for a potential candidate is up to the SCRUM Team.
If the upper management needs to create a forecast (for software products) for 1 year, your company needs an agile coach to show upper management the advantages of customer feedback iterative product development or EBM with agile frameworks like SCRUM. Maybe you can agree on a quarterly roadmap? Get upper management into your reviews.