Certified Scrummaster® and Scrum Product Owner® in Details

Read about Scrum techniques we learned on training in Warsaw, Poland. Now we apply them at our company and are happy with the results. Ball Point, Story mapping, Kano model, and other Scrum terms in a nutshell. Today we are going to share our experience from participating in the CERTIFIED SCRUMMASTER^® and CERTIFIED SCRUM PRODUCT OWNER^® courses from Innovel and ProCognita in Warsaw, on June 29–30^th and July 1–2^nd. This article is not intended to create a revolution in SCRUM; it is aimed to share a few materials and techniques presented during these courses and the results of applying these techniques in our company. These techniques, which we will be discussing, would be useful both for those who are taking their first steps in SCRUM and for those who have much experience in applying this framework in their projects.

CERTIFIED SCRUMMASTER^®

We started with the Silent Sorting exercise. First, we had to write our expectations from the ongoing course on stickers and stick them up on the “expectations board.” After that, all participants were divided into two groups. The first group had to sort all the expectations by any number of categories. There were no rules except one — this group had to do this with no discussion. The first group performed well and sorted all the stickers quite quickly, even considering that some stickers were moved a few times. After that, the second group had to name all created categories. Unlike the first group, the second one was allowed to discuss.

During the debrief part, we understood that the second group spent much more time naming seven categories in contrast to the first one where the same amount of people sorted more than 30 stickers. The conclusion is the following: during the discussion, we spend a huge amount of time arguing instead of performing the task. We do not insist on removing any discussions from your work — in some kind of activities such as brainstorming, the discussion is inevitable. However, when all the participants are “in context,” you can get better results if you exclude preliminary discussion in some kind of activities, like in our case, to allow for the processing of the task in parallel by over one person. By the way, the importance of context was illustrated by the second group: a lion’s share of time had been spent in trying to understand the context of the first group so that they could try to name the categories correctly.

The next exercise was quite simple but very useful. It was about creating “working agreements” — a set of rules for the team. According to this exercise, the team had to create a set of conventions, which they would keep up-to-date, and monitor themselves so that the rules are followed by everyone. The main advantage is what agreements come from inside of the team and are not set by managers.

In such a case, the team has an internal motivation to work according to their rules, and that is why rules are likely to be followed. Second, if any team member were to sabotage a routine, the entire team would keep pushing that team member to follow the rules. To conclude, we would like to say that this exercise is great for making the team self-organized, or at least to get started on this process. We already tried using this exercise in one of our SCRUM teams and acquired great results. That team had a “disease”: some people used to arrive late for Daily Scrum Standup too often. As we had applied a rule to not start the meeting until all of the members are present (those who are sick were not considered), sometimes an entire team had to wait for about 5–10 minutes until a few remaining people arrived at the meeting. After one more such instance, team members agreed that the person who arrives late should somehow apologize for keeping the rest of the team waiting. A ScrumMaster came up with this idea and offered, as a suggestion, creating working agreements with one sole rule: those who are late over three times, would serve a pie for the whole team. During a month, the number of cases decreased to one or two per week. After the first case of showing up late and serving pie to everyone, which was pushed by other team members, the number of cases decreased to almost zero, except a few very extreme cases.

There is one more useful exercise: Ball Point Game. We have added quite an informative article for reference, which describes this exercise, so please read it first; if you have already heard about this exercise, keep reading, as we would like to share our experience of participating in it with you. During 30 minutes, we handled seven iterations, which included planning, doing some work, and retrospective. After each iteration, we tried modifying our way of doing the task which helped us to increase our work productivity by six (!) times — from 20 to 120. In our opinion, this exercise had the most visible result compared with all the other exercises we experienced during both courses. Of course, in practice you may not receive such high results because many factors would affect the team: internal process rules of the specified company, business domain, whether the team is ready to accept any changes or not, and so on. But still, in the right conditions, this exercise is very helpful for teaching teams to become Agile.

