The case for trainings

 When coaching, especially in large organizations, I very often encounter teams and individuals who have basically been "pushed" into Scrum, SAFe, Kanban or LeSS without ever having attended a training course. While on the one hand, I advocate that "the real deal is what happens in the workplace", I want to make a case why training is absolutely mandatory for new agile organizations and even for those who are just going through a major change. In doing so, I would like to debunk the common "arguments" given by organizations against professional training.

Why not just learn on the job?

It's entirely feasible to successfully adopt a different way of working while doing it. That's how people who devised "Agile" also did it. But it's extremely slow and error-prone. And we re-invent the Wheel. And we may not spot our obvious problems until we hit a brick wall.

A classroom setting allows the trainer to create an environment specifically focused on a certain learning objective, and drive home the point. Encountering a similar scenario "on the job" without any a priori experience will make things appear more complex, which means that it will take significantly more brain power to comprehend.

Of course, an experienced coach will guide their coachees through this situation and the learning process as well, and they will do it in a practical working environment, connected to the real workplace environment. The time factor could easily be twenty-fold, though, because a lot more guidance, explanation and time for reflection is required when the basis just isn't there yet.

What happens in agile training

After this brief introduction, I would like to explore quickly what you get out of a good agile training:

Conveying knowledge

Teaching the roles, artifacts and events of (Large-Scale) Scrum or SAFe doesn't take long.

The formal rules of these frameworks are extremely easy, and it can be done in a few hours. Hence, the issue isn't in standing in front of a class and rattling down the material - the issue is in getting people to find an answer to their own question of, "what should I do?"

Aligning on Roles

It's important that people understand their own role is and that of the people they work with. For untrained people, that's one of the major sources of conflict, because there are unspoken assumptions and conflicts until we had an open conversation. A classroom environment allows people to bring three things together smoothly:

• Objective standards
• Their own personal understanding of their own role
• Others' understanding of their own role, especially interactions

Understanding events

There are numerous events in each framework. As a coach, most of the dysfunctions in practice I observe are related to people not having a proper understanding of the intent beind these events. A training environment allows the trainer to let people consider for all of these events:

• Scope
• Participants
• Agenda
• Intended outcome

With people who already practice a framework, trainers will often let participants explain how they conduct these events, then provide corrections and advice in order to help people get more value out of what they've been doing so far.

Constructing artifacts

Regardless of whether you're using an agile approach already or are transitioning from classic project organization to dealing with agile artifacts, the journey is extremely difficult for people who have no understanding on the purpose and contribution of these artifacts. A classroom setting will give people time to learn or reflect upon:

• Intent of each artifact
• Setting up the artifact
• Maximizing effectiveness
• Minimizing handling efforts
• Dealing with typical challenges

People are often amazed when they compare how they're currently working with the ease and seeming effortlessness with which a trainer uses artifacts in a classroom setting to achieve their purpose.

Experience Anchoring

As already mentioned above, the "knowledge" part is the simple part of an agile training. A proper agile training will spend a major portion of its time on creating an "anchor" - letting people try out the approach in a safe environment, so they can draw their own conclusions in comparing this with their own workplace environment.

Living the framework

Small simulations will allow people to try out their framework, and gain some experience with both the ups and downs of the new ways of working. Depending on what participants want to get out of it, they may either use the simulated environment to explore their own role and receive instant feedback, or they can try out a different role and build some empathy.

Communicating and learning

In a training environment, it's expected that people use each exercise and share with the group what they learned, what they would like others to be aware of, and what they would like to keep for the future. This is an extremely good habit for adaptive ways of working, which oftentimes doesn't happen on the job, because people feel it's out of place or don't have time.

Subtle learning

When people don't understand an instruction in a training environment, they will typically just ask the trainer. In the working world, they would often lack the courage to speak up and just try to get through somehow, the problem will only become obvious in retrospect. A training allows people naturally adopt the benefits of the Scrum Values, such as Openness and Courage, and a good trainer will drive home the point that they're already doing it!

Team Formation

