We have finished our 6th wave of Internal Scrum Training – the last Internal Scrum Training this year 😉
As usually, we introduced few changes: run extra simulation on retrospective (Non-musical chairs), run Scrum Standup Sabotage game and soften constraints on Scrum Lego Game.
I must admit: it went differently and … we all had lots of fun! 🙂
Photos and videos are below.
Internal Scrum Training: Wave-05
On 28-SEP-2012 we have finished Wave-05 of Internal Scrum Training. Well, we call each group of students “a wave”. Why? We are sharing our knowledge and experience with them, and they are teaching us as well. Something like sea wave polishing rocks.
If you’ve read previous posts, you might wonder why are we still putting images and videos of repeating Scrum trainings? The answer is simple: while we’re improving our training and materials, each new wave is different. We are sharing the buzz and excitement (as well as lessons we’ve learnt from failures and pitfalls).
Some managers were wondered where is the practical value from internal Scrum Master training for their teams? While we explaining, demonstrating and involving people into theoretical and practical sides of being agile, we discovered that this is good, but apparently is not enough. Thus we decided to take extra commitment and share that commitment with participants: each student after each training day should write down personal commitment (Action Point) which will be oriented on specific experiment to be arranged in his/her team. That commitment is focused on acting towards validated learning while using empirical framework (Scrum).
Some people saying:
“You can bring a man to a well, but you cannot force him to drink from it”
“While you cannot force man to drink water from the well, but you can explain, show by example and put some water closer to his head”.
What we can do is to “Shrink the Change” and “Tweak the Environment” (see Switch for more)
We had good amount of discussions. Some of them were valuable. Some people complained that these discussion were flooding. Thus we came up with simple palm voting rule to let the group to self-manage such discussions. This started working in 1-2 days since self-organization rule was introduced.
Also we introduced personal commitment from students on actions after training with post-training proactive follow up from our side. This is commitment to start acting (not to actually delivering something). This is how we “shrinked the change”.
Special thanks to: new excellent business owner – Sophia! She was able to find us an awesome sheikh for the game! See yourself in Photos and Videos sections below!
And this is the first group which was able to build release plan and give us forecast regarding how many sprints it will take to build a Lego city.
Also we teach participants to calculate reliability of team commitment = (amount of completed stories ) / (amount of promised stories).
- Try “acceptance critieria” when demanding specific things from managers or service providers.
- Try creating/updating release plan after the 1st sprint
- Try diversify stories for the 1st sprint to gain more knowledge.
For example: take stories from different areas for the 1st sprint to attack uncertainty even if it does not go along with business priorities (you need that knowledge to build release plan). Building central park stories only will not help you to size Lego construction stories.
- Try specification by example and prototyping (whiteboard)
- If something is not visible then it doesn’t exist (e.g. invisible chance cards can be forgotten by coaches 🙂 )
- Avoid compromising the quality. Lowering quality standards leads to extreme degradation of product when team focused on value for the business.
- Try multi-team retrospective to address issues which bother your team but issue connected to other team(s).
- Try getting Product Vision from Product Owners or Business Owners on Sprint Review.
Very valuable feedback we’ve got from our participants:
You did not answer on all my specific questions. But now I know how to answer them by myself.
We emphasize during our training, that we cannot and will not give you a quick fix formula for your problems. We give you understanding, values and principles behind Scrum framework and Agile. It is your job to find right answers/your practices which match your context. “The best practices” are harmful, since you might assume that they are universally good regardless context (which is not true).
In recent post I shared our observations while running Scrum Lego Game as part of internal scrum training.
During next “wave” (each group of students receiving the training called ‘wave’ with corresponding number) of internal scrum training, we decided to improve the game by adding few changes.
These changes includes:
- chance cards (regular and trump card, regular card applies to team who draw the card, but trump card applies to all teams in the game :-))
- release burndown chart — business owner wants to know if teams are able to deliver entire Lego city (see how remaining work decreasing from sprint to sprint)
- value burnup chart — how much value produced each team in each iteration
Originally chance cards were designed to introduce certain uncertainty of real world to the game. Certain ‘management decisions‘ explained on a chance card (e.g. 50% of team should use only right hand, while other 50% should use only left hand) supposed to lead to velocity degradation, BUT reality surprised us! Continue reading
We played Scrum Lego Game with different teams.
Learning points: try Scrum ceremonies and practices in action during simulation while building Lego City.
In this post I decided to share our observations and insights.
Few words about the game. This is not competitive, but a collaborative game. Teams do not compete with each other, but has to collaboratively build a Lego City. Without collaboration both teams fail.
We experiment all the time and learning from our students:
There are tons of books describing who is a Product Manager and the majority outline the main responsibilities.
When I work with Product Manager we case-by-case decide who is NOT a Product Manager.
He/she is not and should not be:
1. a Scrum Master or Development Manager.
It’s a human nature to help people. If your team is experiencing difficulties – you want to help it by showing the problem, suggesting decisions. Continue reading