We would like to indicate one more exercise, which is developed for teaching the team to make relative estimations. In fact, it is a modified Mike Cohn’s Zoo Points technique; thus Tomasz’s version has a great advantage — the nature of objects to be compared. In Zoo Points, you need to work on animals sizes, which is quite abstract and has not much in common with estimating pieces of work; meanwhile, Tomasz’s exercise deals with estimating tasks’ complexity from the beginning, by asking the question: how hard would it be to do something, for example, throw a rock, a piece of paper, or even an animal by one meter? Since, in development, we often face very different tasks, which require our own approach, this exercise seems to be much more effective than Zoo Points. There is another thing we learned from doing this exercise. First, planning sessions are more about synchronizing information between the team members, which is even more important than the actual estimation, so that everyone knows what to do in the specific task. That is the same thing we had to do because every course participant had their own opinion on throwing each object. Second, it’s much easier to make an estimation when you have a standard, well-known estimated task — throwing a rock in our case. We already tried using this exercise a few times while teaching one of our teams; during each session, we used to create a new list of objects. As a result, we were finally able to define the real capacity of that team and increased the percentage of “done” work from 70-75% up to about 90% per sprint and it keeps growing. Of course, that was not the only tool we used to achieve such a result, however, we believe that it has played a significant role.

Finally, we would like to inform you about the exercise which would show very clearly how self-organized teams perform. This is the variation of the “human knot”, popular during team buildings, when you are asked to take any person’s hand with your left hand, and another person’s hand with your right one. After that, you need to untangle and make a circle. The main difference comparing to the original version is that we had two iterations. During the first one, we had a “manager,” who was guiding the untangling process; other participants had to follow the instructions. In the second part, we had to untangle all together, without the manager. The results we gained were quite interesting: the manager had to spend much more time—about four minutes—to finish untangling the knot; meanwhile, when we were doing this altogether, we had spent only 17 seconds, which is 14 (!) times less. So basically, this exercise shows very clearly how great a team of professionals can perform if they are not told what to do all the time.

During the rest of the course, we studied various theoretical material such as roles in SCRUM, their responsibilities, different activities held during the sprint, Agile essentials, etc. This course would suit both newbies and those who have already tried being Scrum Master and would like to sharpen one’s theoretical and practical knowledge.

CERTIFIED SCRUM PRODUCT OWNER^®

During the Sertified ScrumMaster^® Course, we focused on the different techniques for working with the team inside the SCRUM framework. The Certified Scrum Product Owner^® course was specialized for working with products as a Product Owner in various aspects: release planning, sprints planning, customer and user expectations management, features prioritization, etc. Similar to the previous course, we started with defining expectations and working agreements.

After that, we moved onto the Flip the coin exercise, which started off the practical part. Four students played the role of employees and performed the task of flipping 20 one-cent coins and passing them to the next employee. Every coin, which had reached the final employee and had been flipped, was considered as a “done” piece of functionality, which could be passed to the customer. As soon as the final employee flipped the last coin, the exercise was finished. The other four students were considered as managers — they had to record the amount of time during which their employee finished their part of work. Finally, one last person had to record two checkpoints: when the first and the last coin were “done.” During five iterations, rules changed a few times: for the first iteration, each employee dealt with one batch of 20 coins; every next iteration, each employee dealt with a batch of 10, 5, 2, and 1 coin. We found out, the less the bunch size was, the better was the total productivity, while personal productivity was decreasing. If after the first iteration we delivered the first piece of functionality after only 76 seconds, then after the fourth iteration our result was an amazing 6 (!) seconds. The total time taken to deliver all functionality decreased too, from 86 to 25 seconds, which was more than three times less; thus, after the last iteration total productivity decreased by three seconds due to a less than the optimal batch size. We realize that this result is quite far from reality, and much more “ideal” because the exercise did not consider such things as an increasing amount of work, re-works and defects fixes, acceptance issues, etc. However, this exercise clearly demonstrated the profit of an iterative approach and the value that could be provided to the customer by using it.

