Impressions from the trainings Certified Scrum Master and Certified Scrum Product Owner

Today we want to share our impressions from participating in the Innovel and ProCognita Certified Scrum Master and Certified Scrum Product Owner trainings , which took place in Warsaw on June 29-30 and July 1-2, respectively. Here we consider the most interesting from our point of view tools and techniques presented at both trainings, which will be useful both to those who make their first steps in SCRUM, and who already have some experience in using flexible SCRUMs in their projects. We left the original names of the exercises in order to simplify the search for those who subsequently wish to find more information; In addition, the article is supplemented with links to English-language articles explaining the essence of some exercises.

Certified Scrum Master

The course began with an exercise called silent sorting . At the beginning, the participants of the training were offered to write out their expectations from the course on stickers and place them on the “expectations board”. Then all participants were divided into two groups. The first group was to sort the stickers into categories. There was only one rule: the sorting should be done without discussion, in complete silence. The first group coped fairly quickly, although some stickers were moved to different categories several times. After that, the second group was supposed to give the names of the categories received. Unlike the first group, the second was allowed to discuss their actions.

During the analytical part of the exercise, it turned out that the second group spent much more time giving names to seven categories, unlike the first group, which spent much less time sorting more than 30 stickers. The conclusion is that often during the discussion a considerable part of the time is spent on conversations, rather than on the direct execution of the task. However, we do not focus on the complete exclusion of discussion from any type of work; on the contrary, in some activities, such as brainstorming, discussion is one of the most important components for achieving the desired result. However, when all participants in the task are in the same “context”, you can omit the preliminary discussion. According to the experience of using this technique, we can note that its use in estimating a backlog task by 10–15% reduces the time spent on planning compared to using planning poker. By the way, the importance of being in one context was demonstrated by the second group: the lion's share of the time spent in inventing category names went to try to understand the logic according to which the first group performed the sorting of stickers.
')


The following exercise at first glance seemed quite trivial to the training participants, but later it turned out to be very useful in work. The exercise was to develop a so-called. Working aggreements for a training group. Any group of people working together should develop for themselves a set of “dormitory” rules that this group will adhere to. The duties of the group also include updating the rules as necessary and monitoring their implementation by all members of the group.



The main benefit of using this technique in teams is that the rules are developed by the direct participants, and not imposed by the managers. Therefore, the team will have an “internal” motivation to adopt the rules and is much less likely to sabotage their implementation. In addition, if one of the team members tries to avoid following the rules, colleagues will take it alive and return to the right path. Also, this exercise is great for the emergence in the team of the rudiments of self-organization. We managed to try it out on some of our SCRUM teams and got excellent results. One of the frequent "diseases" in teams is the reluctance to go to all sorts of meetings that "distract from the main work." This misunderstanding may result in delays or omissions of meetings for various reasons. So, one of our teams was distributed up to some point and lived in different rooms, so the participants periodically “forgot” about the morning stand-ups and came late. And since one of the rules of this team was not to start a stand-up until everyone gathered in the meeting room, sometimes it took a long time to wait. Had to even call late and remind about the meeting. After the next such incident, the SCRUM-master of this team jokingly offered to “punish” those who are late: for every third delay it was necessary to treat the whole team with some goodies. Everyone vividly picked up this idea, and the rule was included in the working agreements. Within a few days, the members of this team enjoyed the fruits and sweets. Of course, this decision was very unpopular among those who continued to be late. However, there was nowhere to go, because the rest of the team members did not give the debtors a rest with jokes and hamstrings. As a result, during the month the number of delays has decreased to almost zero, since no one wanted to spend a decent amount of money to treat a large company.



The next exercise we met was called Ball Point Game . Its essence is to transfer the maximum number of balls from the first participant to the last. The rules are well described in the article by reference, so we will not dwell on them here. Within 30 minutes of the training group, to conduct 7 iterations, including planning, execution of work and retrospective. After each iteration, the group tried to modify the process in such a way as to increase its productivity. Due to these changes, the group as a result was able to increase productivity by 6 (!) Times - from 20 to 120 balls. Of course, in practice, the results may not be so encouraging, because the game simulation does not take into account such factors as the company's internal processes, the team’s readiness for change, the business domain of the project, etc. Nevertheless, this exercise quite clearly shows the benefits of using iterative project management methodologies.

