As an Agile Trainer and Coach, I find an interesting paradox. Most people will state that they already know all about Agile. And if asked, most organizations will say that they are already using Agile, even if it is A.I.N.O. (Agile in Name Only). Or they will describe what they are doing as "agilish". I am pretty sure that "agilish" in this context means that they aren't following Agile Values and Principles. And in most cases, it also means they are doing pretty much what they were doing before agile but now they call them by agile sounding names. And they don't need or want Agile training.
This creates an interesting problem for me as an Agile Coach. You say you already are using and know about Agile, right? And you say that you don't need or want any type of training on Agile or Scrum, right? Are you sure you are a good judge of your Agile knowledge?
People aren't great at evaluating themselves. We all tend to overestimate ourselves and our talents, traits and abilities. We feel we are smarter than the average person, or more generous or whatever. The truth is that we don't see ourselves or others accurately. This is a known type of cognitive bias called illusory superiority
So probing for Agile Training and Coaching needs can be tricky. Frequently, managers, leaders and executives of all stripes feel they already know enough to succeed with Agile. Is it possible they learned everything they needed to know about Agile from that Forbes magazine article or from hearing a colleague speak about it at a conference?
If an organization is using A.I.N.O. they might get ticked if you tell them they need Agile or Scrum training. I've had internal agile champions tell me that their leaders believed that they have been practicing Agile for years. They asked me not to mention the need for Scrum training because they had been telling their leaders that they had already been using Scrum. So please don't mention the need for training. Huh? You mean you want me to lie about the current state just so someone doesn't get upset about the truth?
I've also run into client situations where team members were taught or told things about Scrum and Agile that were inaccurate. What do I tell team members who have been taught to use "Sprint" to describe waterfall phases, as in the Analysis Sprint, the Development Sprint, and the Testing Sprint? I have to do my best to not scream out: "That crap you were doing before wasn't agile!" Sometimes I am diplomatic and I tell them that they need to adopt a more disciplined form of Agile or Scrum.
Unfortunately there is no standard assessment for measuring Agility (and if there were I'd be suspicious of it!). So I find I that early on I need to spend a lot of time just asking questions and helping people understand where they are today. I also try to cast a vision for what they might gain by making changes and improving their processes. I talk about the benefits that they've hoped for that they aren't realizing. Here are some typical talking points:
- All the Costs and None of the Benefits - The biggest justification for training is that you are misusing Agile and Scrum, incurring the costs, and getting none of the benefits. By continuing to use old patterns and simply adding a daily standup and calling things sprints, you can actually add more overhead to a poor process. People will become jaded if they are told they are self-organizing but continue to be assigned work from multiple projects with conflicting priorities and deadlines.
- Avoid Confusion and Thrashing - Even when done well, teams can often be confused about how to proceed and waste time thrashing on team processes. Training helps to avoid this by getting everyone on the same page with both the "how to do agile" and "how to be agile" or the mindset and philosophy behind what they are doing.
- Unlearning - Most of us already know all about Agile, right? Even when we don't, our minds fill in the blanks about what Agile is without our even knowing it. An easy example is the Scrum Master role. Even though the Scrum Guide is clear in describing the Scrum Master as a process coach, impediment remover, and facilitator if needed, most everyone equates this role to the project manager and they believe that the Scrum Master also does everything that the project manager would do. So a big part of my agile training is to help people to unlearn things that they think they know.
- Make a Realistic Assessment of Where You Are - It is difficult to change without a realistic assessment of your current state. There is an old saying that the first step is admitting you have a problem. Without a clear idea of where people are today, there is no way to successfully help them get somewhere else. Training can help people to appreciate where they are, and what they don't know. Or as in the previous example, what they believe they know that simply isn't true.
- Avoiding the Agile Mish-Mash - Many times I find that team members bring their experience from other areas or organizations into their current team. They end up with some sort of agile frankenstein by including various practices or tools. Everyone wants to believe that what they did at company XYZ was the way it should be done.
- Poor Agile and Bad Scrum Hurts Others and Becomes the Standard - New teams that get stood up and use "agile" keep propagating the same bad patterns and mistakes from previous teams. The "norm" for Agile in the organization will just continue to get worse. Training can help people to overcome the bad patterns and to create more effective ways of working together.
- Facilitate Change and Continous Improvement - If people see that Agile and Scrum are effective ways of working when used properly, they will be open to learning about other improvements. They will become more open to change and trying new things. The alternative that I have seen is when Agile and Scrum are used against people, they become more resistant to change. They simply put their head down and wait out the proposed change, instead of embracing change and continous improvement.
Finally, I help them to think about experiments they might do to move them toward their goals. Maybe they will try a training pilot with a team, or take a team that is thrashing and conduct "refresher" training.
Another area of low hanging fruit is whether those people who are being asked to support teams as Scrum Masters have actually had Scrum Master training. Getting the CSM or PSM Scrum Master Certification is pretty easy, and taking the training to get it is a pretty low bar for someone acting in a leadership role. (Read more about Scrum Master Certification here).
A Quick Self-Assessment
- Are your "Agile" practices a lot like the practices you were using prior to becoming Agile?
- Have you used any any objective tools to gauge your agility? (BTW, we have Agile Health Assessments and Scrum Maturity tools)
- Have you brought in outside experts to assess the approaches you use? Have you benchmarked with other firms?
- Do you or your people attend Meetup's, conferences, or outside training sessions?