Why does Scrum sometimes fail and what to do about it

Among your friends there are probably people who have tried Scrum and decided to refuse. Perhaps you yourself were in such a situation. I studied scrum with Jim Koplin, a Microsoft internal trainer in Sweden. He worked in several companies in which everything was scrambled. And also in those where classical development methodologies were used. In this article I will tell my observations and try to uncover the secret of scrum, why is it not given to many. Read under the cut.

What is Scrum? Why is it needed and what are the benefits? These are important questions because many are beginning to use Scrum as a fashion statement, but it is a tool, and quite specific. First of all, it is a flexible development methodology that makes it relatively easy to adapt to actively changing requirements.. Let me give you an example: on one project they decided to make a classic multi-page video application, a couple of months later they decided to do a one-page application at the top, they had to throw out half of the code and rewrite half of it. After a couple of months, they decided what should be done not only for video, but also for pictures, and this entails a complete redesign of the design. After some time, the chief designer and senior management changed, and the new one had his own ideas about how and what to do. This is not counting the regular edits and rather fundamental changes from the marketing department, which tested the layouts on real users and constantly changed something depending on user feedback. Yes, perhaps in this case Scrum is needed, as it gives the very flexibility. Moreover, this is the only possible way for the existence of such a project. Of course, there is a loss of time for stand-ups, retrospectives, etc., of course, joint code ownership and a limitation on the number of simultaneous tasks reduce overall efficiency, but this is a small fee for the project to move stably under conditions of high variability. Scrum was created not from a good life, but from necessity.

Another example: a web studio is carrying out its 50th project, this is a typical online store on the popular CMS. The customer, although he does not know what he wants, but an experienced manager directs his chaotic thoughts in the right direction, so that an agreed specification and layouts appear. This month, the designer has already completed three of the same projects and with a full hand, connecting all his creativity, just does the job. They don’t even check it, because they know that it has been working for a long time and it always does an excellent job. Layout designer and programmer, reading habr with one eye and looking at the IDE with the other, monotonously do the usual work. The work is handed over to the customer, and he, well, he must not have accepted it the first time, rolled out the list of edits. Will Scrum work on such a project? Let's figure it out. Can a manager initially draw up a work plan? Of course it can. Can a customer suddenly abandon any key module in the middle of development? I think it is unlikely that at least he will have to pay for the work already done. Even if not so, such situations rarely happen, say, not every second order. Based on previous experience, can specialists suggest how the project will develop further and secure against changes? Of course, because they have a lot of expertise in such tasks. Even if somewhere the classical approach fails, these losses are not so big as to beat the drums. how will the project evolve further and hedge against changes? Of course, because they have a lot of expertise in such tasks. Even if somewhere the classical approach fails, these losses are not so big as to beat the drums. how will the project evolve further and hedge against changes? Of course, because they have a lot of expertise in such tasks. Even if somewhere the classical approach fails, these losses are not so big as to beat the drums.

Scrum provides tremendous flexibility, but it is not free. Answer for your project: do I really have so much variability that I need a scar? What to do if the scrum did not work on your project? The answer is simple: do not use it, which means it is not suitable for your case. You can read the works of Taylor and Drucker ; in IT, you underestimate the achievements of classical management. You can read my article about (commercial break) how to meet deadlines on projects managed by the classical methodology. No need to give up what works great with the right settings, there are plenty of classic ways to increase efficiency.

But of course you can’t explain all this to your director. When top management sees that Scrum has set up work on a volatile project that hasn’t moved in any other way, they begin to think that this is a universal pill. Scrum is progressive and innovative, and when you say that you work in scrum, it sounds cooler than if you work in classics. And it doesn’t matter that management in IT (to be honest) is in its infancy and lags far behind management in other industries. After all, we have not even learned how to accurately plan the deadlines. But we want everything new and advanced, forgetting about proven and working management techniques, such as division of labor, assignment of areas of responsibility, motivation, control. There is a myth that in IT everything is different, for example, joint code ownership is useful, because it increases the bus factor. But how do other industries cope with this? Officials, say, do not increase the bus factor, but on the contrary, blurred responsibility is considered a sign of bureaucracy. By the way, continuous integration (a wonderful thing), fashionable now, is just a banal separation of the functions of execution and control, a principle invented long before our birth and the invention of computers. And the Scramov stand-up rally is, in fact, an ordinary Soviet planning meeting held earlier at most enterprises at the beginning of each working day. Therefore, colleagues, read the classics and be critical of what they are trying to sell you. fashionable now continuous integration (a wonderful thing) is just a banal separation of the functions of execution and control, a principle invented long before our birth and the invention of computers. And the Scramov stand-up rally is, in fact, an ordinary Soviet planning meeting held earlier at most enterprises at the beginning of each working day. Therefore, colleagues, read the classics and be critical of what they are trying to sell you. fashionable now continuous integration (a wonderful thing) is just a banal separation of the functions of execution and control, a principle invented long before our birth and the invention of computers. And the Scramov stand-up rally is, in fact, an ordinary Soviet planning meeting held earlier at most enterprises at the beginning of each working day. Therefore, colleagues, read the classics and be critical of what they are trying to sell you.

Summing up: if you have a big, really big variability on a project - Scrum will be able to increase the efficiency of your work. If you can make a plan and roughly know what will happen in a month or two - don’t use Scrum, it won’t help you much, but you still have to pay with time, usability, etc. ... And of course, use common sense, it’s not forbidden use Scrum in parts, if any ideas from there seem interesting to you and it seems that they will work - feel free to pick them up and use, most importantly, without fanaticism. I hope the article will be useful and help you choose the methodology at the right time.

PS: Everything expressed in the article is the personal opinion of the author, gained over 10 years of practice in software development. Many points are different from the mainstream, think with your own head and do not take anything for absolute truth. Write your matching or opposing experiences, if any, in the comments. And may good luck come with you in scrum poker and scrum preference!