As an agile coach I often have Scrum Masters come up to me becuase management is complaining there are too many meetings in Scrum and that their developers aren't 100% utilised on developing the products. I also have developers asking me if they can skip the sprint review and retropspetcive as they have some work to finish off for the sprint and that is a much better use of their time than sitting in a meeting. Why is it that so many people walk away from a Scrum event saying it was a waste of time, boring or not relevant to them? It's easy to be tempted to just drop an event, but each scrum event has a pupose that contributes to tyhe overall outcomes so a better way would be to make these scrum events more effective and show the value each events contibutes.
I recently became certified as a Professional Scrum Trainer to deliver Scrum.org's latest skills course - Professional Scrum Facilitation Skills. I experienced the course as a student and in doing the course, I really got an insight into facilitation and how important a skill it is for Scrum Masters and any Scrum team member to use to enhance their team's success and improve interaction. Facilitating the dynamics and interactions within these events is essential and one of the key take-aways for me from this course, was the five facilitation principles and how key they are towards guiding a group of people collectively to a shared objective.
5 Facilitation Principles for Scrum Events
1. Participatory - Scrum teams are self managing with a mix of skills and capabilities. Each Sprint they develop a Sprint Goal and have a shared responsibility to deliver an increment of customer value each and every sprint. This requires all the scrum team members to be involved in scrum events and have a say. People will by into a shared goal they have developed in preference to a goal that was forced upon them.
2. Healthy - Facilitation should create a safe space for people to be heard and have robust discussion. People should feel safe to raise conflicting perspectives and opinions. Therefore a facilitator should create a place for healthy discussion and expect that conflist may happen and build trust by remaining neutral in the conversation. Guide conversations to ensure tehy rmeian respectful and build a forum for learning and exploreing to come to a shared understanding.
3. Transparency - The emergent process and work must be visible to people performing the work and stakeholders who receive the work. This is because important decisions are based on the perceived state of the Sprint's increment. If there is low transparency, this can lead to decisions that diminish value and increase risk. Remeber that transparency isnt just about visibility, it is about creating shared understanding of the work and the outcomes.
4. Process - Facilitation helps participants to be guided towards the desired purpose for the Scrum event. Facilitation isn't about just doing fun ice breakers and team building activties. The technique choosen should clearly link to the objectvies for the event to be effective. To enact this process, facilitators will need to have a "toolkit" of approaches and techniques and use the appropriate one to meet the desired objective.
5. Purposeful - Each sprint event has a clear purpose that helps scrum team to iteratively show progress towards agreed the sprint goal. Having an increment of product to inspect and discuss at Sprint Review is critical to obtain feedback to help guide decisions for the next increment and what to adjust in the product backlog. Don't just focus on the format of the scrum event, as a fcailitator, think about how to drive the inetraction to achieve the intent and purpose of the event
All five principles work hand in hand to ensure that scrum events will be more focused, productive and effective. This requires a facilitator to plan for the facilitation to get the most out of the interaction of each event. Facilitation is a key skill to help your scrum teams become awesome and high performing.
to view the full article please visit my Zen Ex Machina blog
from Scrum.org Blog https://ift.tt/Mw2YC7R
0 Comments