Attention deserves another exercise designed to teach SCRUM teams how to work with relative grades. This is a modified version of Mike Koch’s Zoo Points technique. However, this option has a significant advantage due to the different composition of the group of objects for assessment and the task. Zoo Points are invited to perform an assessment of the size of animals, which has little to do with the real assessment of the complexity of the work. At the same time, the Tomash exercise initially implies an interaction, albeit with one task, but with different conditions for its implementation. Participants are asked a question: how difficult it will be to do something. For example, throw a stone, a sheet of paper, a pen or a living object at a distance of one meter. Since in software development we often meet with diverse tasks, this exercise is of more interest compared to Zoo Points.

There is one more thing that the training participants learned about during the exercise. First, the planning process is aimed not at the fact of receiving an estimate, but at synchronizing knowledge of the task between team members. This is the state that we had to achieve when performing an exercise at the training, because each of the participants in the exercise initially had their own vision of how to perform the task. Secondly, it is much easier to evaluate when you have a “standard”: a unit of work that is clearly clear to all team members and has a certain amount, on the basis of which subsequent work can be assessed. We have already tried this technique on one of our SCRUM teams and obtained excellent results: if previously the accuracy of the team’s estimates was about 70-75%, then after using the technique and defining the “standard” the accuracy increased to 90% during just a few sprints, and tends to increase. Of course, this is not the only tool that we used to improve the quality of ratings. But it was precisely this exercise that gave the greatest result.

Finally, it is worth noting the exercise, which shows very well how self-organized teams can work productively and smoothly compared to those where the manager manages everything. This exercise is a variation of the “human knot” often used in teambuilding. In this exercise, participants are asked to join hands in a chaotic manner. Then, when everyone joined hands, it is necessary to unravel the resulting knot. Presented at the training version of this exercise consisted of two stages. In the first, one of the participants became a manager and told the team how to unravel. In the second stage, the team acted without a manager. The results of the exercise were amazing: the first stage took about 4 minutes, the second - only 17 seconds, 14 (!) Times less. Thus, even taking into account the fact that this is a simulation, and not a real case, it can be argued that under certain conditions a team of professionals is able to do the work without clear guidance from the manager.

The rest of the course was devoted to the study of various theoretical aspects, the fundamental values ​​of flexible methodologies, the role in SCRUM and their competence, the types of activities within the iteration, etc. This course is suitable for both beginners who are just starting to work with SCRUM teams, as well as those who have put several teams on their feet and wish to hone their practical skills.

Certified Scrum Product Owner

If the previous training was aimed at working with the team, then the Certified Scrum Product Owner training is designed to work with the product in such aspects as function prioritization, version planning, customer and user expectations management, etc.



As in the previous training, the group began work with identifying the expectations of the training participants and developing working agreements. Next, go to the exercise Scrum Penny Game . In the course of this exercise, four participants played the role of employees who were to perform fairly simple work: turn over 20 one-coin coins and transfer them to the next employee. Each coin that reached the last employee and was turned upside down was considered a completed unit of work; all 20 coins were considered the volume of design work. Four more participants in the training played the role of managers. They needed to be close to their employee and record the amount of time for which the employee would do his part of the work, i.e. will flip all 20 coins. Finally, one of the participants in the training recorded two points: when the first and the twentieth coins were turned over by the last employee. During five iterations, the rules were changed several times: at first, each employee had to turn over all 20 coins and only then pass them on to the second employee. Then it was necessary to transfer 10, 5, 2 and 1 coin. As a result, it became clear that the smaller the batch size transferred to the next employee, the worse the productivity of each individual employee became, but the overall productivity grew. If at the beginning the team delivered the first completed work unit to the customer in only 76 seconds, then already in the fifth iteration, in just 6 (!) Seconds. The total project execution time also decreased and was 25 seconds at the fifth iteration versus 86 at the first, that is, 3 times faster at the same quality level. Of course, this result is far from reality, since does not take into account possible increases in the scope of work, correction of defects, processing of functionality, problems with acceptance, etc. However, this exercise perfectly demonstrated to all the participants of the training the possible benefits of using an iterative approach to product development and the speed with which such an approach would benefit the customer.

