Scrum Training

How do we start a training in Scrum

Before starting to talk about what Scrum training is, I wanted to tell you something about myself. At the age of 18, he gave judo classes to children aged 5 and 7, at 20 he gave basic computer classes for administrative assistant oppositions, and from the age of 24 I gave development courses (OCX, Clean Code, TDD, BDD, etc) and Scrum for a lot of South American countries (Argentina, Chile, Brazil, Mexico, Puerto Rico)

How to start, by saying that one of the things that I have been most passionate about in both my personal and professional life has been training, without going into whether I have done better or worse.

For me, training has two key pillars, the first pillar would be to be able to share my knowledge, and the second pillar would be the search for continuous improvement. In this search, I want to be a better communicator, empathize better with the public, who often you don’t know how they are going to react, and therefore be a better teacher.

I think that the type of “enthusiastic” personality that I have (enneagram), has helped me to be able to continually reinvent myself within this wonderful world of training. I have gone from the paper document to the power point, and lately I am using Sketchnoting techniques, with many dynamics and lego (Lego4Scrum).

My personal advice, to get into the world of training, you have an urgent need to share your knowledge, and above all to want to meet the expectations of a group of people who spend valuable time in your training course.

Remember that in a training you are not the important one, they are always the important ones, do not waste their time. It is much better to do a mini-course of a couple of hours, but worth it, than a two-day course without a structure, a clear and well-armed objective.

Preparation of a training in Scrum

I am going to tell how I prepare a basic training in Scrum, here each master has his booklet, and the important thing is that if you copy, you do it from the best.

Until not long ago, I always went to training with my Powerpoint as a basic tool, but one day at a Bikablo (graphic visualization) meetup, I saw that a world of possibilities could open up. The change was brutal, so now whenever I can, I leave the presentation at home and use the graphic representation. In this article you can see some that I usually use.

Another very important thing that you have to look at is the company culture. Let me explain, suppose you are hired to give a Scrum training, where the company has an organizational culture deeply rooted in a traditional model (taylorist), where values are conspicuous by their absence, and sharing knowledge is a chimera.

If you are going to give a training and you do not have any information about the company, do not worry because there are ways to obtain it. In the next section I tell you what I do.

Presentation Round and Expectations

In a Scrum training, the first thing I do after introducing myself and teaching the session script is to do a round of introductions. In this round I ask people what their name is, what their role is, if they know about agile development frameworks and if they have worked with any of them.

If you are working with any agile framework, I am very interested to know what your previous role was. It is very typical that the former Project Manager now acts as the Product Owner. I am also very interested in the percentage of internal vs external, to have some information about the organizational culture of the company.

Apart from the above, I also make them write on a post-it what their expectations are for the course. We place these post-its on a Kanban board as you can see in the photo.

Depending on the type of company, in a Scrum training, I usually give more weight to some sections more than others, and with great grace and self-confidence, I take the opportunity to annoy those managers rooted in the culture of command and control .

Agile Vision

Human beings are moved by both personal and professional goals, and we look for the best way to reach that goal, vision, passion (call it what you want). On this path we come across smaller stones that we can jump over, or with other giant ones that we will have to go around, but we should always go forward. Sometimes it’s hard, but who said life was easy.

Companies call us because they want to work «in another way«, they don’t know how, but what they do know is that they are not having the expected results, and they vehemently embrace the slogan «Renew or die«.

In this case, as a representative of «agile on earth» (just kidding), and based on my experience, I try to outline a basic path that any company should follow in its agile transformation. Be careful, this agile thing is not a panacea, nor is it going to make us always earn money by default, or look at what the 2018 Chaos report from Standish Group says, where an agile project had a 46% chance of success, compared to 26% in a traditional model.

To summarize the path you see in the drawing, indicate that to reach the «Agile» phase, we should first check if people (at an individual level) have the will to leave their comfort zone and consider a different challenge or not. Until we achieve this milestone, we should not go to the next level, where we change the I for the We, where the needs of the team would be above the needs of the individual.

In a first basic Scrum training, I’m not interested in getting too much into the scaling part, but there is always someone who asks about SAFE, and if it is agile or not (the dark side), and you have to give a few brushstrokes.

Agile Manifesto

