Thin Scrum is better than good Agile

Volley squandered 50 officers and 760 privates. The French trembled, panicked, and fled. “Our business did not go well here,” the official French dispatch describes this moment of the battle.

Kelly J. Gunpowder. From alchemy to artillery.



Scrum team formation is always fraught with difficulties. Almost everyone copes in order to change the order of the workflow and begin to carry out some of the necessary Scrum events. But the minority is able to get visible benefits from these formal changes and start really changing the work process. As a result, the team has the following opinion about Scrum: “ We are wasting time on rallies. Scrum doesn't work. Something needs to be changed . ”



Trying to somehow save the situation, Scrum activists recall that Scrum is also a framework. A new strategy is announced: “ We are not only Scrum, we are also Agile! We use the best practices, we take only the best from Scrum, something that is appropriate for our situation, and everything else is superfluous and optional . ” And if so, “ We are great, and we are doing everything right .”

')







Unfortunately, such a “scrum rescue” is a dead end. Going the easy way, getting rid of the difficult elements of Scrum, not trying to independently search for and solve problems, copying techniques from randomly tucked articles, you can build a process. But not Scrum. Scrum Guide, End Note: “ Scrum’s roles, it’s possible that it’s possible, it’s not a scrum .”



Scrum is really a Framework, but not in the sense that this word is usually understood in development. Scrum is the framework, the foundation, the foundation of the work process. All elements of Scrum are designed to complement and support each other. However, they are not duplicated. There is no safety margin in Scrum. Therefore, everything that is described in the Scrum Guide is mandatory for implementation; nothing can be thrown out of Scrum. But you can and should expand.



Scrum Guide defines the workflow in general terms, since each team has its own specifics, and there is no universal imperative solution for all and cannot be. Each team must find the best way to organize their specific work on Scrum. Decentralized teams can carry out the Daily via Skype, and, working in one place, you can gather in the working room or go to the meeting room or on the street, if there is always the sun and there is no rain.



Subject to the acceptance of Scrum values at the company level as a whole, Scrum can be implemented fully and in any team. By starting to work on Scrum, the team is guaranteed to make significant progress.



In the book “ Scrum: The Art of Doing Twice the Work in Half the Time, ” the author Scrum Jeff Sutherland promises to double the impact of the work team. In fact, if he exaggerates, it is not too much. Perhaps you should not wait for grand improvements instantly. We are reasonable people and rarely bring work to such a deplorable state that even minimal systematization will immediately give a grandiose result. However, progress will happen, and the scale of improvement will be noticeable to the naked eye. And everything will start from the fact that the previously silent developers will begin to talk about interference in their work, and from the fact that they will begin to listen to their opinion.



Practice shows that it is most difficult to establish Scrum in those teams that have already begun to “work on Scrum”, but in reality built the process chaotically.



By basing work on prejudice, unsuccessful techniques and a poor understanding of how Scrum works in general, the team will drive itself into a dead end. But even this situation is not hopeless. Although some help from such a team is likely to be required. The team will be able to figure out what it is doing right, and where it’s wrong and what it is missing. But it will take more time than for a team that avoided such mistakes at the very beginning.



There are a lot of mistakes and misconceptions about Scrum, but some are so common that they are accepted by everyone without any criticism and turn into a Cargo cult . In order not to be trapped yourself, it is worthwhile to sort out some of them.

Scrum: Bug Work

About teams



You can often hear the following:



“The scrum team should consist only of developers, each of which should be able to do all the necessary work. Where do we get these? We only have designers, developers, layout designers and testers. If so, the Scrum team won't work out anyway, we will work as before . ”



But in reality, the Scrum Guide says: “ Development Teams are a need to create a product Increment .” Yes, the team should be universal, but it should be universal in general. If you need JavaScript developer, QA and designer to bring development to release, they should be all in the team. Otherwise, the "cart will not go."



At the same time, the team is fully responsible for the result of its work. Scrum Guide: “ Accumulation and accountability is a whole development team ”. These are not empty words. If the designer Innocent drew an excellent design, but the team could not realize it and release it - this is the failure of the team in general and each participant in the team in particular. Innocent, instead of blaming on JavaScript and QA, that they are slowly working, should think: maybe he can change something in his work so that the next time the team can achieve a result.



Moreover, all members of the Scrum team have one position: Developer. Scrum Guide: “ Scrum recognizes you no matter how a person is involved; there are no exceptions to this rule ”.



First, this is the key to increasing team productivity. For example, despite the fact that Innocent has a specialization in design, and is most effective in this type of work, he is nevertheless quite able to help the team with testing if this particular development stage is a bottleneck at the moment. For more on this, see Eliyahu Goldratt’s The Goal in the Original.



Secondly, it allows all team members to discuss all issues as equals. Ideas, assessments, problems - everyone has the right to express his opinion. For example, Innokentiy has no right to ignore Tatyana’s remarks that the red color of the font on a red background is a bad visual decision. Despite the fact that Tatiana has a specialization in testing, having seen the problem, she has the right to speak, and her opinion cannot refuse to listen because she, you see, is QA. In Development Team, everyone is equal, and this is really important. Such an approach is not unique for Scrum, for more details on the importance of this principle can be found in the book Jeffrey Rothfeder “ Driving Honda ”.



