Why Scrum sometimes doesn't work and what to do about it

Among your friends there are probably people who tried Scrum and decided to refuse. Perhaps you yourself were in that situation. I trained at Scram from Jim Coplin, Microsoft's internal trainer, in Sweden. He worked in several companies, in which everything was on the screen. And also in those where they used classical development methodologies. In this article I will tell my observations and try to uncover the mystery of Scram, why it is not given to many. Read under the cut.

What is scrum? Why is it needed and what are the advantages? These are important questions, because many are beginning to use Scrum as a fashion, but it’s 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 . I will give an example: on one project, we decided to make a classic multipage video application, after a couple of months, we decided to make a one-page upstairs, half of the code had to be thrown away, half rewritten. After another couple of months, they decided what to do not only for the video, but also for the pictures, and this entails a complete redesign of the design. Some time later, the chief designer and top management changed, and the new one had its own ideas about how and what to do. This is not counting regular edits and quite fundamental changes from the marketing department, which tested 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 of existence of such a project. Of course there is a waste of time on stand-ups, retrospectives, etc., of course, sharing code and limiting the number of simultaneous tasks reduce overall efficiency, but this is a small price to pay for the project to move steadily in high variability. Scrum was created not from a good life, but from a necessity.

Another example: a web studio performs its 50th project, it 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 a coordinated TK and layouts appear. The designer this month has already done three of the same projects and a hand-crammed, connecting all his creative, just doing business. They don’t even check it, because they know that it has been working for a long time and it always does a great job. A coder and a programmer, reading Habr with one eye, looking at the IDE with others, monotonously doing their usual work. The work is handed over to the customer, and he, well, he didn’t accept it the first time, rolled out the list of edits. Will Scrum work on such a project? Let's figure it out. Can the manager initially make a work plan? Certainly can. Can the 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 happen quite rarely, say, not every second order. Can specialists, based on previous experience, suggest how the project will develop further and insure change? Of course, because they have a great expertise in such tasks. Even if somewhere the classical approach fails - these losses are not so big as to beat the drums.

Scrum gives you tremendous flexibility, but not for free. Answer for your project: Do I really have so much volatility that I need scrub? What to do if on your project scram did not work? The answer is simple: do not use it, it means for your case it is not suitable. You can read the works of Taylor and Drucker , in IT they totally underestimate the achievements of classical management. You can read my article about the fact, (commercial break) how to meet the deadlines on projects managed by the classical methodology. No need to give up what works fine when properly configured, there are lots of classic ways to increase efficiency.
')
But of course you can't explain all this to your director. When the top management sees that Scrum has set up work on a volatile project, which otherwise did not move at all, they begin to think that this is a universal pill. Scrum is progressive and innovative, and when you say that you work on a screen, it sounds cooler than if you work on the classics. And it does not 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 plan dates accurately. But we want everything new and advanced, forgetting about proven and working methods of management, such as the division of labor, the assignment of areas of responsibility, motivation, control. There is a myth that in IT everything is different, for example, joint ownership of the code is useful because it increases the bus factor. But how do other industries cope with it? Officials, for example, do not increase the bus factor, but, on the contrary, vague responsibility is considered to be a sign of bureaucratization. By the way, nowadays 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 Scramovsky stand-up rally is, in fact, an ordinary Soviet meeting, held earlier in most enterprises at the beginning of each working day. Therefore, colleagues, read the classics and be critical of what you are trying to sell.

Summarizing: if you have a big, really big variability on a project - Scrum will be able to raise the effectiveness of your work. If you can make a plan and approximately know what will happen in a month or two - do not use Scrum, it will not help you much, but you still have to pay, time, convenience of work, etc ... And of course use common sense, it’s not forbidden use Scrum in parts, if some ideas from there seem interesting to you and it seems that they will work - take them boldly and use them, the main thing without fanaticism. I hope the article will be useful and will help at the right time to choose a methodology.

PS: Everything stated in the article is the personal opinion of the author, accumulated over 10 years of software development practice. Many moments are different from the mainstream, think with your head and do not take anything as absolute truth. Write your matching or opposite experience, if any, in the comments. And may good luck come to you in scrum poker and scrum preference!