‘We’ve introduced Scrum, but it didn’t bring the expected results. The projects are still delayed.’ – I’ve heard such sentences at the board meeting of a huge corporation, in which Scrum is used in programming teams (about 30 people). What went wrong?
It turned out very quickly that there are many reasons of this situation. These are 7 deadly sins, committed by companies:
1. Scrum is not only a process, but first of all – values!
‘The Scrum guide’ is very easy – it’s only 1-2 A4 paper sizes. When you familarize with the methodology, it seems to you that the introduction will be easy and short. And it’s usually like that. Unfortunately, after some time it turns out that basically nothing changed, regarding quality and project completions. Why? Because in Scrum, we forget about such values as:
• engagement (earlier commitment)
• concentration on the most important matters
The basis of methodology success are exactly self-organizing teams, which hold these values.
2. There is no place in Scrum for traditional project managers.
One of the basic Scrum rules are self-organizing teams, what means that there is no place here for traditional PM. Unfortunately, it often happens that former project managers try to interfere in Scrum process and impose tasks, priorities and so on. Of course it ends with the disaster. Scrum teams are autonomous and we must respect it. If the managers break Scrum rules, the teams come to conclusion that the methodology makes no sense.
3. Additional tasks.
The most common reason of projects delays. Example: the team has its set of tasks for a given sprint, which they declare to complete. However, the director comes and sets during a conversation new, urgent tasks, which (in his opinion) can be quickly completed. The effects of this are: employees frustration and broken sprints.
4. Joining functions of Scrum Master and Product Owner.
You should definitely avoid this situation.One person may hold the positions of these two functions, but in different projects. A good solution here is Scrum Master from outside.
5. Errors during introduction.
Although the process isn’t difficult, you should remember about some rules. You can read about them in a different post:
6. Negligent retrospectives or lack of them.
Scrum team develops itself during the following sprints. The quality of labour intensity estimation, cooperation in a team, working with Product Owner are improving. To make it possible we should take care of accurate retrospectives, so as to draw conclusions and improve ourselves in the next sprints.
7. The choice of Scrum: Unfortunately, Scrum won’t work in every company. Here are some examples:
• When the employees are involved in many projects at the same time. Of course, single people may work in a few projects, however it can’t be majority of them. I omit the issue whether it’s effective when someone works on ten things at the same time.
• Big teams – Scrum calibration into teams bigger than 10 people is extremely difficult, unless there is a possibility of dividing the team into smaller teams.
• In teams, which also realise, apart from projects, the current clients’ service with short times responses. I’m talking here about situation,in which the orders must be realised at once, and can’t wait until the next sprint.