You know as well as I do that the Agile Manifesto is the abc of “Agile frameworks”. A movement promoted by seventeen software development critics in 2001, who were looking for an alternative to formal methodologies, which were considered excessively heavy and rigid.

At this point, as soon as I start this section, I do the dynamics of the currencies to roughly compare the differences between a traditional development environment (waterfall), versus an environment using an agile framework, and at the end I open a debate with the people who are in the training. I leave you a video (which is not mine), where you can see how it works exactly:

In the traditional model, all the coins go through all the phases of an assembly chain, and at the end of the chain the product is received. However, in an agile model, small deliveries are made, with which it is possible to see if the expected result is correct or not (feedback).

In relation to the pillars and principles of the manifesto, I like to give a little more care to the part of the pillars (people and their relationships, working software, collaboration with the client, and response to change), than to the principles.

Scrum

This drawing helps me to frame the rest of the course. When I started to give Scrum trainings, I explained too many things in this part, and when I was advancing in the rest of the topics (roles, events, and artifacts), I felt that I was repeating myself too much.

In Scrum training, I am interested at this point in giving a few small brushstrokes of the framework so as not to bore the audience (less is more). Obviously we must comment on the origin of the framework, and that it is the most widely used agile framework in the world.

Elements that I want to be part of my speech from that moment on are: Value and Velocity, Iterative and Incremental, Waste reduction, and constant progress.

You see in the image of the Scrum map that there are yellow post-it with questions. Actually when I present the drawing for the first time these post-its are not there. I have prepared these at home, and at the end of the course I give them to them so that they can place them. Doubts??? no, we continue…

Pillars and Scrum Values.

Scrum Pillars

When I talk about Scrum pillars, and I am giving training to teams that have been working for years within a traditional model, I have to be careful.

The reason comes from when I say that Microsoft Project and Gantt charts have done so much damage to software development, where in a 10-month project, in month 9 we asked how the project was going and the shift manager told us that it was going at 90% (at 10% per month), and the client had not seen anything of the product they were developing.

I work in Madrid, where the IT unemployment rate is very low, and it has happened to me many times, that a month before the delivery date of these mega waterfall projects, people left their companies. They leave because they knew the project was a disaster and they weren’t going to finish on the date or even close. The managers had the perfect excuse because they said that they were going well, but that when the key people left the project, it was going to be delayed. Who pays for the broken dishes??? They are paid by the usual, the client.

To fix the above, and to eat an elephant (a huge project), the first thing we have to do is small steaks, that our teams can develop in short periods of time. Promote transparency in the team of how are we doing?, not in the sense of punishing them, but in the sense of how can we help you? If we know how we are doing, we can know how we are going according to plan (Inspection), and if we are not doing well, what we can do to get back on track (Adaptation).

As a closing of this section in Scrum training, I usually emphasize the following sentence:

Remember that all this should be developed within an environment of trust, good will, and mutual help.

Scrum Values

In Scrum training, I don’t usually go into much detail on this part, although I do comment on each of the values, so that everyone understands them, but above all I usually go into two of them, Focus and Respect.

Before, I used to say that to eat an elephant, we would start by eating a little steak, then another, until we ate the whole elephant. When we talk about a project we do the same thing, we break it into small pieces and the whole team gets to work on the first piece that should be the most important for the client.

In traditional environments, the team often receives orders from different sources, or works on two or more projects at the same time. This kills the productivity of the team always, that’s why I’m very heavy with the «Focus» value. Needs should only come to the team from a single point of entry, from the figure of the Product Owner and in a controlled manner, to reduce context switching as much as possible.

In the other part in which I am very heavy, in the value of «Respect«. We usually associate respect with respect for your colleagues, with equality between men and women, with respect for concepts related to creed, race or sex.

Apart from the above, which is a «must«, I find other lack of respect inherent in the professional world. For example, the differences that exist because they have a better degree than their colleague, or the lack of respect that some interns have with external ones, because they feel superior. I don’t even want to think about those companies that have restaurants, or areas for internal, and others for external, or those that add the «external» extension to the email, I can’t stand it.

In general, everything that I explain in the Scrum training, in relation to Scrum pillars and values, can be applied both professionally and personally. It seems that we explain obvious things, but ask who actually applies them.

Product Owner in a Scrum training.

