Role-Playing – Seeing is believing
When teams are On-boarded on Agile Projects , members are trained on the Scrum framework including Agile Manifesto, Principles, Ceremonies, Scrum Values, Roles and Responsibilities.
In addition to the Scrum framework , Mindsets and behaviors also play major role in the success of scrum teams and programs.
While awareness is created on Scrum Values and Growth mindsets, each individual has a unique way of interpreting a scenario and responding to the situation. In several situations members in the Scrum Teams/Product Owners/Scrum Masters/Other Stakeholders expect a near perfect( Text book) behavior from the other, while there could be several challenges for each individual especially in the different phases of transformation.
“I hear and I forget. I see and I remember. I do and I understand” is a famous saying by Confucius.
“A role-playing game is a game in which the participants assume the roles of characters and collaboratively create stories. Participants determine the actions of their characters based on their characterisation, and the actions succeed or fail according to a formal system of rules and guidelines. Within the rules, they may improvise freely; their choices shape the direction and outcome of the games.”
Role-playing is a powerful tool that we have been able to successfully use as a self-introspection coaching tool in our Agile Transformations to bring out the behaviors in different scenarios, and let the participants experience the challenges.
In this experience report, we will discuss on the scenario’s noticed on the ground from the Scrum teams for the Role Plays and how the team members and various stake-holders have benefited from the same.
A few of these scenarios are as mentioned below :
- PO’s influencing the estimation of teams due to their past experience with the product.
- Scrum Masters continuing to command and control the team.
- External stakeholders expecting Scrum Masters to be a Project Manager.
- Individual glory over one team approach.
- Senior members/Architects unwilling to collaborate in the team due to their past way of working.
- Collaborative Inter-team dependency resolution.
- Challenges of distributed teams not being considered.
The benefits that role play provided us :
- Acts as a introspection tool for the teams/individuals part of the Role Play and also for observers.
- Builds confidence for individuals to take up the roles.
- Creates an environment for problem solving.
- Empathy towards individuals.
During the presentation session, a short Role Play is planned.
Let us play the game – bring out the actor in us, have fun and share !!
Outline/structure of the Session
- 4 minutes - Introduction to Role Playing, Scenario and on the spot auditions.
- 6 minutes – Role Play of one scenario by the talented participants selected through auditions.
- 4 minutes - Debrief and sharing by the participants.
- 6 minutes – Sharing of our experience report and the benefits achieved.
Role Plays as a tool to emphasize on desired behaviour in Scrum teams, in addition to better understanding of the Scrum framework.
Anyone embarking on their Agile Journey
schedule Submitted 2 years ago
People who liked this proposal, also liked:
Vijay Kulkarni - Mind shift for End-user documentation in Agile MethodologyVijay KulkarniManager Information DevelopmentUnisys India
schedule 2 years agoSold Out!
After a successful release, the product manager feels extremely happy that the team met the commitments and delivered the software on time. However, when he probes the actual users for the feedback, the first reaction is “documentation sucks”. Why does this happen? Most of the developers and testers still follow the traditional approach of involving documentation folks towards the end of the release! This is paradoxical because when you have development and testing happening in agile approach how can you have documentation in traditional approach?
This session deals with the mindshift change that the entire value chain needs to make end-user documentation a critical part of the scrum team deliverables and bring it on equal pedestal as any other deliverable.
It emphasizes that technical writers should not feel marginalized with the fast paced development, testing, and delivery cycles. Instead, they must work very closely with the developers and testers because they no longer require to sit outside the room and walk in only after the bell rings! And the developers, testers, product owners should not consider documentation folks as the last leg of the product delivery cycle. They must all work as an integrated team, start-to-finish.