Scrum and me... me and scrum... it is a complicated relationship...My last 7 years was nothing but "move to scrum" "be agile" "save the world" (where world===company).
And scrum is like the cake. It is a lie.
I remember the first time we met. Scrum was like a blond, slender, tall Japanese woman.... interesting but really confusing. Our colleague brought the idea to our office (call him Golden Broom, and our office: The Colony). He had a bunch of cards with different colours, he draw a board (ToDo, In progress, Done) and mentioned the well known meetings. One of the main developers instantly bought more colourful cards where we could wrote our stories, and bugs, and whatevers. It started with one team, we successfully multiplied the amount of meeting hours by approximately 1000, but at least kept the production rate the same (its good and bad at the same time), and increased the frustration (or not... not sure about that). And Scrum, because we thought that is our light saber or I mean live saver, were introduced in every team, one by one, voluntarily (actually it was really voluntary, we really thought that will change our life). But we slowly realized Scrum did not solved any of our issues... but it did change a few things. We told ourselves "at least now we/our job are more visible", what was true, but no one wanted to see us/it.
My relation with Scrum did not change. I have been through a few process migrations now, and I never had the feeling: "wow, this works, Scrum is great". Even if there are problems with the team members, with the company, with the aspect of planets, the main problem is with Scrum. It cannot work. Well, that's not true, it can, but only on paper and in a really small subset of reality. Well maybe it is just me, but I think the process out of the shelve should be able to handle reality without raping it.
What's wrong with Scrum?
1. Its whole concept is just not true. Usually the team does not and cannot have all resources+access+knowledge what they need for their work. So they will have dependencies, and Scrum cannot do anything with that (well you can add an extra column). And it will strongly and randomly influence your velocity (the ultimate value).
2. The team does not work without any connection with the rest of the company (even if the Scrum master pipes all the requests). They occasionally have to help to other people, solve issues, and, BLASPHEMY!!! they have to fix bugs, do releases, because:
3. Scrum just gently forgets about the rest of the lifecycle. Staging testing, releasing, firefighting, hotfixes, service releases... "minor" things what randomly and not randomly influence your velocity again.
4. Scrum has no idea what to do with a non-homogeneous team, like DBA, QA, Dev (frontend, backend). They will be loaded differently during the implementation on an epic, and you cannot plan and utilize them easily (without moving them here and there, or ask them to do other things what is not their profession). But the biggest problem is with the QA-Dev opposition. QA and dev does different things. They cannot be each other substitutes in most cases. What a dev can pick up, a QA cannot, and vice versa. QA is loaded at the end, they usually have to do testing outside of the sprint (staging, live release testing, etc)... So you will have sprints where the devs are not loaded while the QA is, or the devs could not finish their stories, so the QA could only do a little testing, and they were doing nothing or days (well, you know what I mean). Of course they can always help each-other out (=dev should do more testing) but in reality it does not work. Especially not for longer term.
5. list all your issues here what you get from the fact that the rest of the company need to be able to support your scrum ("process is for the people" not other way around, right?), they need to give you good product owners, the business needs to change their thinking, etc...
So at the end your velocity will be a joke. The number what you can deliver for sure will be much lower compared to the number what you can almost deliver. And this unpredictability will slowly degrade the commitment in the team.
I know, Scrum is not the silver bullet, it is not for any team, but as I see it is only for a team which is in a startup company, with almost every people in it, and they do not have too much users, or they are not on live, so they do not have to deal with bugs, super-important customers, or at least they do not have serious releases process. Where serious means someone has to do something for more than a day. So indeed it is not for all team, but for <0.001%.
And the real problem, that Scrum does help a little. If your organization was a chaos before, without traceability and visibility and predictability (well you wont have it here as well), then introducing Scrum can give you the false hope, that the improvements what you have achieved in the first weeks/months will stay, and all your issues/difficulties will evaporate. But in reality, you will always fail the sprints, so you will plan less and less till it will be ridiculous so you start to increase again, because there is no other way to ease the cognitive dissonance what you have (why we cannot do more if we can do more?). And everyone silently accepts the fact that the sprints are never done. You will often have sprint goals like: "complete the sprint", because the tasks are independent not coherent enough so actually the team is not sprinting to one direction.
At the end Scrum will be nothing else, then a way of organizing meetings and doing estimates, and managing tasks.
Solution comes in the next post.
No comments:
Post a Comment