Joanna Koprowicz
Introduction
An organisation managing a high-impact risk industrial plant faced significant challenges following several incidents, highlighting weaknesses in its investigation process. The leadership recognised the need to improve the investigation process to ensure a safer working environment and more effective incident prevention. To enhance the initiative’s success, the organisation adopted the Scrum framework, actively engaging stakeholders in developing and refining a new investigation process. Their involvement was crucial and valued.
Project Overview
The initiative aimed to create a robust and comprehensive investigation process by leveraging the expertise and perspectives of various stakeholders. Developed iteratively over five two-week
the process prioritized stakeholder engagement, feedback, and the incorporation of diverse perspectives. A cross-functional team consisted of both internal staff and external contractors. This team was responsible for reaching out to all impacted stakeholders to ensure the process captured a full spectrum of views and insights.
An Initiative Lead was accountable for the successful delivery of the project. Their role involved ensuring that the team remained focused, avoiding distractions from non-essential comments or inputs. The Initiative Lead prioritised the backlog of requirements, ensuring that meaningful outcomes were delivered within the 10-week timeframe.
Process Overview
The ideal process of decision-making involves scanning for information, understanding and interpreting it, predicting outcomes based on knowledge, planning accordingly, and acting on those plans. However, each step is vulnerable to specific mistakes influenced by contextual factors like cognitive biases, environmental complexity, time pressures, and resource limitations. Recognizing these vulnerabilities and the factors that contribute to them is crucial for improving decision-making and reducing the likelihood of failures.
Decision Making Process:
- SCAN: Absorbing information
- UNDERSTAND: Interpreting information
- PREDICT: Using information from past experiences in combination with existing knowledge
- PLAN: Plan the outcomes
- ACT: Act accordingly
Sprint Planning and Execution
Each sprint began with a planning session where the sprint goal was set. The goals varied but followed a structured approach:
- Sprint 1: Conduct workshops and interviews with various stakeholder groups to understand the current investigation process’s shortcomings and gather diverse perspectives.
- Sprint 2: Develop a draft of an improved process, including key questions to ask during investigations. Run additional workshops to gather collective feedback on this draft.
- Sprint 3: Based on the feedback, create a refined version of the investigation process. This version would then undergo further review and testing.
This iterative process continued until a final version of the investigation process was generated. The process was then set to be tested for three months before undergoing a final review.
*activity = user story
Stakeholder Communication and Involvement
After each Sprint Planning session, an email was sent to all stakeholders. These emails provided updates on progress, detailed the expected involvement from stakeholders in the upcoming sprint, and encouraged participation in the Sprint Reviews.
The Sprint Reviews, held at the end of each sprint, were critical touchpoints for stakeholder engagement. During these reviews, stakeholders provided feedback on the work completed, which sometimes led to heated discussions. These discussions were viewed positively as they signalled deep engagement and commitment from stakeholders. The Initiative Lead, who acted as the Product Owner, encouraged these discussions, emphasizing the importance of diverse perspectives in refining the process.
All feedback received during the Sprint Reviews was meticulously documented and analysed. Later, stakeholders were informed whether their feedback was incorporated or abandoned, and clear reasons were provided for any decisions to drop suggestions. This transparency was crucial in maintaining trust and ensuring continued engagement from all parties.
Managing Diverse Opinions and Concerns
Given the sensitive nature of the project, some stakeholders were more vocal in expressing their concerns and resistance. To address this, 1:1 sessions were scheduled during the sprints with these individuals. These sessions allowed the Initiative Lead to work closely with the concerned stakeholders, ensuring their voices were heard and helping to secure their buy-in by the end of the project.
This personalized approach to managing resistance was instrumental in overcoming potential roadblocks. By the project’s conclusion, even the most vocal critics had become advocates for the new process.
Voices from Our Team:
“The heated discussions during the Sprint Reviews were actually a sign that everyone cared deeply about the outcome. I appreciated the open environment where we could all voice our concerns and work through them constructively. Also, the 1:1 sessions were incredibly helpful. It was clear that the team was committed to addressing our concerns, and by the end of the project, I felt much more confident in the new process. The buy-in was well-earned.” |
Adapted Scrum Practices
Due to the part-time involvement of an external agency, the traditional Scrum practice of Daily Scrum was modified. Instead of daily meetings, Daily Scrum was scheduled only three times a week, with each session lasting 20 minutes. Despite this adjustment, the team maintained effective communication and collaboration, demonstrating that Scrum can be flexibly adapted to suit project needs.
Retrospectives with the external agency were also held at the end of each sprint. These sessions focused on improving the team’s collaboration and efficiency with each sprint, ensuring continuous improvement throughout the project.
Voices from Our Team:
“The support from leadership and the structure of the Scrum framework made this project stand out. Even with the modified Scrum practices, we were able to stay on track and deliver something we’re all proud of.” |
Definition of Ready (DoR) and Done (DoD)
To ensure clarity and avoid ambiguity, the Initiative Lead established a DoR and a DoD for the project. The DoR is a checklist that ensures an activity or task is well-prepared, clear and actionable. When an item meets the DoR the team has enough information to start work without major uncertainties or blockers.
For example, if a workshop was scheduled for a particular sprint, the DoR criteria required that the workshop be scheduled, attendance confirmed, and the venue booked and confirmed.
On the other hand, the DoD is a set of criteria that an activity or task must meet to be considered complete, ensuring that the final output meets quality standards and stakeholder expectations. The DoD criteria were similarly well-defined. Also, each activity included clear acceptance criteria laid out by the Initiative Lead. This approach ensured that all team members and stakeholders knew exactly what was expected and when a task could be considered complete. For example, acceptance criteria for the workshop included having at least two representatives from each operational area, with a minimum of five departments represented, all empowered to make decisions on behalf of their departments.
Volunteer Participation and Leadership Support
The project benefitted from the fact that all stakeholders involved were volunteers. This voluntary participation meant that those involved were genuinely interested in the project’s success, significantly increasing engagement levels.
Additionally, the project had strong support from leadership, which reinforced the importance of the initiative. Stakeholders understood that the process being developed was not just another bureaucratic exercise but a critical improvement with leadership backing.
This understanding ensured that everyone involved treated the process with the seriousness and dedication it deserved.
Results and Outcomes
The project resulted in the creation of a significantly improved investigation process. The final version of the process, refined through multiple iterations and extensive stakeholder input, was well-received by all involved. The process was then set to be tested for three months with a wider group of users, with a review scheduled at the end of the testing period to make any necessary further improvements before final sign-off.
The key outcomes of the project included:
>> Refined Investigation Process
The final process was the product of extensive collaboration and feedback, resulting in a robust and well-rounded investigation process that fully addressed the organization’s needs. Remarkably, this was all delivered within a relatively short timeframe.
Further Benefits Included:
>> Increased Stakeholder Engagement: The iterative approach, combined with regular communication and transparency, led to very high levels of stakeholder engagement. This engagement was critical in ensuring that the final process was both comprehensive and widely accepted.
>> Strong Buy-In and Support: The project secured strong buy-in from even the most resistant stakeholders through personalized 1:1 sessions and the active involvement of leadership.
>> Effective Use of Scrum: The project demonstrated the effectiveness of using Scrum in a non-software development context. By adapting Scrum practices to suit the project’s needs, the team leveraged the framework’s strengths in facilitating collaboration and iterative improvement.
Conclusion
This case study highlights how an organization successfully used Scrum to engage stakeholders in the development of a critical process improvement. By prioritizing communication, transparency, and adaptability, the project team was able to create a well-rounded investigation process with strong buy-in from all stakeholders. The project’s success underscores the importance of stakeholder engagement in driving meaningful and sustainable improvements.
Voices from Our Team:
“I was initially sceptical about whether Scrum was a suitable framework for running this project, but I was pleasantly surprised. I don’t think we would get a consensus and collaboratively agreed version of investigatory questions within 5 Sprints if we weren’t using Scrum.” |
