I taught an Agile Training course recently and felt I did a pretty good job. When I reviewed the participant feedback, not everyone agreed. The feedback was mostly positive, though one comment stung:
This presentation felt like a reiteration of the scrum guide. In order for the course to be of value, I expected it to be tailored to our experience and have meaningful contributions that are not easily and publicly accessible.
— Training Participant
This person thought my training was a restatement of the Scrum Guide.
It wasn’t. But now I am being defensive.
It is easy to feel disappointed or hurt by feedback. And I like to say that feedback is the breakfast of champions.
So what can I learn from the feedback? Here are my key takeaways:
- People want customized agile training
- Training participants want insider information
- Some people focus on the tool
- Some people learn better on their own
- People’s experience is their reality
People Want Customized Agile Training
Most people think that they are unique.
They believe that their company and context are specific and different. And each person has different learning needs and often a wide range of experiences.
I agree that the training should be custom and specific to them. I don’t want to provide training or information that is not pertinent and valuable.
It is desirable but difficult to tailor training to a specific group. As an outsider, how can you fully understand the context and nuances and customize your training to each group? Is it feasible? The attendees are the experts on how they do their job. How can I possibly tell them how to do it better?
Agile Training Participants Want Insider Information
There was another comment in the feedback that stung a little. The person wanted training that included “meaningful contributions that are not easily and publicly accessible”. I had to think about that for a moment.
It was hard to imagine that my training would include proprietary information or insider tips and tricks. That is because of the nature of Agile. Agile itself is open. There are thousands of books on agile. And there is plenty of information about agile that is free including blog posts and YouTube videos.
I view my role as an agile instructor as a curator of all that widely available and free information. I want to provide participants with the insights and capabilities they need to hit the ground running based on where they are.
But that is defending. And I am defending when I point out places where the training was specific and unique. Product Backlog Refinement. User stories. The Sunday School Rule.
On reflection, this part of the feedback is excellent. I want to provide excellent value by sharing my insider tips and tricks.
Some People Focus on the Tools
Another participant from the same training session commented that they wanted to be taught how to use Microsoft’s Azure DevOps in the training. (They hadn’t used ADO prior to that point.)
I could defend. I could point out that I focused on the principles behind the activities and not the tool. I could point out that the first Agile Value is Individuals and Interactions over Processes and Tools. But that may not help them to get their job done if the tool is difficult to use.
Mastery of tools is important. You will be slower and less productive if you are fumbling around trying to figure out how to create a backlog item.
And frankly, I don’t think Microsoft made the mastery of the tool any easier by building Azure DevOps with so much capability. There are 6 different ways to accomplish each task in ADO. And each person and team may select different settings making rendering any type of organization-wide metrics unusable.
Even the basics of ADO can be challenging for new teams. Is this new request a backlog item? Feature? Epic? Does it matter?
The bottom line is though I don’t like to or want to teach how to use tools, that would be valuable to my training participants.
Some People Learn Better on their Own
I cannot dismiss the comment about reading the Scrum Guide. Not everyone benefits from sitting in a classroom. Some people just learn better on their own. And as noted, the 2020 Scrum Guide just has about 12 pages of text.
Even if you alternate between lectures, exercises, and discussions, you still have some participants who don’t learn well in that context. How do you structure training so that these people don’t feel like hostages in the classroom?
You don’t do it by keeping people in a classroom for two straight days!
When I reflect on other classes that I have taken, they allow me to learn on my own timeline. The best ones feature a combination of lectures, discussions, exercises, videos, and reading assignments. Participants are able to learn in ways that work best for them.
And for me, that sometimes means going down a rabbit hole on a particular topic that interests me. I will often pause a video to Google a term or look up an author.
I consider myself an autodidact, a fancy way of saying self-taught. I prefer to read a book rather than sit and listen to a lecture. I don’t know how many people are like that. I know that George Washington, Thomas Edison, Ernest Hemmingway, and Abraham Lincoln were all autodidacts.
Good training will accommodate those who are self-taught. This can include pre-reading assignments. It can also include pointers to additional reference materials so students can do their own deep dive and learning.
Experience and Perception are Reality
Back to the comment about the Scrum Guide. The training was not a reiteration of the Scrum Guide.
Sorry if I sound defensive but it wasn’t even close.
About 25% of the content of the training course I delivered was focused on the Scrum Framework. So yes, one could argue that some of the content can be found in the Scrum Guide.
The remaining 75% of the training covered the following topics which are not covered in the Scrum Guide.
- Agile Manifesto
- XP, Lean SW development, and Kanban
- User stories
- Backlog refinement
- Any roles outside the 3 scrum roles – managers and leaders, subject matter experts, etc.
Those who are familiar with the Scrum Guide would know that the 2020 Scrum Guide has been pared down to just the essentials. It is a 12-page document that focuses on the values, principles, and ideas of Scrum. It is not a detailed guide on how to use Scrum.
In fact, many books have been written about Scrum to help people better understand and apply the Scrum Framework. In addition to the books written by Scrum co-creators Jeff Sutherland and Ken Schwaber, there are a few other books that I have recommended in my Best Agile Books article:
- Essential Scrum, Ken Rubin
- Fixing Your Scrum, Ryan Ripley, and Todd Miller
Reading the Scrum Guide is a great start but it would be insufficient for Teams, Scrum Masters, and Product Owners.
That is all great but it doesn’t really matter if participants don’t understand this. Their experience is their reality.
Classroom Agile Training has Other Value
Whether or not the content is taken from the Scrum Guide, there is immense value in classroom training. It allows us to get on the same page with a common language and common understanding.
Classroom training also helps teams with their interactions. All the exercises we did in class were team-based. Since most of the teams in the room were new to working as a team, the engagement among team members provided an opportunity to begin to mature along the forming -> storming -> norming -> performing continuum.
And let’s not forget the importance of interactions. They are called out in the four Agile Value statements:
Individuals and Interations over processes and tools
Agile Manifesto, 4 Agile Values
We know that two people can read the same document and come away with different interpretations. That is probably why there is an agile principle that emphasizes the importance of face-to-face communication:
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Agile Manifesto, The 12 Principles Behind the Agile Manifesto
I would also argue that the classroom exercises provide an opportunity to learn while doing and help create consistency across the team. And frankly, some people learn better by doing.
The Bottom Line – Agile Isn’t Rocket Surgery, But You Should Hire an Agile Trainer
The concepts that we cover in agile training are straightforward and understandable, for the most part.
Sure there are some lean principles that may be counter-intuitive at first. Developers often come into training thinking that their own productivity and efficiency are more important than working as a team. They confuse efficiency with effectiveness.
Or they often think that it is more effective to make all the changes (in a big batch) while you have the hood open on the car, instead of making small changes.
Or they believe that getting more things started will result in more things getting done. Or that daily priority changes are OK and not counterproductive.
So there are a few ideas that are counterintuitive. Otherwise, I don’t want to make it mysterious, difficult, or hard to understand. I want to de-mystify it as much as possible.
And yes, lots of people have used the Scrum Guide (or less) to get started as an agile team and they have done just fine without hiring an agile trainer.
But just as many have attempted Scrum and found themselves using a bunch of anti-patterns. The Ripley and Miller book I mentioned above, Fixing Your Scrum, became extremely popular because it is written to address those anti-patterns.
Should you hire an Agile Trainer? Yes! I am biased, of course.
Can you read the Scrum Guide and use Scrum effectively? Yes! Can you hire an agile trainer and use Scrum effectively? Yes again! A good Agile Trainer will help you accelerate, understand the underlying principles, and move more quickly from forming and storming to high performing.