Myths and Realities
-Myth: Self Management means that no managers are needed
-Reality: In organizations that are using Scrum well, the manager’s role switches aways from directing the team toward supporting the team. He/She make sure that the team have everything they need to be successful, such as equipment-budget-cooperation from personnel outside the team and keep the team focus by letting rest of the organization burn their time
-Myth: Each developer should have all the skill necessary to do every type of work during the Sprint.
-Reality: It’s true that maybe that could be the goal, but until the team reach that goal each member should help whoever asks or feel that his knowledge would be valuable. We are in an era where the technology increases so fast that humans cannot keep up any more.
Agile Leadership Style
• Act with great humility
• Create the conditions that support strong, empowered self-managing teams
• Foster empiricism by encouraging experimentation
• Keep the team’s focus on the value and customer outcomes
• Creates an environment of trust and transparency by modelling and reinforcing the Scrum Values
• Use techniques such as coaching, teaching, mentoring and facilitation
• Help teams transition to agility by letting go of old ways of working
Facilitation
Is the act of leading people on already agreed objectives in a way that support participation, ownership. Based on these two, then creativity can be engaged.
Next to Facilitation, transparency and collaboration will be born and hopefully can live inside the team.
The principles of facilitation are Participatory, Healthy, Transparency, Process and Purposeful.
Great facilitators have these skills:
Active Listening, Encouraging Curiosity, Problem Solving, Resolving Conflict, Using a Participative Style, Encouraging Openness, Empathizing and Showing Compassion, Demonstrating Leadership, Building Consensus, Managing Time Effectively, Setting Objectives, Communicating Adequately, Being Organized
When a facilitator lives with those (at least some) skills then one of the “fruits” of his action is that his DevOps colleagues are more open on the Retrospective event, which leads to actionable improvements.
How the Sprint retrospective should look in reality:
1) Briefly revisit with the the team the improvements identified & agreed in the last retro. Has the team addressed the improvements
2) If so, What was the impact? Are they still relevant? What to do about them?
Sources:
Professional Scrum Competency: Developing People and Teams | Scrum.org
Leave a Reply