Probably the most underestimated aspect of an agile training, and also the reason why I advocate bringing in a trainer rather than sending out people to role-specifics training, is team formation. There's a huge difference in performance between a group of individuals working on the same project (product) and a team (or: team of teams).

Over the course of the training, a trainer can form groups of trainees as teams who will have had ample time to discover and work out the important aspects of their future collaboration: who can expect what from whom, how they will organize themselves - and what is important when. After such a training, people will be pumped and ready to rumble without delay.

Just the benefit of having had people spend a few days to sort out all of their misunderstandings and find a common way forward can pay for a good training with ease: The formal knowledge gained is just the icing on the cake.

Flawed arguments against training

I would like to dissect the most common arguments given against bringing in a trainer and having people attend a formal training, because I believe that there are very, very few solid reasons against kicking off a new agile unit with a good training:

Common reasons

I hear all of these arguments commonly, and none of them hold water when you think about it a little closer:

The cost argument

"People know the price of everything and the value of nothing." - Oscar Wilde

The training costs too much

You will pay for the training one way or another: If you would "save" on the training, you'd have to do it with coaching, parallel to work, and therefore, over a prolonged period of time. The time lost due to friction until people are settled as a team and have found their way to collaborate and contribute will typically exceed a month ... and now think: how much will you spend on coaching during that period?

Effectively, you've got to do the same thing, with the only difference being whether you do it in a classroom or in parallel. The cost will be the same.

We don't have budget

A common problem, specifically in large corporations' IT department. It comes from a cost accounting structure. You may have budget to "do work" (CapEx), but not budget to "set up doing the work more efficiently" (OpEx). It's a dilemma. The solution rests in TCO - total cost of ownership. 

Going the right direction after a training will be faster and cheaper than figuring things out first. Even if you save just 1 Sprint on whatever you intended to do by setting up a training - the gains are X salaries for 1 Sprint, which should be part of your overall budget. 

Start thinking in terms of throughput accounting: if you spend $100k to build something, or you spend $80k to build something, the second option is cheaper. Except that "under the hood", option 2 used training, whereas option 1 burnt the budget on "doing": Does it even matter?

You have the money. You just don't see how you should be allocating it.

People are too busy

Of course they are. Because of your current ways of working. Which is what you want to improve.

If things don't work, why would you want to keep continuing doing the wrong thing, rather than making a full stop, resetting - and starting off with full speed in the right direction?

Other Priorities

This tells me that your organization has a priority issue: If "other things" are more important than coming together to introduce a more effective way of working - then your organization doesn't understand or appreciate effectiveness. We can use the training to set the baseline for fixing this issue, but we won't fix it by continuing to do what we always did!

We can't withdraw X people for 2 full days!

Imagine someone gave you an axe that allowed you to cut trees twice as fast, but it would take Monday and Tuesday to get used to. At the end of the week, you'd already have cut more trees. It's the same with your team(s). The only reason why you can't train them: because you feel the short-term cost is bigger than the long-term benefit. I call this "The tyranny of the Urgent." If you don't break free from that now - why would get better when your team has invested even more time working suboptimally?

As the proverb goes, "The best time to plant a tree is 20 years ago. The second best time is today."

We don't need it!

What do you say to a salesperson when you don't want to take the offer? "No." It's entirely acceptable. At the same time, would you say "no" to yourself when someone was literally offering you free money with no strings attached? 

To not spend money for something that costs you less than it earns you - is economic nonsense.

We'll figure it out by ourselves

That's entirely legitimate. I had the same attitude. And I did. It took me years. If you have those years ... great! Unfortunately, I don't think your comeptitors will wait for you to learn stuff that's well known while they start dominating the market.

People already know Agile

As mentioned above, a good trainer will not focus exclusively on objective knowledge. Instead, the training will form a team (of teams) of people who agree on a common, more effective way of working: If you already had this, why would you need a new way of working?

The flawed underlying assumption

Behind all arguments given against training is a single, unspoken common assumption: "We believe that training doesn't make much of a difference."

I would like to take a jab at this assumption like this: "If you believe your current ways of working are already (almost) as effective as what the trainer would teach you, why do you even want to adopt new ways of working?"

