The FSDM2OneSumX Adapter is a standard product from ADWEKO that enables data integration between SAP Financial Services Data Management (FSDM) and OneSumX from Wolters Kluwer. When we started setting up product development, we established classic project management and worked according to the waterfall model. At first we planned, discussed and designed a lot. Only afterwards did we continue with development and later with testing. Over time, we realized that this approach was not optimal for our adapter development because we could not achieve quick wins and felt we were progressing more slowly. After a lengthy analysis of the pros and cons, we decided on an agile approach, in particular agile development of the adapter.
In the following, we will explain which best practices we have developed and what the Scrum benefits are using our standard product development as an example
short and productive sprints
one of the most important features of the Scrum methodology is the time-based division of work phases into sprints. Typically, a sprint spans one to four weeks. It begins with Sprint Planning, in which the specific tasks – User Stories for the Sprint – are planned. The end of the sprint marks a review of the results achieved and a retrospective in which the positive and negative incidents of the sprint are discussed and measures are taken to increase efficiency and improve the way of working.
In our development project, we set a sprint length of three weeks. This period is optimally adapted to our needs. On the one hand, we can divide more complex topics into several blocks to ensure that the processing of each task can be completed. On the other hand, clearly plannable target results can be determined from the respective iterations.
In each sprint we can do parallel work – business analysis, test design and development. This way, we can ensure that we make overall project progress and work on all fronts. Experience has shown that a different focus can be placed in each sprint – for example, we have been concentrating more on business analysis in recent months. Due to the dependencies between the individual topics (conception, testing and development), it has proven to be best practice for us that the business analysis takes place in one sprint and the development and testing in the following one. This way, there is enough buffer for any conceptual adjustments before moving into development to avoid future code corrections that arise after new business analysis insights.
Constant team exchange
The dailies we have as part of our sprints are a great way for each team member to present the successfully completed tasks from the previous day and the current issues to be worked on. On the one hand, everyone gets a chance to speak, and on the other hand, you only concentrate on the essentials, due to the time limit of the dailies – in our case, 15 minutes. A brief exchange ensures transparency within the team, and a downstream in-depth discussion of any topics and problems can be conducted with the respective experts afterwards, which has proven to be clearly efficient.
With constant status updates from individual team members, everyone on the project knows where we stand and who is currently working on which topic. This allows for a quick exchange of know-how, because anyone interested in a particular topic can find out about it directly afterwards. In addition, in the review, all edited user stories are presented to the whole team, which helps to ensure that everyone has the same level of information and solid knowledge about all project topics.
The daily exchange makes it possible to react faster and to reschedule if we realize that the current topic is no longer so important or takes much more time than originally expected. This flexibility and adaptability is important when you have an intensive development plan and want to achieve results quickly.
Continuous improvement of processes
An important goal of Scrum is continuous improvement and increased efficiency. This is primarily addressed during the regular retrospective meetings at the end of each sprint. By constantly reviewing the approach and questioning the way we work, we try to consistently derive improvement measures and immediately incorporate them into the next sprint. For example, this meant that our project documentation and familiarization processes were scrutinized with each subsequent review process and adjusted and optimized accordingly. Through this recurring process, each team member is always required to actively participate in team design and task management, description and distribution. Compared to waterfall project management, the Scrum methodology involves everyone working continuously to work better and more results-oriented, which makes for a better team feeling.
Jira as an overview source for the project progress
Scrum does not specify which tool is used to manage the Product Backlog. Our project has chosen Jira. For us, this is the central place where current and completed user stories, as well as future topics, are made visible to everyone. Managing the backlog and topics for the current sprint provides an overview of the sprint progress. In addition, a concrete overview is possible in Jira of who is currently working on which tasks, what the effort estimate is for the user stories, and what the acceptance criteria are for the corresponding task to be completed successfully. Based on Jira, you can set up different reportings to better analyze the project progress.
Scrum is an established method to enable successful project management, especially in product development. Our experience has shown that the Scrum rules (artifacts, events and roles) enable us to react immediately to changes, to optimize our working time, to produce results faster and to achieve our planned goals.
Galina Engelhardt is Manager Managed Services at ADWEKO and has 10 years of experience in the financial services sector. Her main focus is on business analysis, conception and design of interfaces, requirements management, as well as coordination and management of teams.