The case study was prepared in collaboration with Dragos Dobre from Swiss TPH.
Authors: Justyna Mihułka (SolDevelo), Damian Borowiecki (SolDevelo), Dragos Dobre (Swiss TPH).
Implementing Scrum Framework in a project is always a challenging process. When do we know that we’ve implemented the framework successfully? Is there any pattern we should follow? What are the key results indicating that we achieved the goal?
This case study will show you how we effectively implemented the Scrum Framework in a hybrid project, where team members are working remotely and are from different countries and cultures. We have cooperating colleagues from our SolDevelo’s office as well as from the client’s side – Swiss Tropical and Public Health Institute (Swiss TPH).
The open-source Insurance Management Information System (openIMIS) is a solution aimed at managing complex interactions of a health care system, including enrolling beneficiaries, processing claims, and calculating reimbursements for providers. It is globally managed by the openIMIS Initiative with the goal to continuously improve the software and implement it, especially in low- and middle-income countries, where the implementation of health financing schemes may be a great struggle.
In the collaboration work between SolDevelo and Swiss TPH, Swiss TPH plays the role of a Product Owner. As Swiss TPH implements openIMIS in LMIC, the client is represented by the stakeholder for whom the implementation is realized.
The decision about working in Scrum was made for two reasons:
1. Inside the team there was an idea and the drive to start working in more Agile mode.
2. We were applying for the new grant and one of the requirements was a team working in the Scrum Framework.
The team members were aware of general Agile methodology and they knew some basics of Scrum. However, there was room for improving the knowledge and starting to use it in practice.
In the next section we will present the different perspectives on using Scrum from key actors groups.
Scrum Master’s Perspective
The Scrum Master’s responsibility was to explain to the team the value of the Framework adoption, educate how to do it correctly, facilitate the process and coordinate elements of the Scrum such as events, artifacts and roles. The team had a dedicated experienced Scrum Master from SolDevelo who was engaged in the whole process of education, implementation, facilitation as well as in being the coach and the mentor.
We started from a series of workshops about the fundamentals of Scrum. The goal of this for the team was to understand the purpose of each element of the Scrum (events, roles, artifacts) and what value they may bring to the team, to the process, to the product, to the client and to the end users.
We focused on the roles in the Scrum Team, as we faced the challenge which is having two Product Owners dedicated to two parts of the system. What is more, the team is working remotely from different countries, such as Poland, Switzerland and Tanzania. We quickly realized that in order for the project to be successful each one of us needs to deeply understand and share the vision of the common goal.
For the next step, we decided what our workflow should look like and how long we want our Sprints to last (2 weeks). At the same time, we opened our first Sprint with the planning session. The most challenging for us was a two-hour timeboxed meeting during which we needed to listen to each other, focus on the Sprint Goal, decide what is our priority, which user stories we should put into the Sprint Backlog, and how developers may turn the items into the increment at the end of the Sprint.
Setting up all Scrum events (Daily Scrum, Sprint Planning, Sprint Review, Sprint Retrospective) was the second part of our implementation.
For our first planning sessions the crucial role was played by the Scrum Master who was facilitating the meetings, making sure that everyone is aware of their role: Product Owners are prepared for the planning with the idea of a specific Sprint Goal, the team is willing to discuss each Product Backlog Items (PBIs), estimate them and decide how to plan the work for the next two weeks.
What we found necessary just after a few Sprint Planning meetings was organizing the regular Product Backlog Refinement sessions to discuss each user story, an issue or a bug, decompose, describe them using the agreed Definition of Ready (DoR) template and estimate them so we can plan more effectively. Thanks to this, our planning meeting is now limited to a two-hour timebox.
Be the Coach and the Mentor for the Team
Scrum Master’s role is to help the team to be more effective and self-organized. The Scrum Master in our team needed to make sure that the team understands the product vision and the Sprint Goal. And that each element of Scrum is absorbed and brings value to the team, to the product, and to the customers.
The Scrum Master helped to implement each element of the Scrum Framework and coach the team on how to improve them. First of all, we agreed on the development workflow to be followed during a Sprint. Initially, the development workflow contained activities realized by external stakeholders from outside the Scrum Team, like the Quality Assurance, that was conflicting with the defined 2 weeks Sprint period. In addition to the workflow, we also agreed on the Definition of Done (DoD) that constrained the previous workflow.
Secondly, we started to track our basic metrics such as velocity, predictability, burndown chart, cycle time, defect trends. Thanks to this, we are now more aware of these metrics in the team and we know what should be improved with a high priority.
Moreover, we started working on team building by organizing workshops about intrinsic motivation based on Moving Motivators (Management 3.0). Such workshops may impact the team spirit, morale and cooperation.The team is now more aware of each other’s motivation and competencies.
After three months of working in Scrum, the Scrum Master conducted an audit on each of the implemented elements: roles, events and artifacts. The results helped us understand the current status of implementing the Scrum framework and provided us with recommendations about the future improvements.
How do we benefit from the Scrum?
From the perspective of the transparency of the ticket board and workflow, the introduction of Scrum was an opportunity to tackle the redesign of our Jira team space. The previously used kanban board, shared by many teams, without top-down rules defining naming and descriptions of the issues (DoR) and split into several project spaces, was problematic from the perspective of understanding what developers are currently doing and what the short-term plans for development work are. Hence, we worked out a better flow of information and more exchange in the tasks between team members.
The introduction of the framework helped to enhance the ticket lifecycle. Scrum was introduced at a time when most tasks were not strictly related to providing value, but rather to maintenance and bug fixes. From the beginning of the introduction of Sprints, certain aspects such as the long ‘In Testing’ (QA related) time impeded the closing of tasks within Sprints. However, we managed to fix this by changing the DoD and abstracting the UAT out of the team deliverables. Changing the process also gave us the opportunity to look at defining task descriptions and notice issues early on in the delivered specification from the client, resulting in better predictability and reduced rework time. This also helps in maintaining long-term goals, as clear Sprint Goals show the entire team the general direction of development.
It is hard to assess changes in productivity after the introduction of the framework. Prior to its implementation, the team was unlikely to have problems in delivering and working on tasks. On the other hand, the methodology has a positive effect on the predictability of work and therefore, on mid- and long-term planning. In exchange for better predictability, the time spent in meetings has increased significantly, which can have a negative impact on productivity, as meetings interrupt the work rhythm. However, the added value outweighs these downsides. In addition, encapsulating work in two-week Sprints allows additional metrics to be introduced to catch impediments or trends that can be improved. Previously, measuring metrics was much more complicated.
Improved communication and transparency
Even though the team already had daily update meetings prior to Scrum Framework application, the introduction of Scrum improved the communication between clients, Product Owners and developers. Product Backlog Refinement meetings improved the understanding of client’s real needs, thus reducing the back and forth discussions to explain eventual misunderstandings. Planning meetings allowed us to prioritize and concentrate on specific issues for the team to be able to deliver tangible results to clients. Review meetings allowed clients to actually see advancements on features, and easily evaluate and accept the results.
The openIMIS platform, that we are developing using the Scrum Framework, has many sides and components. On one side, there is the development of the platform covering multiple components, ranging from Web Applications to Mobile Applications. On the other side, there is the implementation of openIMIS in different country contexts. All this work represents multiple projects around the same software product. Scrum allows a more natural synchronization between developers and clients around all these projects. This is also true when work from one project needs to be compatible with the work from another project, and with the global openIMIS Initiative work in general.
Ready to release product
Our team is responsible for the maintenance, support and release of openIMIS product. Scrum Framework has goal-oriented Sprints that force the whole team to deliver features and fixes at the end of each Sprint. This makes openIMIS ready to be released easier than before. Moreover, all bugs discovered during release UAT are handled on time due to the Agile organization model that Scrum brings.
What will be the next step?
The Agile and Scrum approach will be continued within the team and the project. A lot of Scrum elements have become the routine for the team. So the focus in the nearest future will be on adopting Agile culture and values more than just implementing rules and tools. The team is mature enough to be aware of Agile values and to cooperate with the stakeholders and the clients in an Agile mindset. The project will be developing and in the near future we have a plan to increase the number of team members engaged in the openIMIS platform.
The end of the year is the perfect time for conclusions and wrap ups. Together with the team and the client we would like to repeat the Scrum Audit as well as Customer Satisfaction Survey. The results will hopefully inspire new improvements and changes in the process workflow.