Agile method for the introduction of software systems
Agile Manifesto
Assuming that the result of a complex project can be accurately described in advance has proven to be simply wrong over all these years of implementation. Therefore, even today many projects aimed at introducing complex systems such as PIM, MDM or GDSN fail.
Because of this, agile methods for implementing software systems have been increasingly established for years.
Agile implementation of a software system is beneficial in that business and technology work closely together, results can be delivered quickly at a fixed rhythm and tested by businesses, allowing project planning to be adjusted and readjusted at any time.
Our consultants are not only skilled in apllying agile methods, but they also have many years of experience in implementing agile principles:
Agile method for the introduction of software systems
Assuming that the result of a complex project can be accurately described in advance has proven to be simply wrong over all these years of implementation. Therefore, even today many projects aimed at introducing complex systems such as PIM, MDM or GDSN fail.
Because of this, agile methods for implementing software systems have been increasingly established for years.
Agile implementation of a software system is beneficial in that business and technology work closely together, results can be delivered quickly at a fixed rhythm and tested by businesses, allowing project planning to be adjusted and readjusted at any time.
Our consultants are not only skilled in apllying agile methods, but they also have many years of experience in implementing agile principles:
Agile Manifesto
User Story Map – the big picture
An agile approach does not mean unplanned action. It is just the other way around.
To keep the big picture in mind, we use the 'User Story Map' in our projects.
It describes how users are supposed to interact with the system ('User Activities') and which tasks ('User Tasks') users have to perform. 'User Stories' then describe how they are going to execute these tasks and these “User Stories” are then assigned to relevant the system releases.
For development, the 'user stories' are broken down into developer tasks, included in the so-called 'backlog' and the implementation is planned in sprints as part of the SCRUM development process favored by us.
User Story Map – the big picture
An agile approach does not mean unplanned action. It is just the other way around.
To keep the big picture in mind, we use the 'User Story Map' in our projects.
It describes how users are supposed to interact with the system ('User Activities') and which tasks ('User Tasks') users have to perform. 'User Stories' then describe how they are going to execute these tasks and these “User Stories” are then assigned to relevant the system releases.
For development, the 'user stories' are broken down into developer tasks, included in the so-called 'backlog' and the implementation is planned in sprints as part of the SCRUM development process favored by us.
SCRUM – Sprint by Sprint to success
All development tasks or requirements that are known at any point in time are recorded in the product backlog.
In a 'Sprint-Planning', which usually takes place every two weeks, the Product Owner prioritizes requirements for the next Sprint and plans them in cooperation with the development team.
Sprint planning clarifies prioritized requirements and estimates the implementation effort.
During Sprint, there is a daily 'Daily Scrum' in which Product Owner and developer team discuss possible questions and problems and jointly look for possible solutions. At the end of the 2-week Sprint there is a 'Sprint Review Meeting'. In this meeting, the developer team reports their results, and the product owner accepts the product increment.
In the following 'Sprint Retrospective', the whole team reflects on which aspects of Sprint worked well and which aspects could be improved.
SCRUM – Sprint für Sprint zum Erfolg
All development tasks or requirements that are known at any point in time are recorded in the product backlog.
In a 'Sprint-Planning', which usually takes place every two weeks, the Product Owner prioritizes requirements for the next Sprint and plans them in cooperation with the development team.
Sprint planning clarifies prioritized requirements and estimates the implementation effort.
During Sprint, there is a daily 'Daily Scrum' in which Product Owner and developer team discuss possible questions and problems and jointly look for possible solutions. At the end of the 2-week Sprint there is a 'Sprint Review Meeting'. In this meeting, the developer team reports their results, and the product owner accepts the product increment.
In the following 'Sprint Retrospective', the whole team reflects on which aspects of Sprint worked well and which aspects could be improved.
Benefit from our experience
Contact us – no matter which project phase you currently find yourself in. We are happy to support you with our experience.