We continue the training in Scrum, with the master of Chinese dishes, the Product Owner. In the drawing you can see the most important thing that I tell, that it does not go far from what the Scrum Guide tells. But for me there is much more.

The Product Owner is the key piece for the magic of Scrum to happen or not. We can have the most mature, self-organizing, multifunctional teams, but if this person doesn’t get it right, you’re screwed.

How should it be to keep many cymbals in balance, and the fall of one significantly affects the rest. The Client, strategy, market, roadmap, budget, or the team, are some of these dishes that the Product Owner should not let fall.

I say that the Product Owner should always have one eye on the client’s needs and strategy, and another on his team to always ensure value and speed.

Value, is to make small deliveries, which are really differentiating elements from the competitors, and Velocity is to see how I can reduce the delivery time, without reducing its quality.

On the other hand, the Product Owner has to give the team wings to be innovative, disruptive, and ensure quality. Other times he has to stop them when they begin to deviate from the defined strategy.

For a Product Owner to do their job well, sometimes they have to have a firm hand with the client and their team and know how to say no. You must be intelligent and negotiate with both parties to reach agreements, this is the most important thing.

Scrum Master in a Scrum training.

As there are many articles that talk about the figure of the Scrum Master, in Scrum training, I want more of the problems that they can face, than what the theory says. The one that watches over the Scrum framework, if you allow me, I’ll skip it.

Things that I tell in the talks that I like to highlight about a Scrum Master:

• You are not a room reservation, your work is much more important.
• Lead by example friend. The values ​​and pillars thing is not only for others.
• You know what personalities your team has (Enneagram).
• You know what dysfunctions your team has (Lencioni).
• Your teams have work agreements (Alliance).
• You know what stage your team is in (Tuckman).
• Study the values ​​of your company and you will understand many things (organizational culture).
• Work on the generation of Value (Product Owner) and Velocity ​​(Team)
• Promotes training and innovation.
• We admit the change even in the final stages, but they are not free, negotiate.
• Small user stories. The great secret of deliveries and estimates (team goals).
• The one that covers a lot little squeezes, controls WIP, and waste, and encourages swarming.
• Experiments, experiments, experiments, will help you to validate hypotheses. Constanlty reflect and adjust.
• The certificate is only valid for passing the first human resources interview.
• If you were a project manager before, take advantage of the Peopleware part and unlearn the command and control part.
• Don’t be discouraged and keep trying. To take a step forward, you have to take a few steps back.
• Don’t be a chump. Design patterns, static code analysis, code review, pair programming, continuous integration, continuous deployment, XP, TDD, BDD, Gherkin, are part of agility.
• Be careful with the funny retrospectives, what do you want to achieve???

Even if you are an excellent Scrum Master, and you have taken into account all of the above, you can fail, because you do not have the support of your company. Remember that the dark side is always present, get to know it and try to bring it to the light. If you can’t, nothing happens, to something else butterfly.

Development Team in a Scrum training.

When I know that in a scrum training, most of the people who attend are development teams, I try to make the beginning as impressive as possible. As I come from the world of software, I know more or less what you may be thinking.

Things like “let’s see what this guy tells us”, “he has no idea”, “that doesn’t work here”, or let’s see if he finishes soon because I have a lot of work, are thoughts that are palpable in the environment. That strength and energy, I have to channel it to achieve my purpose. As Sun Tzu said in The Art of War:

Know your enemy, and know yourself, and you will be victorious in a thousand battles.

To attract the attention of the audience, and plug them into the formation, I usually play the following video, from the 300 film:

At the end of the video I highlight the phrases with which I want to spin the training:

We fight as a single, impenetrable unit, that is where our strength lies. Each Spartan protects the man next to him, from thigh to neck with his shield, a single weak point and the defense would collapse.

I’m sorry my friend but not all of us are born to be soldiers. If you want to contribute to a Spartan victory, remove the corpses from the battlefield, tend to the wounded, and bring them water, but I cannot count on you to do battle. You are wrong Leonidas, you are wrong.

Now we are all ready to talk about what a Development Team is in Scrum, and I have to try to cover all the elements that I have marked in bold:

• A single, impenetrable unit. We have to talk about what a self-organized, multi-functional team is. We, and only we, are going to decide how we are going to do the work and the time it will take us to do it. Obviously we take into account the opinions of others, and we constantly reflect on how we face challenges.