It is mutual assistance and mutual respect that form the basis of a successful Scrum team.



About review



“ At Demo, you need to invite users, and we are doing a web application and our users are somewhere far away. Maybe there, in sunny California, Scrum teams can invite users to demos, but not in our country of frosts, bears and dolls ”.



Scrum has no demo. However, this does not prevent many from holding exactly Demo. For example, collect 200 people working in the same room with a projector and torment each other for 5 hours with demonstrations. Enterprise. Epic. Useless.



Scrum has a review. And the review implies a discussion of the work done, the results achieved and future plans with the stakeholders [stakeholders]. Communication and feedback are key elements of the review; everyone invited to the review should have the opportunity to speak out and discuss their point of view with the team and other stakeholders. Therefore, the number of invited to the review should be limited, otherwise a normal discussion will be impossible. To invite the most valuable people to the review is the responsibility of the Product Owner. Scrum Guide: “ Attendees include the Product Owner ”.



Interested parties include not only business owners or customers, but also any other company employees who can provide the team with a qualitative assessment of the results of its work and at the same time are interested in overall success. These can be representatives of technical support, analysts, development experts, heads of departments, Product owners of other teams and any other employees, regardless of their position or type of activity. It is important that their opinion is for some reason valuable to the team. Finally, yes, end users, if that makes sense.



You can read more about the review in Kenneth Rubin’s book, Scrum Basics .



About retrospective



“ We tried a retrospective a couple of times, but there wasn’t much to talk about. In general, there are no problems in our team, so this extra meeting is a waste of time. Let's better work an extra couple of hours . ”



Retrospective must be required. Only by learning how to find and fix problems in the work of a team, you can increase its performance. Learning to conduct high quality retrospective is very difficult. Books will not help. Here we need practical experience.



The team must have either a strong Scrum Master, who will teach the team to conduct a retrospective from the inside, or someone from experienced managers who can help the team from the outside.



Working from the side, you need to be very careful and only push the team in the right direction, and not feed it with ready-made solutions. Otherwise, the team will never become independent and after removing the “guardianship” will quickly return to where it started. In addition, teams are always better at making decisions to which they came themselves, and implement them faster and more efficiently than any decisions from the outside, even if these solutions are good in themselves.



Having achieved the first success in improving the review process, you need to redouble your efforts. If it seems that now there are no problems, this is a clear sign that everything is very bad. There are always problems. Retrospective is Kaizen, a continuous and never-ending process of improvement.



About Scrum-masters



“A scrum master on every team is a waste. And where to get them? We opened a vacancy and hired only one for six months, and then almost without experience. He has nothing special to do, we conduct a review once a quarter, the daily stand-up teams themselves organize, and generally cope, there are no problems. He, of course, spends too much time in the room with the xBox, but the project drivers are happy with him, they say, he helps the senior developers to plan and collect reports on the commands at the end of the month. In general, one is enough for us, and the vacancy can be closed, which is no use looking for . ”



Indeed, it is almost impossible to hire a Scrum master, and especially a good one - whoever will be bad at hiring. But this is not necessary. It is important to find a developer in the team who can fulfill this role. To give him this opportunity, removing from him a significant part of the load, which he now performs. And most importantly, start learning.



Yes, you need to learn Scrum-masters. To fulfill this role you need a skill that does not appear by itself. You can send “masters” to the training, it is easy, but the result will be modest. It is much more important to teach the “masters” of various teams to meet regularly and discuss together the problems they face and the solutions they find. It will also be useful if the “masters” start to prepare and conduct internal Scrum seminars on topics they are interested in.



Scrum-master can find a lot of useful things in Scrum Guide .



Coordination of work



“ Scrum is intended only for small, individual, independent teams. And we have 30 developers, not counting testers who develop one application. We work with common code and common base, what kind of independence is there? We are divided into six teams that should interact and Scrum does not mean this. So you should not expect an increase in productivity. Well, at least Product managers no longer need to bargain for each specific developer . ”



Yes, the combined efforts of several Scrum teams working on a common product are required regularly, and this is normal.



In Scrum, there are no Product Managers, or any other managers, just as there is no Demo. However, development can be coordinated within Scrum.



Product changes that do not require complex technical efforts can be simply coordinated between Product owners of teams and planned with high priority.



Sophisticated technical work, ensuring the integrity of the application architecture, avoiding “bicycle construction” are provided by regularly invited to review and plan technical experts of the application. Scrum Guide: “It’s possible to follow up on technical or domain advice ”. In a company, there may be dedicated roles for application architects outside of teams, or it may simply be experienced and highly skilled developers working in specific teams, but actively interacting on product development issues in general.



Pro planning and DoD