After that, we started working with the business case, which was at the center of the further program. First of all, we needed to create a product which we worked with up to the end of the course. Our team decided to create a web application, which would help travelers to find the best tour according to their criteria, defined by the user, such as tour cost, duration, or minimum amount of transfers. Next, we defined a few business drivers for our product:

• We want to create this web application for those who do not have the availability or time to spend much time searching for the best travel tour, and that is why the matching process should be as easy and quick as possible;
• We want to provide our customers with the best match according to their defined criteria;
• We want to make our customers happy.

After that, we needed to create a few features for every business driver. This was quite complicated because some features hardly supported any of the business drivers. During this task, we also worked a lot to create user stories, so that our final list of features looked like a real backlog.

With that list, we moved to the Story Mapping technique:

1. Firstly, we created a backbone on the flip chart—kind of customer journey—by placing high-level activities which would be available in our web application, from the initial to final, from the left to the right;
2. During the next step, we sorted user stories below each step. Here we added a few more essential stories that we had missed initially;
3. After that, we held a prioritization session, where we put the most important stories above the less important ones for every activity;
4. Finally, we had to divide all of these stories into releases. Each release had to contain enough value so that the product could go live after that release; also, the first release had to contain as little functionality as possible, so we started with the “walking skeleton”.

And here was the most interesting part. We spent much time discussing what should be included in the first version, dismissing one story after another. By doing this, we came to understand that in our first release, we could go live with one simple feature — a landing page with some contact information. Although this kind of solution was very far from our initial idea — an algorithm for matching an ideal journey—we had reasons to follow it:

• Our initial idea included a lot of complicated functions such as integrations with ticket booking systems, hotel booking providers, and the algorithm itself. To implement all of that, much time and resources were needed;
• That also meant that our product would start producing a profit in the very long term, which we considered as unacceptable;
• During development, the whole idea could become irrelevant due to different market changes, so there would always be a high risk of failure of the product.

According to the items above, it was reasonable to start with hiring a few agents and let them process all of the incoming requests from the customers. Of course, in this case, we had to work with many other travel agencies. But on the other hand, we would acquire more or less a stable financial source of income not only to stay afloat but also to keep implementing extra features; meanwhile, we would be able to study market needs. That is why this solution seemed to be the best option from the perspective of the new business; for a mature company, the decision would have been different. Thus, in our point of view, Story Mapping is a very helpful technique to work with your or your customer product and come to an understanding of why products do need to evolve iteratively. We believe that every reader has worked on a product, or has at least heard of such a situation when a few months or even years of work were thrown away because before development finished, the business idea had become irrelevant due to some reasons. This technique partially reduces such a risk.

We want to show two more prioritization techniques, which were discussed during the course:

• Purpose Alignment Model. It is used to divide features into 4 groups inside the matrix. Higher priority features are those which are put into the “differentiate” group, and the lower priority ones are those which fall under the “who cares?” group;
• Kano model. This technique divides features into basic, performance, and excitement groups. After the first release, your product must contain all the basic features, some from the performance group, and just a few of the exciting features or even none.

Conclusion

Both courses were very informative and useful. During the four days, we:

1. Removed blank spaces in our knowledge about SCRUM;
2. Received answers to our questions about applying Agile in different kinds of teams from practicing SCRUM professionals;
3. Acquired many tools which would help us to work with the customers and the team;
4. Discussed various practical issues with experienced Product Owners and ScrumMasters.

Some of you may think that most of the information we received during the courses can be found on the internet — and you may be right sometimes. But we should take note that the efficiency of live conversations, the possibility to discuss different aspects of SCRUM with professionals — these are things you cannot get from online forums. Of course, the possibility to become a Certified Scrum Product Owner or Certified ScrumMaster after finishing the course is also a great bonus.