• Our strength. Here it is mandatory to talk about common goals and continuous improvement. Yes or if we have to pursue technical excellence, improving the quality of our work, good practices (test automation, continuous integration, continuous deployment, DEVOPS, etc).

• Not all of us are born to be soldiers. Do we want to celebrate the success of the team as our own, or do we only look out for individual interest. If it’s the latter, I’m sorry, friend, but there is no place for you in the team, no matter how good a professional you are.

In the Scrum trainings, I challenge the development teams, and I tell them that for me, agility is getting up to production in less and less time. If before we went up to production every six months and now we go up every four, we are a little more agile. If we manage to go up a little more every two, until we can go up to production, several times per sprint, although some say that is impossible.

It is not worth using Scrum or any other agile framework if we have not reduced the delivery time. Nor is it worth it if I upload very frequently to production, if what I upload is not used by anyone (it does not add value). Remember Value and Velocity, I’ll leave it there.

Vision: We want to become a high performance team

Scrum Events

After talking about the roles in Scrum, we have to talk about a very important part that is the events, when we meet and why?

You have to have efficient meetings to minimize waste. The normal thing would be to invest around 12% to 15% of the Sprint in Scrum meetings. How long not? Much less than you would use in a traditional environment, I assure you.

Remind you that we work in small iterations of time (Sprints), of one month or less, in which an increment of «Finished» product is created.

In short, a lot. Within the sprint, we meet on the first day to see what we can do during the Sprint (Planning), we meet daily to see how we are doing according to plan (Daily), and at the end of the sprint we show what we have finished (Review) and reflect on it as we have worked (Retrospective).

In the retrospective, which is the last meeting of the sprint, I am very heavy on talking about what actions we have to take to improve as a team, and how it generates more value. In other words, if instead of 10 user stories per sprint we can get 15, what should we do?

In relation to the review and the retro I usually liven up the evening with a soccer example. I see the review as the team that goes out to play in front of thousands of people, showing their best game, and the public decides whether to whistle them or not (feedback), and the retrospective would be when the team goes to the locker room and they talk about what they are going to do. to do, so that the second part is better, in addition to remembering that what happens in the locker room stays in the locker room.

Finally, I also give a lot of weight to refinement. For me it is as important to finish a sprint well as planned, as it is to prepare the next sprint. It’s not worth finishing a sprint well, and the next sprint we don’t know what we’re going to do. Here I usually tell the story of the famous «woodcutter» that goes like this:

“A lumberjack goes looking for work, when the foreman interviews him, he sees a strong, motivated guy who wants to work and hires him. This lumberjack gets up the first day at 8 in the morning and spends 8 hours cutting trees and cuts 125 trees. The woodcutter when going to bed thinks, tomorrow I’m going to get up at 7 in the morning and I’m going to cut more trees than today. The next day at the end of the day surprised he sees that he had only cut 105 trees (how could this be). The angry lumberjack thinks that the next day he is going to get up at 6 in the morning to cut down more trees than ever before.

After the third day he only manages to cut 80 trees. On the morning of the fourth day, he goes to see the foreman and tells him “sir, I am going to leave my job because I am incapable of improving, worse still, I am cutting fewer and fewer trees”, to which the foreman replies “during these three days you have stopped at some time to sharpen your axe” to which the woodcutter replies “I don’t have time to stop, I have many trees to cut”.

Moral “In order to improve, sometimes it is necessary to see how we can adjust the process, and continue improving”

Scrum artifacts

Here the message that I give and I give a lot of cane is to the figure of the Product Owner, in the sense that they have a vision of the company’s strategy, that they have a tentative roadmap for two or three months (no more), and that they have least two refined sprints where the «there are no bad user stories but bad conversations» is fulfilled. The roadmap is converted into a Product Backlog, the commitment of what we are going to do is converted into a Sprint Backlog, and what we generate at the end of the sprint (value) is what we call increment.

I’m very weigh, weigh, weigh on having user stories the smaller the better, remembering things like INVEST or refinement techniques.

Summary of Scrum Training

Important, do not give too much information in a first Scrum formation with dozens of slides, it is better to show very basic information but easy to understand, and if possible with group dynamics. You learn a lot by playing, and on top of that it’s fun, take advantage of it.

Cheer up friend, and remember that the process of cultural change should be done slowly….