I have this week certified as a Scrum master, after a two day course. And I will therefore like to share, some thoughts on, how I think Scrum can be implemented in SAP projects. I have no experience in project management except for at team level and being a participant in SAP projects.
Scrum is a framework designed for Agile projects. The article Scrum in 5 minutes, gives a pretty good understanding of the concepts. The basic idea is to make prototypes, add business value continues during the project and remove impediments.
The opposite of scrum is the waterfall method with separate phases for each task like specification, analysis, design, implementation, test and deployment. The waterfall model has some challenges.
- The business or customers does not have a complete idea of what they need before the see how a model works. This result in change requests along the way, which is more expensive the later in the process they are found.
- Features is requested that is never used a study published in xp2002 showed that 45% of features in software is never used.
- It become more difficult to change or correct something, in the later stages of the project
- During the test face everything has to work and then fixed and retested.
- Hand over between the different faces requires a lot of documentation, which can be difficult for other persons to understand or requires a lot of time on creating.
- The method assumes that we do not live in a complex environment, where changes does not occur.
- Often has overrun in time, price or bad quality.
I would say that ASAP is a clear waterfall method, with a analysis, implantation, test and go live face. ASAP contains some accelerators and templates to assists in the implantation. ASAP therefore contains most of the challenges stated above.
Scrum acknowledge that it is not possible to plan everything into the future and is therefore using 2-4 weeks iterations, which each have to result in a “workable” product. A large part of the framework is dealing with how to prioritize the most imports features from a business value perspective. The target is to create hyper productive teams, which produce more business value per resource.
A study done in Systematic , a CMMI5 company (so they must know what they are doing), showed that it was possible to halve the project cost and provide better quality than a waterfall implementation with Scrum.
Scrum can probably not save the world of projects. Like all other frameworks Scrum has some challenges, which can cause problems with the implementation.
- First of all organizations have to acknowledge they cannot plan feature the want in advance.
- Many organizations leave parts of the framework out; this will not result in a ScrumBUT with a lower productivity.
- The organization has to believe in the scrum approach and leave the groups alone in the sprints. If not it can result in lower production and a product which does not provide the correct business value.
- Other revenue models have to be created for consultancies, to adopt Scrum instead of a high paying waterfall approach.
I’m currently trying to figure out which parts of Scrum, we can use as an Integration Team in an implementation project. It will result in a ScrumBUT, but it will hopefully provide some experiences on how projects can be managed, from a micro level.