“ Planning with the whole team is nonsense. Waste of time. Last time, designers had been bargaining for an hour, what color do the buttons do, and should we listen to them? We plan the whole day, and only half of the tasks are done, it would be better to spend this time on work. In general, planning work for two weeks is useless, because tomorrow there will be a bug that needs to be fixed urgently, and the whole plan will fall apart. And we do not fix non-critical bugs at all, because the sprint plan cannot be changed. Do you? What is it? ".



The whole Scrum team really should be involved in the planning. It is important. Thus it is guaranteed that everyone will know what and how the team will do in the sprint, so as not to play the “damaged phone” in the process. It also allows you to immediately take into account all the comments from all points of view.



However, the team must learn to use the time allotted for planning, with benefit and to work out different tasks in parallel in the composition necessary for discussion.



The full composition of the team in planning is required during the initial analysis of the backlog before the assessment, in forming the goal of the sprint and drawing up a plan of action to achieve it.



The goal of the sprint and the list of tasks taken in the sprint is often confused. Up to the wording "our goal, to do all the tasks taken in the sprint." This is mistake.



The goal should determine the expected quality result from the work ahead, and there should be one such goal. The goal should not change during the sprint. Scrum Guide: “ No changes were made that would endanger the Sprint Goal .” Having a goal gives the team some tactical freedom in choosing what will be realized and how, which is often very important. Scrum Guide: “ The Sprint Goal is implemented within the Sprint ”. This is not only an opportunity to refuse to implement less valuable tasks if resources are insufficient, but also an occasion to do more if there is a good idea or opportunity.



It is possible and expected that the list of jobs scheduled for the sprint will change. Scrum Guide: “ Scope can be clarified and re-negotiated between the Product ” and “ Beginner ” of sprint backlog within the sprint . ” Make changes to the sprint normal and expected. Suspiciously the opposite, when the team works the entire sprint on the original plan, without making any changes to it at all.



Teams often “forget” about Definition of “Done” (DoD) - criteria for the work performed. This seems to be taken for granted; fulfilled means fulfilled, which is incomprehensible here.



Without clear and shared criteria for the completed work, the team will constantly miss with planning: “We’ve done everything! And what's left? To protest and release ... ".



Also, the criteria for the work performed are important for analyzing the results of the sprint, understanding what was not done to complete the work, provides an excellent topic for the retrospective and allows you to formulate specific steps to solve this problem.



Scrum borrows a lot from Lean manufacturing on this topic.



The fixed duration of the sprint here corresponds to the tact time. The planning process implements a pullout system when, instead of telling the team what it should do for the sprint, the Product Owner offers possible options from which the team chooses the work to the extent that it can do it.



The concept of DoD provides for the elimination of work-in-progress losses, the largest of the types of losses identified in lean, since by the end of the sprint all started work must be completed to the end. Scrum Guide: “ At the end of a sprint, the new increase must be done .”



Working together, all these techniques can not only increase the team’s performance, but also concentrate on more valuable work, quickly changing priorities.



Read more about the types of losses in production and Lean manufacturing can be found in the book “ Tao Toyota ” by Jeffrey Lyker, and an entire chapter is devoted to this topic in Sutherland’s book “ Scrum. The revolutionary project management method ”mentioned above. One of the user story planning techniques is well documented by Kenneth Rubin in Scrum Basics .



Pro Scrum Poker



“ There is no sense in Scrum Poker. Developers spend two hours on puzzles, make some estimates. And what is the result? Every time we take twice as many tasks in a sprint than we actually do . ”



The idea of ​​Scrum-poker is so replicated that many people think that it is an integral part of Scrum and without it nowhere at all. This is not true. Scrum-poker is just one of the techniques that has its advantages and disadvantages, as well as using Scrum-boards or scheduling in the form of User stories .



If Scrum Poker works, good. If the team regularly and strongly makes mistakes with the sprint rating, using “poker”, then it is for this team that this method fits poorly.



Maybe you should start gambling. And perhaps personal developer ratings will work better than average.



Practice shows that if the tasks are sufficiently well decomposed, the assessment does not present significant difficulties. It is important that the total score for all tasks selected in the sprint, in the end correspond to what the team can do, and the fact that individual tasks will be evaluated with one or the other error is not really important.



About Scrum in general



“ Scrum is a purely theoretical approach that can work only in ideal greenhouse conditions, in real life Scrum is not applicable. In general, Scrum is yesterday, now everything has to be done by Agile! ".



If you look, Scrum is not so scary. And it is quite affordable for competent and high-quality implementation.



Do not confuse Scrum and Agile, these concepts are not alternative, do not oppose and do not replace each other.



By and large, Agile is a set of tactics that are certainly reasonable, but not sufficient to build a full-fledged workflow. There are a lot of variants of agile-processes, there are not so many good ones among them.



Scrum is a well-thought-out workflow based on principles and tactics that have proven their practical value. By the way, Scrum appeared before Agile, and the Scrum authors were involved in the Agile manifesto.



Yes, Scrum does not come easily.



C'est la vie.



- Dmitry Mamonov



Development department,

Merge's division into master,

Department of work with git,

Senior bash console operator