Games for new RTE's (Release Train Engineers)
89 views
Skip to first unread message
kristy...@gmail.com
Dec 2, 2020, 3:04:48 AM12/2/20
to AgileGames
Hi everyone,
Just wondering if anyone has any good games to help new RTE's understand their role in a scaled agile environment.... or know of any games that will convert well to RTE's participating/learning from it?
Appreciate your assistance.
Below are my introduction question responses - as I have not actively engaged here before:
1. My name is Kristy
2. Scrum simulation game
3. Played when I first officially became a scrum master - 2017
4. I have been a Scrum Master, Product Owner & now agile coach (new)
Appreciate your input and advice!
Kristy
Pierre Neis
Dec 2, 2020, 4:26:49 AM12/2/20
to AgileGames
Just look after games for scrum masters an agile coaches. A RTE is nothing more than another kind of scrum master.
Author of The New Normal : AO concepts and patterns of 21-st century agile organizations. Buy here |
--
You received this message because you are subscribed to the Google Groups "AgileGames" group.
To unsubscribe from this group and stop receiving emails from it, send an email to agilegames+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/agilegames/055d42e9-736f-4454-be2b-fb47b59f8ac8n%40googlegroups.com.
Andy Nguyen
Dec 2, 2020, 10:53:39 AM12/2/20
to agile...@googlegroups.com
Hello Kristy,
I’ve got two games for RTE. The first one, the one I designed is more
purposeful and the other one, I participated, but was in beta mode.
I intend to make the RTE understand the notion of alignment in 3
sprints. The first one is the planning, where he interacts with other
stakeholders: project managers, product owners, dev managers
(maintenance teams) and external remote teams where none of them agree
in synching. They all have cards with specific excuses and valid
reasons.
Then we debrief. Obviously, we have to find some sort of alignment.
Does it mean it would have to be escalated higher to get priorities
understood?
In the second iteration, we might agree on initiatives, but you have
misalignment on implementation. One team uses dates, another has a
milestone to deliver, another team has 3-weeks sprints.
Then we debrief.
In the third iteration, we align in sprints but they have changing
priorities and initiatives. Their manager or directors changed at
sprint 2. Sure the teams agreed initially, but then, customers are
always right.
Then we debrief. It shows that managers and directors cannot just be
aligned, but committed.
Scenarios are specific to our organisation, so it cannot be shared.
But you simply need one RTE (same or rotated) and other stakeholders
with a role, and a scripted scenario to answer. The RTE, knows the
roles and is time limited to have a form of consensus at each
iteration.
The second gate is more PI Planning focused. The beta version was
awful because they added the math notion and participants – including
me – were confused on what number to add to which step. It starts with
a role (assigned 1), so he opens card 1. As we read the scenario, the
RTE makes choices and choice A is 2, and choice B is 4. Choice A, adds
to card 3, and on and on. Sometimes, in the card’s scenario, the BO is
required, so take that role and add to the choice.
Scenarios can be:
1. Is a prioritisation required?
2. A story requires someone else in some other team, should he be
consulted or we simply estimate the story?
3. Should the information provided be considered a risk? Or can the
team handle it?
4. Can this enabler be estimated right now?
5. Should this huge dependency be in a Scrum of Scrum?
In the age of Mural and Miro, simply flipping cards without doing math
is fine. Flipping some cards can lead to a dead end, ie, a bad
decision. But mapping the cards in a mind map, and flipping cards over
and over is fine.
And I did not want a copy of this game because the notions of the
decisions above shouldn’t be gamified. It makes the PI Planning
frivolous.
I’ve got two games for RTE. The first one, the one I designed is more
purposeful and the other one, I participated, but was in beta mode.
I intend to make the RTE understand the notion of alignment in 3
sprints. The first one is the planning, where he interacts with other
stakeholders: project managers, product owners, dev managers
(maintenance teams) and external remote teams where none of them agree
in synching. They all have cards with specific excuses and valid
reasons.
Then we debrief. Obviously, we have to find some sort of alignment.
Does it mean it would have to be escalated higher to get priorities
understood?
In the second iteration, we might agree on initiatives, but you have
misalignment on implementation. One team uses dates, another has a
milestone to deliver, another team has 3-weeks sprints.
Then we debrief.
In the third iteration, we align in sprints but they have changing
priorities and initiatives. Their manager or directors changed at
sprint 2. Sure the teams agreed initially, but then, customers are
always right.
Then we debrief. It shows that managers and directors cannot just be
aligned, but committed.
Scenarios are specific to our organisation, so it cannot be shared.
But you simply need one RTE (same or rotated) and other stakeholders
with a role, and a scripted scenario to answer. The RTE, knows the
roles and is time limited to have a form of consensus at each
iteration.
The second gate is more PI Planning focused. The beta version was
awful because they added the math notion and participants – including
me – were confused on what number to add to which step. It starts with
a role (assigned 1), so he opens card 1. As we read the scenario, the
RTE makes choices and choice A is 2, and choice B is 4. Choice A, adds
to card 3, and on and on. Sometimes, in the card’s scenario, the BO is
required, so take that role and add to the choice.
Scenarios can be:
1. Is a prioritisation required?
2. A story requires someone else in some other team, should he be
consulted or we simply estimate the story?
3. Should the information provided be considered a risk? Or can the
team handle it?
4. Can this enabler be estimated right now?
5. Should this huge dependency be in a Scrum of Scrum?
In the age of Mural and Miro, simply flipping cards without doing math
is fine. Flipping some cards can lead to a dead end, ie, a bad
decision. But mapping the cards in a mind map, and flipping cards over
and over is fine.
And I did not want a copy of this game because the notions of the
decisions above shouldn’t be gamified. It makes the PI Planning
frivolous.
Reply all
Reply to author
Forward
0 new messages