The agile project management methodology “Scrum” is based on simple rules, defined project roles, and daily meetings. Gain insights into a client project.
Today, companies face a complex and rapidly changing business environment. Ongoing digitalization requires them to constantly react to new conditions and competitors and establish rapidly maturing business models. To meet these complex demands, there is an increasing reliance on agile project approaches.
We are convinced: No project without governance!
In the minds of many managers, agility is associated with the notion that everything runs autonomously: employees lead and organize themselves using Scrum, Kanban, or similar methods, and performance measurements and control are superfluous. While this may be partially true, we are confident that central governance and control remain essential. Why? Governance is about coordinating collaboration within the project team and continuously improving it. Leadership defines the binding framework within which team members operate. If this framework is not established, the team will experience uncertainties, coordination difficulties, and unnecessary additional work. The result is widespread dissatisfaction! Therefore, it is absolutely necessary to establish effective governance that provides the necessary orientation for project stakeholders. The benefits include:
- Clear Task and Role Assignments
- Autonomous Work
- Defined Framework Conditions
- Short Communication Channels
- Regular feedback loops
- The product vision as a jointly defined goal!
Agile, more agile, most agile: Scrum as a Project Management Methodology
The agile project management methodology "Scrum" is based on a few simple rules, three defined roles, and daily meetings. Scrum is an iterative process comprising several time-boxed sprints to achieve the project objective (e.g., product completion). Scrum originated in software development. However, it quickly became evident that this flexible and dynamic approach could also be beneficial for other project applications. At ISR, we also utilize Scrum in our client projects, as we are true #Scrumfans.
The Three Scrum Project Roles
The Product Owner (PO) plays a crucial role in Scrum and should not be confused with a traditional project manager. The PO represents the interests of external project stakeholders (e.g., clients, users) and involves key stakeholders without compromising their decision-making autonomy. Among their most important tasks is the creation of a product vision – essentially, the concept of the product or solution that the client wishes to advance to generate value for the end-user. Furthermore, they collaborate with stakeholders to define business requirements, which are then articulated as an initial product backlog. In coordination with the development team, work packages are subsequently defined and prioritized. Conclusion: The PO bears significant responsibility for the implementation and success of the project.
In contrast to the PO, the Scrum Master is responsible for the entire Scrum process. Their primary responsibilities include removing impediments, fostering effective team collaboration, and procuring necessary resources. Additionally, they serve as the competent point of contact for external parties and ensure adherence to all agile project management rules. Conclusion: The Scrum Master is tasked with ensuring the smooth operation of the development team and overseeing the sprint.
As the third and final Scrum role, the members of the Development Team (DEV Team) are essential, as the Scrum project would not be feasible without them. The Development Team performs operational activities based on individual competencies, organizes all tasks autonomously, and collaborates on an equal footing, as there are no hierarchies within the team.
Figure 1: The Central Role of the Product Owner
Five Steps to Success: The Sophisticated Scrum Process
Every project commences with a product vision. This overarching concept of the product defines the mandate to be addressed by the Scrum project. The product vision is then translated into story cards, which describe individual elements, functionalities, and features of the product. The subsequent Scrum process can be structured into five steps.
The Product Backlog is compiled from the gathered requirements of the PO and the story cards. This constitutes a collection of functionalities and features that the product is intended to possess.
During Sprint Planning, upcoming tasks are planned, and the sprint goal for the subsequent sprint is formulated. From this, the Scrum Team creates a Sprint Backlog.
The Daily Scrum involves a brief exchange among project team members, where each addresses the following questions: What have I accomplished since the last Daily Scrum? What do I need to do before the next Daily Scrum? What impediments exist?
Each sprint concludes with a Sprint Review meeting, where the project team presents the results to the PO. Considering the discussions held during the Sprint Review, the next sprint can commence with process step 2. This iterative process continues with subsequent sprints until the product is developed and the project is completed.
The Sprint Retrospective is a dedicated meeting where the sprint is discussed in plenum. Everyone can provide feedback on perceived collaboration, processes, and tools utilized. Learnings are documented and applied to subsequent sprints.
Figure 2: Scrum Framework
Project Example: ISR Frequently Applies Scrum in Client Projects
Enough theory! To illustrate how agile project managementWhat is project management? Project management encompasses all – often standardized – tasks,… More can be implemented in practice, let's examine a specific, albeit anonymized, example from one of our client projects where Scrum was utilized.
Theoretically, a PO and a Scrum Master are always required. In our project example, the client-side PO was absent. This presented no issue, as these responsibilities were simply assumed by the Scrum Master. The Scrum Master, in collaboration with the client's project team members and the DEV Team, gathered, aligned, and evaluated the requirements. Through the application of Definition of Ready (DoR), Definition of Done (DoD), and acceptance criteria, the requirements were refined to a point where they could ultimately be incorporated into a sprint.
The aforementioned steps were conducted in two meetings. In the first meeting, the Backlog Refinement Meeting, with the PO and the DEV team, the initial requirements were revised. The agenda items were:
- Compilation of the project team's functional and technical backgrounds
- Identification of dependencies
- Refinement of acceptance criteria
- Effort estimation by developers
In the second meeting, the Sprint Planning Meeting, with the PO, Scrum Master, and DEV team, the sprint goal was presented, and clarifying questions were addressed. Subsequently, the DEV team agreed on the scope of stories that could be processed within the sprint. This formed the Sprint Backlog.
Subsequently, the DEV team executed the stories planned for the sprint in 3-week sprints. During this period, developers exchanged information on work progress and upcoming tasks in the Daily Scrum Meeting.
Upon sprint completion, the customer was presented, during the Sprint Review Meeting, with how individual tickets – i.e., distinct tasks to be completed – were implemented. In our example project, this was demonstrated by a representative developer, but it could also be presented by the respective implementer. A crucial milestone in this meeting was the acceptance of the DoD by the PO.
In the final meeting, the Sprint Retrospective, the Scrum Master discussed with the DEV team and the PO what went well and what could potentially be optimized. Measures for improvement were documented and planned for upcoming sprints to facilitate continuous enhancement. Using this methodology, in the last sprint, in addition to new features, stories that improved system performance were also implemented. For the DEV team, we worked on a story for better structuring of release notes to further enhance the quality of deployments.
Are you interested in agile methodologies?
If you are now curious and also wish to implement your projects using agile methods, or if you have further questions – please do not hesitate to contact us; we look forward to engaging with you!
Angelina Jordan
Account & Marketing Manager
Business Process Automation
angelina.jordan@isr.de
+49(0)151 422 06 942
