Simon Bourk

The story aims to showcase the transformative power of Agile and Scrum in leadership and team management within the tech industry. It's inspired by real-world scenarios where leaders face challenges in project management and team dynamics. The intent is to provide a relatable and inspiring narrative that underscores the value of specialized Scrum training. Key Highlights: James's journey from facing leadership challenges to embracing Agile training. The impact of the APS course with Minecraft in providing practical, hands-on experience in Scrum. James's growth, leading to improved team dynamics and project success at Innovatech (fictive company name)

Here are my observations made after teaching Scrum using Minecraft Education for approximately 3 years. Minecraft is used to create a world (metaverse?) in which students are asked to develop a product. The immersive nature of the platform replicates the workplace and invites students into reflection how are they approaching work as an individual and as a team.

Facing the COVID-19 pandemic, we are all staying home for the safety of our people. This is a hard time for all of us. While classes are re-scheduled in the Fall, some of us Scrum trainers are refocusing our energy to help the household while others are investigating how to conduct interactive online training.

I am learning awesome things that can relate to our world of “Agile” and “Product Ownership.”

I’m currently helping a small software shop within a government organization where multiple Scrum Teams are serving the same cause. They are building one product that has several sub-systems, which sometimes need to be integrated. Mostly, they have a low amount of dependencies between teams and systems. Today, the wind is slowly changing and the trend is “unity,” so the sub-systems need to be closely integrated. I suggested they use the Nexus Framework to help them manage their development. They decided to integrate the systems gradually, starting with two Scrum Teams and adding more teams as it goes. They have implemented the Nexus Daily Scrum. A few weeks prior to beginning development, the Dev Teams refined their dependent items. I knew there was some anxiety. At that point, they were conducting Nexus Daily Scrums, but felt that these daily meetings in addition to the Daily Scrums were overkill, because there were no dependencies between the sub-systems. So they decided to stop. They managed instead with offline ad-hoc conversations about upcoming “dependent” work. However, after a few Sprints, they selected the dependent items that needed to be developed and decided to reinstate the Nexus Daily Scrum and synchronize daily. The teams organized an ad-hoc pre-planning meeting which included a few members from each team. They wrote down the list of dependent items, and had a high level conversation about how they would integrate their work. After this discussion, they decided to postpone the release off by one week in order to allow for “recovery” and “stabilization.” Those two words made me twitch instantly. The habit of “stabilization period” is so frustrating! These are old habits left over from using waterfall and poor technical practices. What does it mean to be “done” at the end of a Sprint? Why do you need a stabilization period if you were “done?” What can you do to mitigate risks earlier, now? I went on for a little rant with the teams. I saw heads nodding, reasons were disclosed and it occurs to me that they were using a risk assessment practice that they used in the past. Anyhow, a potential topic for the next retrospective. The Sprint continued. Every day, at the Nexus Daily Scrum, most of the developers would start their turn by saying “there are no dependencies, can we go now?” and then, at last, someone would say “I will be doing this highly technical thing, how will I integrate with this other thing?” and the conversation would trigger everyone’s interest. The equivalent of the Nexus Sprint Backlog would be updated with new information and they would carry on. Even if the teams were not ready to plug and play their parts fully implemented, the Nexus Daily Scrum continues to be held everyday. It enables the team members to discover small experiments they can do before going too far into the development. Furthermore, although they haven’t been using the Nexus Framework fully as describe in the Nexus Guide, they created the equivalent of the Nexus Sprint Planning and created a Nexus Sprint Backlog for tracking their dependencies. I cannot wait to see what they will come up for the Nexus Sprint Review and for the Nexus Sprint Retrospective! Cheers, Simon From the Nexus Guide, you can read: Nexus Daily Scrum The Nexus Daily Scrum is an event for appropriate representatives from individual Scrum Development Teams to inspect the current state of the Integrated Increment and to identify integration issues or newly discovered cross-team dependencies. During the Nexus Daily Scrum, attendees should focus on each team’s impact on the Integrated Increment and discuss: ● Was the previous day’s work successfully integrated? If not, why not? ● What new dependencies have been identified? ● What information needs to be shared across teams in the Nexus? During the Nexus Daily Scrum, the Nexus Sprint Backlog should be used to visualize and manage current dependencies. Work that is identified during the Nexus Daily Scrum is then taken back to individual Scrum Teams for planning inside their Daily Scrum events.