Then we started working with a business case, which became the focus of attention for the rest of the training. At first it was necessary to invent a certain product. One of the teams decided to create a system that would help travelers select the best options for tours according to specified criteria: cost, travel duration, number of transfers on the way, etc. Then the team members needed to determine the so-called. business drivers are something akin to a “mission.” During the discussion, the following drivers were identified:

• We want to create a product for those who do not have the opportunity to spend a lot of time searching for the perfect tour, so the travel selection process should be as fast as possible;
• We want to provide our customers with the best matches for the criteria they set;
• We want to make our customers happy.

Next, the team needed to come up with several key system functions that would support the developed drivers, and then decompose the functions into user stories. The process of identifying key functions turned out to be very difficult, because not all functions that were considered important supported directly at least one of the drivers.

After receiving a list of user stories, the team switched to the Story Mapping technique:

1. First, we created an application framework, placing the key functions in the order in which the user should have encountered them in the application;
2. Then placed user stories under the corresponding key functions. At this stage, participants added some essential stories that were missed when initially decomposing functions;
3. The next step was the prioritization of user stories for each of the functions: the most priority stories were located above, and the least important ones - below;
4. Finally, all user stories are divided into product versions so that each version can be logically finished and ready for release. In this case, the first version should have a minimal set of functionality, i.e. to be what is called “ The walking skeleton ” in foreign literature.

And then the fun began. The team spent a lot of time trying to determine the set of functions for the first version, cutting off one user story after another, or even in whole packs. Gradually, it was understood that the first version of the product may be limited to a landing page with contact information of a travel agency. Although this decision turned out to be very far from what was originally intended, there were weighty arguments:

• The original idea included many complex functions, such as integration with housing and ticket booking systems, the algorithm for selecting the ideal trip, etc. To develop all this functionality, would require significant resources.
• If the first version decided to bring all the planned functions, the team would have made a profit in a very distant future. Given the ever-changing external environment, the risks of long-term investments were too great.
• Already in the course of product development, the idea may change many times under the influence of various factors of the internal and external environment, so it was worth starting small and trying what happens as a result.

With these arguments in mind, the decision to hire several agents and conduct business, as everyone does, seemed appropriate. Of course, in this case, the team deliberately rejects the main “chips” in the form of an ideal journey selection algorithm; However, this approach will provide an opportunity to test the market as a whole, and if successful, raise enough funds to implement the basic idea. We are sure that every reader at least once heard about such a project - or took part in it - where after a few years of work everything that was done was thrown into the basket due to irrelevance. Therefore, we recommend using this technique to prevent such a situation at the very beginning, suggesting that the customer develop the product iteratively.

Finally, we want to point out two techniques that may also be useful in prioritizing functions during version planning:

• Purpose Alignement Model . Used to divide functions into four groups in order of importance for potential users. Functions that fall into the "differentiate" quadrant should be developed as soon as possible; At the same time, functions that “nobody cares” may never need users, so they should receive a lower priority.
• Kano model . This technique divides all functions into basic, required and admiring. In the first version of the product you need to include all the basic functions, several required and 1-2 admiring. If you need to sacrifice something, you should first abandon the admirers, and then the required ones, but in no case the base ones.

Conclusion

Both trainings were extremely helpful. For four days we managed:

1. Eliminate white spots in the theoretical knowledge of SCRUM;
2. Explore many useful tools for working with customers and the team;
3. Get answers to current questions from our practice from experienced SCRUM specialists.

Some of you might think that most of the above information can be found on the Internet. And you will be right, but only in part, because on the courses you can get something that cannot be found on the Internet - live communication with really tough specialists and discussion of burning issues here and now. And as a nice bonus - the opportunity to become a Sertified Scrum Product Owner or Certified ScrumMaster.