Simon Bourk

In this reflective blog post, I explore the evolution of Scrum and Agile over the past two decades, highlighting key milestones and shifts in how these frameworks have been adopted. I discuss the current state of Agile, addressing ongoing challenges and the strong community support that persists. Looking ahead, I consider the future of Scrum, emphasizing the importance of transcending past practices while integrating new technologies and cultural shifts. I also highlight the innovative work of my colleagues in helping organizations better assess their current state to make informed decisions.

This story highlights the importance of using complementary metrics to ensure you're not just focused on speed, but also on delivering real value to your customers.

This blog explores how Scrum can solve ten common challenges that teams face, enhancing productivity and satisfaction both within teams and among stakeholders. Through its structure, Scrum addresses issues like unclear priorities, changing requirements, and ineffective communication by promoting regular feedback loops and continuous improvement practices. It also tackles productivity issues and prevents overwork through its emphasis on self-management and shared responsibilities. By encouraging regular stakeholder engagement and maintaining a focus on high-quality deliverables, Scrum ensures that products meet customer expectations and that teams work in a sustainable, balanced manner. This makes Scrum an invaluable framework for any team looking to improve their product development outcomes and work dynamics.

To transcend Mechanical Scrum, it's crucial for the Agile community to re-emphasize the importance of the Scrum Values, encourage adaptable practices, and foster environments that prioritize continuous improvement, team autonomy, and value creation. Success stories from those who have shifted from mechanical to empirical Scrum practices offer valuable insights and inspiration. As we move forward, leveraging resources and training to deepen our understanding and application of Scrum will be key to overcoming these challenges. The goal is to not just follow Scrum by the book but to live its principles, ensuring teams are truly agile, responsive, and focused on delivering value.

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.