Richard Hundhausen

The integration of Azure DevOps and Mural revolutionizes the visualization and management of Product Backlog items. Mural acts as a versatile front-end for Azure DevOps Services (as well as Jira), empowering Scrum Teams to forge interactive visual roadmaps and creatively handle work items using a variety of templates, such as the "Now, Next, Later" template. This combination enhances collaboration and facilitates strategic planning for both current and upcoming sprints. While the potential for visualization is vast, there are some notable limitations in the integration that merit further exploration.

The blog post suggests that Professional Scrum Product Owners should leverage Hypothesis-Driven Development (HDD) to make data-informed decisions, enhancing Scrum’s iterative nature. HDD is presented as a complementary practice that starts with a hypothesis which guides the Scrum Team's actions based on empirical evidence and user feedback, particularly for risky and/or expensive features. It also outlines steps for integrating HDD into Azure DevOps, advocating its use to ensure development aligns with business goals and user needs.

This post provides guidance for conducting a Nexus Sprint Review, a key component of the Nexus Scaled Scrum Framework (or any scaled Scrum implementation) aimed at enhancing inspection and adaptation for large-scale agile development. Dissatisfied with existing guidance, I decided to share my insights on how to structure these reviews to facilitate integrated feedback on the work done by the Nexus (the team of teams). It outlines the replacement of individual Scrum Team Sprint Reviews with a Nexus-wide review focusing on the integrated increment and suggests employing a "Sprint Review Bazaar" to cater to stakeholders' diverse interests through a diverge-converge approach. This method encourages detailed inspections and feedback in breakout rooms, analogous to visiting booths at a science fair or car show, thereby increasing transparency and engagement. The post also provides a detailed sample agenda for a 2.5-hour Nexus Sprint Review, emphasizing the importance of flexibility and adaptation during execution.

As a travelling Scrum and DevOps consultant I’m constantly asked “should our team use Scrum”? Now you might think that being a Professional Scrum Trainer – and serious Scrum fanboy – I would always answer “Yes!”. Well, you would be wrong. I frequently talk people out of Scrum – for the right reasons. Professional Scrum Trainers know how hard it is for a team to adopt and practice Scrum successfully. Therefore, we want to make sure the nature of the work is right for the Scrum framework. To that end, I’ve come up with five simple, mostly non-scientific, yes/no questions that I use to survey the inquisitor. My Five Questions Do you have at least three technical people to do the work? Are you developing a product/increment? (vs. just doing one-off/unrelated work) Is the majority of the work large enough to require a team? (vs. smaller, individual task-sized work) Is the majority of the work complex? (per the Stacey model) Is the majority of the work plannable? (vs. unplanned/support type of work) If the person answers “yes” to all 5 questions, then I’ll recommend they move forward with Scrum. If there are 3 or 4 “yes” answers, the Scrum framework will probably help the team yield results, but they may experience some friction and waste. If there are only 1 or 2 “yes” answers, the Scrum framework will be more overhead than helpful. It’s Not About Effort None of my questions include any culture, behavior, or type-of-industry questions. I don’t really care about their existing management structure, level of trust, technical debt, if they have remote team members, or whether they are a government agency or financial institution. Those attributes relate more to the level of effort required for Scrum adoption to become successful. The five questions are more about the nature of the work and less about the current level of dysfunction the team or organization is experiencing (or causing). Putting my consultant hat back on, the five questions tell me whether I should proceed with a Scrum training/coaching engagement or “fire the customer” before I get started. Follow-up questions about the culture, current behavior, and environment will tell me how much effort will be required. Incidentally, those are not simple yes/no questions, but an understanding that evolves over multiple in-person conversations and assessments. Conclusion My five questions are not weighted equally. For example, if someone answers “yes” to four questions, but answered “no” to having at least three technical people to do the work, then it may be a non-starter. Since opinions will vary on the weighting of these questions, I recommend using them purely as a guideline for your own questions or assessment.