Some days ago I had the opportunity to take part at talk by Christian Schmidkonz from SAP. He is an expert in agile methods and introduced Scrum@SAP. Scrum is an agile project management method for IT projects. If you are not familiar with it I suggest to read an introduction first.
So what is the main difference between classical and agile methods? I think these are some core values and beliefs: In classical project management believes we can plan each activity of a projects in a long range. Let me give you an example of such a plan: "34 weeks in the future developer Sandra will have finished a certain piece of code. Now developer Peter can use this code to solve task B. At this time Sandra starts to help Hans with task C. Both will complete this work 36 weeks in the future so that Sandra, Peter and Hans can start in 38 week to solve task D together."
If course everybody knows that we can't plan this way because it's hard to give predictions - especially about the future. What happens if 25 weeks in the future a certain requirement changes so that task B is obsolete? What happens if in week 35 Peter get's ill or is on holiday or the management decides that Peter has to prepare a demonstration for customers? And what will happen if task D becomes obsolete because it turns out that there was a serious design error and extensive changes to the software are necessary? We all know what happens in this case: We need reporting to detect risks and problems and spend a lot of time writing reports. We use reporting to find solutions for smaller problems. But at a certain point in time there are so much problems that the whole project has to be re-planned which takes lot of time. If you know exactly what to do you may be successful with the classical approach, but if there are uncertainties you should ask yourself whether the agile approach is better.
It's the core belief of agile project methods that reporting is the wrong approach to detect problems. We need working code that can be tested to detect performance problems for example. Another believe is that we can't predict the future. We have to develop use case with high business value first, after 4 weeks we test them, detect problems and plan the activities for the next 4 weeks. So planning and testing must be permanent companions: At the begin of each development phase (called "sprint") we plan the sprint and then we test the software.
This sounds reasonable. But even after reading an introduction of a book by Ken Schwaber a lot of questions remain that can only be answered by an expert like Christian Schmidkonz. Here are some of my notes of the talk. I hope that thorsten.franz3/blog will add hist nore in a second part.
Scrum means Transparency
Scrum means to develop software in incremental way. At the beginning of each "sprint" the goals of the sprint is defined. At the end there is always a demo so the project owner can control the progress of development. At the end of each sprint we have a working system that can be tested.
Scrum helps to Focus on Business value and Working Software
The project owner defines a list of use cases and has to define priority for each one. Within each sprint a certain number of use cases have to be developed. The use cases (or requirements) have to be understood by the team and there have to be testable.
From these use case the team defines a task list and estimates each task. During the development phase the remaining effort has to been checked constantly. The goal is to produce working code and to code a complete use cases
If after a certain time the project is short of time the most important use cases have beep developed. After each sprint we have a working software and can detect problems (think of performance issues) very early and we can find a way how to deal with them.
Scrum doesn't mean Chaos - it has strict Rules
Some people think that some Scrum means chaos: „The developers and architects stop creating documentation". This is not true. In Scrum projects there is a very pragmatic attitude towards specification. And if concise documentation is part of the requirement then it will be done. Most agile methods have very strict rules - so often they need more discipline than classical methods.
In fact the success of Scrum comes from the mixture of its ingredients: iterative development, retrospectives, early tests and so on are nothing new but the right mixture seems to be the key to success.
Scrum supports Self Organization of the Team
Scrum focuses on transparency. After each sprint the project owner can check the product. But he has no influence how the development is done. In fact the team has all necessary skills for developing the product: there may be architects, quality experts, testers, middleware experts within the team. If there are problems within the team or the team doesn't have the necessary skills it's the task of the Scrum Master to find a solution.
Agility doesn't mean that the Product Owner can constantly change the Requirements
If requirements change from day to day then this a serious problem for any software development project. And I don't think a classical "waterfall" approach will work under these conditions because the waterfall-approach depends on specifications that are stable for a time that is much longer the time of a sprint. With Scrum changing requirements will become transparent because at the begin of each sprint the product owner tells the team his requirements und product owner and development team try to find a commitment. As a consequence Scrum allows to deal with changing requirements but makes the costs of changes transparent.
Scrum is no Silver Bullet
Scrum is no general problem solver. Developers won't double their efficiency if they work at a Scrum project. But Scrum does a retrospective at the end of each sprint so that the team can learn and increase their knowledge which will help them in a later sprints.
Scrum doesn't mean Micromanagement
Scrum has strict rules and gives a lot of transparency: After each sprint there has to be testable software and a demonstration of the use cases that have been developed within each sprint. And this is more than a monthly demonstration because the with this demonstration the sprint goals are checked against the use cases of the product backlog that should be realized within this sprint.
So we have very hard and strict criteria and the team has to to put all its strength to fulfil them. If there are additional requirements from the product owner or the management then this can be very harmful: The team can't concentrate on reaching the sprint goals as well as doing unplanned work like additional demonstrations for the management, customers and so on. So this transparency shouldn't be misused by establishing micro management.
