First of all: I am not experienced in doing Scrum. Actually my few projects implementing a Scrum-like approach did not went well. But I don’t see that Scrum as process was the problem. Looking back it was more the circumstances under which Scrum has been applied and how it has been applied. I still believe in the benefits coming with Scrum if implemented right.
Reading Florians article IMO says that Scrum is the problem because of its rigid rules which makes it unsuitable in many situations for him. What I basically say is that this is not a problem of Scrum but it just wasn’t applicable in Florians situation or was implemented wrong way.
Second here is my understanding of Scrum and its rigid rules and why I don’t blame Scrum if it is not applicable: Scrum is a framework for implementing an agile process. And it gives this framework a defined terminology and a few fixed rules. This will make Scrum for the most of us simple to understand.
However Scrum is also a trademark and it is clearly defined in the scrum guide how you must implement your process to be called Scrum. What I want to say is: Scrum is just one framework among others. I believe that it is applicable in most situation without changes. But if you need changes. Make them, just don’t call it Scrum and don’t blame Scrum for being inflexible in is definition of rules artifacts etc.
I will take up some of Florians points and reply to them. So be sure you first read the article of Florian to get the context. So here are my points:
1. Teams are self-organizing
A self organizing team is wonderful if it’s actually happening. But as Florian mention there are many reasons which hamper the self-organisation of a team. A certain stability of the team is a precondition to build a team. I agree with Florain. But these reasons are threatening every process and is not Scrum specific. If your team is changing too fast and too often you have no team. And in this case you should not implement a team centered method like Scrum at all.
But don’t blame Scrum for this. Blame the one who chooses a team centered method like Scrum under this conditions.
2. Sprint after sprint after sprint.
Florian says software development is more like a marathon. This is true. But the metaphor of doing a marathon as a series of high intensive sprints leading into a burnout is wrong.
My understanding of a sprint (to stay with the metaphor) is a single segment in your marathon. And no doubt: You want to get the best out of it. So you run as fast as you can with the long distance of a marathon in mind. Scrum is not about literally sprinting every sprint. That would be indeed stupid. If Scrum runs in this mode it is simply implemented wrong.
In my eyes Scrum tries to do the opposite. It helps the team to stay motivated, by defining realistic goals in a sprint. In the same way a runner in a marathon splits his 42,195km into segments to keep motivated.
2. The Daily Scrum
The Daily Scrum is about synchronising the team. Three questions:
- What do I have achieved?
- What will I do next?
- What is hindering me in my progress.
Not more. There are many ways how to do efficient Daily Scrums and they highly depend on who the team works together. Reading „have you ever been in a meeting involving more than 3 people that got anything accomplished in 15 minutes?“ let me suspect that you just want to put to much in your daily synchronising meeting.
3. No planning beyond the current sprint
Scrum tries to ship the most valuable usable product on every iteration. The coordination of the most valuable product is kept in the product backlog and may change depending on the needs of the stakeholder. Having no planing beyond the current sprint is therefor simply wrong – it’s hopefully done in the product backlog.
The sprint just defines the next features out of the product backlog which will make the most valuable product.
4. Permanent emergency mode
I am fully with Florian that you should quit if your organisation is doing software development in emergency mode all the time. But this is not related to any PM method, this is always true. I can see no reason why Scrum is encourage being in emergency mode.
5. Your team can’t work with Scrum? Scrum does not deliver
Scrum is not the silver bullet method. It is useful and applicable under certain conditions. But if it does not work, than the reason for that is IMHO often not Scrum. Why? Scrum is like tool. How well Scrum can be applied depends on many factors. And in worst case it does not fit at all and should not be implemented. It can help you to complete your tasks if applied on the right problem and applied by the right people. The problem/circumstances must fit.
If your stakeholders are not available than Scrum might not be a good idea because the presence of the stakeholders is important to maintain the product backlog and always work towards the most valuable product. On the other side your team must be suitable. As mentioned before self organisation is an important aspect in Scrum. If this does not happen for whatever reason, than Scrum can not be applied in a good way.