This article was originally posted on scrum.org

https://scrumorg-website-prod.s3.amazonaws.com/drupal/2021-04/Pentacomp2021%20%282%29%20%281%29.pdf

The Challenge

Pentacomp has been working with its client, The Ministry of Health in Poland, on developing several software products including an e-prescription platform they refer to as e-health. The Ministry of Health had been working on these products for a decade and they needed a new solution to help them deliver their complex systems.

The Ministry of Health tested different approaches for the development of e-health and decided Scrum was the best fit for them and initially worked with 5 separate Scrum Teams. As subsequent orders came from the client, 2 other teams were also added, one of which was from a second supplier, making a total of 7 Scrum Teams, and again they added another 2 teams, totalling nearly 100 Developers across 9 Scrum Teams to support the growing e-health system.

As the e-health system grew, so did the number of capabilities, components, and assemblies creating increased complexity and dependencies. Integration was becoming very difficult with their ever-growing scope of work. The teams struggled with communication and transparency issues among the Developers.

The Solution

To address these issues, Pentacomp decided to implement the Nexus framework for the e-health initiative. They tested several other approaches before choosing Nexus but ultimately found that Nexus was the best fit. The Ministry of Health was very involved in the decision to use Nexus to scale Scrum and found it to be the most suitable for their teams since they were already using Scrum.

Scaling Beyond Nexus to Nexus+

A major challenge they faced a few months into using Nexus, was that they found the teams to be misaligned, which created challenges when ordering their Product Backlog revealing that the teams in the Nexus were working on separate workstreams. They decided to separate into 2 separate streams of work. Each stream became a Nexus, and together this became what is known as a Nexus +, multiple Nexuses working together representing a product family for the Ministry of Health. The first stream was for software focused on their core domain: Patient Online Account and Prescription e-services. These products included e-referrals, cross-border prescription, mobile e-patient, and Covid-19 vaccine record capabilities. The second stream implemented health information exchange, including electronic medical documentation and medical encounters. There was still some integration needed between the 2 Nexuses in order to provide a consistent experience for patients. As the teams were evolving, they worked to be consistent in their use of Scrum, principles, values and culture, collaborative product mindset and agility, while increasing effectiveness. Each Nexus was considered a separate product, so they introduced another Product Owner, yielding one for each Nexus. Therefore, within the Nexus+ there were 2 Nexuses (one for each workstream or product). Each workstream had its own Product Backlog and Product Owner.

Initially, as a Nexus+, each Nexus held separate Nexus Sprint Planning sessions, Nexus Sprint Retrospectives, Nexus Daily Scrums and Cross-Team Refinement sessions. They had common Definitions of Done and kept the same design principles across Nexuses. They also had one common Nexus+ Sprint Review.

After several Sprints, they realized that holding individual Nexus Sprint Events were masking the interdependencies between the two Nexuses. Therefore, they adapted to have one common Nexus+ Sprint Planning session, defining the common direction of work in both areas, relationships, dependencies and long-term plans. They also began having one Nexus+ Retrospective and one Nexus+ Daily Scrum for both Nexuses together. They kept two separate Product Owners treating each Nexus as its own product and held a Nexus+ Cross-Team Refinement session in addition to Cross-Team Refinement sessions in the individual Nexuses. There was a rigorous focus on consistent communication toward integration,
eliminating waste, resolving inconsistencies, Product Goals, and customer value.

In addition to synchronizing events at the Nexus+ level, the teams also applied other practices to help address their challenges with transparency and alignments:

• Ensure a clear Definition of Done for all Product Backlog Items
• Develop rules and standards (gitflow, creating an analysis, test pyramid, rules for creating documentation, etc.)
• Synchronize on a regular basis between Product Ownership and the client
• Use a Nexus+ Daily Scrum to emerge dependencies between the Nexuses
• Maintain a 15% threshold each Sprint dedicated to manage technical debt as needed
• Conduct a “Big Retro”: once every few months after major production releases with Scrum Teams and the client in attendance during a meeting lasting several hours. Clients participated in these Retrospectives and interacted directly with the Scrum Teams, which was very helpful and motivating.

The Results

Once the Nexuses were already working, the Covid-19 pandemic came to be. They were unsure how the Nexuses were going to work remotely, but it worked well and more importantly, their products became more critical than ever. Patients were easily able to get their prescriptions without going to a doctor’s office thanks to theire-health product. The system they built helped save the Polish healthcare system from a collapse. They received many accolades from the Ministry of Health because of this. (https://pacjent.gov.pl/e-recepta/porady-lekarskie-i-e-recepty)

Prior to Nexus, the Ministry of Health released less frequently:

“ In 2018 we had 5 releases, in 2019 we had 3, in 2020 we had 6. In January 2021 (when this case study was being written) we have already had 4 releases”, said Hanna Ochmańska, Scrum Master.

Their cycle times also continue to shorten currently average at 11 days. They are currently working on e-appointment and teleconsultation modules and expect them to be completed in 2021. Due to the growing range of functionalities, they have expanded the composition of the project with another team in connection with subsequent customer orders, and currently work in 9 teams.

The Company

Pentacomp designs innovative IT solutions, maintains and services IT systems, and provides consultancy for companies in various industries. By carrying out strategic projects, the Pentacomp team has been supporting the largest organizations and firms in achieving success and gaining a market advantage for 25 years. This case study talks about its work with the Ministry of Health in Poland.

About Scrum.org

Scrum.org, the Home of Scrum, was founded by Scrum co-creator Ken Schwaber as a mission-based organization to help people and teams solve complex problems. We do this by enabling people to apply Professional Scrum through hands-on training courses, globally recognized certifications and ongoing learning all based on a common competency model.

Scrum.org supports people wherever they are on their learning journey from beginner to highly experienced practitioner, helping them to grow over time with ongoing learning opportunities and resources. Community members share knowledge and gain new insights from each other leveraging forums, blogs and more.