If you believe, however, that the new ways of working will make a significant difference, then I would suggest to figure out the value proposition of a training. Drop the fallacious arguments, talk purely about your needs and expectations.

If you need help building a business case for investing into training, we can do that:

The value of training

Before you think about "training or no training", ponder these questions:

• What's the biggest challenge we have, that we want to solve within our current way of working?
• How would the new way of working deal with this challenge?
• How much does this challenge currently cost us - ever day, every month, per year?
• How much would setting the groundwork with a brief training course help us shave off the current challenge?

The answer to these should help you formulate the business case for a training, and help the trainer manage expectations as well. If like this, you end up with a negative business case for the training, then I would - most likely - not suggest adopting a new way of working at all. The friction of switching ways of working would probably outweigh the expected benefits.

Once we've learned that training is a positive case, look for the following aspects in agile training:

• Will the training address the challenge(s) we want to improve upon?
• Will the trainer be able to relate our situation with the training content?
• Will trainees get specific impulses for things they could start doing differently tomorrow?
• Will the training equip people to apply their learnings outside the classroom?
• Will the training connect people on the work they will be doing? 

If the answer to any of them is "no", either talk again to the trainer or find a different trainer.

Once you are convinced that the answer to all questions is, "yes", then it should be a no-brainer to do whatever it takes to free everyone for a few days to get some proper training. 

Training vs. coaching

What I say in this paragraph is bad business for me - because I'm a coach: I have sufficient experience to claim that the needed duration for coaching - and thus the coaching expenses - will be significantly lower after people had training.

The reason why I say it regardless of the financial impact: the probability of change success goes up dramatically. This, in turn, means that the likelihood that you will discover the value in coaching will go up. And thus, the probability that you will speak favorably of my coaching will also go up.

An expericenced coach would be fully capable of compensating the absence of classroom training and formal education in the coaching work. From an expectation management perspective, I would still advocate for starting with training before coaching, because it's not an either-or situation.

Good training enables better coaching. "No training" means extra money for the coach, and more trouble. The best case scenario is great training followed by great coaching. It produces a win-win-win scenario: you learn more, you save money, and the coach will be more effective faster.

Factors to disregard

A lot could be said on bad decisions when choosing a training. I would just want to highlight a few factors you should simply disregard when deciding on training, because I see many people look for these factors, only to later complain they didn't get their money's worth.

Certification

I have some beef with certs, because - especially for introductory classes, which we're talking about - they do not certify competence. They certify attendance, and you don't need (virtual) pieces of paper. You need people to do work. If your training helps you to do work better, that's great. Certification is a gimmick. It adds no value to a course.

Multipliers

Many organizations are trying to save money by sending a few people to a 2-day course, who are then expected to act as "internal multipliers". One of the key benefits of training is to form teams who can immediately and effectively start working in a new way, You lose this benefit by dispersing people and introduce propagation layers. Those people who will work together should receive training together. And don't limit it to "managers" or "leads" - train everyone!

Standards

A canned and bottled curriculum is a double-edged sword. You need something that people can relate to, something that's actionable in your organization. As such, the trainer must at least be able to pick up your people where they are instead of merely playing off a script. If the script is flexible enough, it's not a disadvantage. Otherwise, the standard creates a problem.

Fun!!!

Training can have fun moments, but I'm highly suspicious of trainings that people unanimously call "fun": If you want fun, send people to Disneyland. Ignore the fun factor.

When a trainer actually breaks with your current paradigms, it will throw you into mental disarray. Anger, sadness and frustration can accompany a great training that really shook your beliefs about work. In some cases, it takes weeks or months until people realize what they learned. During that time, you might see people give both thumbs down on the training, which only shifts once the learning sinks in. Don't let high fun scores attract you to a training, and don't let lower fun scores detract you from it.

Conclusion

A good training will pay for itself - even when you're too busy, even when you think you already "know Agile". And even when you have no money. If the training isn't worth it, then whatever change initiative you're running probably isn't worth it, either. Hence, training can be a great lithmus test to see whether you should proceed.

You will save time, you will gain productivity, and you will also have a better bottom line when you achieve the same (or better) results after a training.