For a Successful Agile Adoption, Put Education First

Having a plan for your agile transformation is important. In this regard, there is no difference between traditional product development and agile product development—planning is everything. It is after the planning that things differ.

One of the valuable lessons in agile is being flexible enough to move things around, to challenge your own timing and preconceptions. This was never truer than in how my approach to education changed during the last agile transformation I worked on.

I was initially working with an organization of twelve to fourteen agile teams using Scrum and kanban. After an initial period of getting to know all the teams and the organization, I followed the conventional agile coaching wisdom and focused on just four teams. I would help a small handful of teams to excel, then move on to new teams and do it again.

The four teams were very receptive, and thanks to building trust early, we worked well together. They understood the principles, asked questions, and wanted to improve. The problem was that every time they started to move forward, something would come along to blindside them, throwing them off their cadence and out of the mindset. Sprint interruptions were one of the most common derailments, with the product owner, management, or the business completely changing the team’s backlog from one week to the next. The basic understanding that letting a team focus would get all the work done sooner just wasn’t there.

No matter how much I worked with the teams, they were not able to take their learning and grow with it, because the rest of the organization was still operating on a different set of values, goals, and objectives.

As a good coach should, I started asking questions across the organization. I found a wide variation in the amount of agile understanding, training, and acceptance. Even among those who had been formally trained in agile, there were large differences in understanding.

Education has always been an important component of my agile transformation plan. In the past, education was part of my one-on-one engagement with individual teams. In a large transformation, this could mean a team continued to operate in the old development model—or, even worse, in the new agile system—and not be trained for months or longer.

What I learned with this large-scale transformation was that when something is taught and who is taught is as important as, if not more important than, what is taught. Education is a vital ingredient in transformations, and it should be one of the first steps you take in moving to agile.

Start Everyone on the Same Page

In this specific case, we had a large organization that was made up of a half-dozen smaller companies, all of which had been doing some kind of agile—with wildly variable levels of understanding and adoption. To move forward, we needed some consistency.

Training shouldn't exclude or include based on background. For me, there are three key guidelines for an agile education:

1. Create a common vocabulary: I learned this well before agile. If everyone is using the same definitions, it's harder to get confused.
2. Come up with a consistent set of "agile basics": While every team will have different estimates, if they all learned the same way to estimate from the start, they will at least have the same common ground to work from. There are so many ways to do "agile" that having common training to call on will help prevent confusion as teams start to work together more.
3. Team-building, small and large, is important: Breaking a team out of its day-to-day push for hands-on, focused training gives members a chance to relax and jell as a team. At a larger scale, in a class of twenty, for example, you can easily have four different teams attending. This chance to work with other teams forms stronger bonds that carry over into work on real projects.

With this understanding, I took an abrupt left turn in my coaching plan three months into the transformation. After getting executive support, I spent six months and trained 150 engineers, managers, and product managers in a series of two-day agile workshops. The effects were immediate and positive.

Teams saw marked increases in velocity, the percentage of planned work that was completed by the end of the sprint shot up, communication between teams and with product owners improved, and, most importantly for me, engagement and happiness increased across the board.

One engineer summed it up best when he came to me at the end of a class. "I've been working on agile projects for over six years,” he said. “I've been taught the flow of Scrum more than once. This is the first time ever that I understand why we are doing agile." His team became one the highest performing teams in the organization, despite that engineer working in Israel and the rest of his teammates working in India.

One of the most visible indicators of the success of putting education first was in the metric of “planned to done.” This metric represents a team's predictability, showing how much they planned to do in a sprint and how much they ended up delivering at the end of the sprint.

When I started with the teams, not a single team had a ratio of more than 30 percent on any kind of consistent basis. Less than three stories out of ten that were planned were getting done in a sprint.

After training, every team saw a jump in planned to done. Six months after training had ended, nearly all my teams were over 50 percent all the time, with a majority regularly in the 75 percent to 90 percent sweet spot of predictability. The connection to education is high.

Tailor Your Content, but Don’t Cut Corners

After determining a need for education, the next obvious question is "What do you teach?" This is really a chapter all its own, with as many permutations as there are in the transformation itself.

I start with using the Scrum Alliance curriculum guidelines for a Certified ScrumMaster course. Then I have modules for some of the most common agile concepts not already covered in the CSM curriculum, such as kanban. At the start of every class, I run an exercise and we build a class outline together to meet their needs. There is always a core minimum viable product that ensures every class gets the same baseline, then additional modules based on that individual class’s interests.

Of course, every time the topic of education comes up, I get some variation of "We don't have time to take two days for training." This is typically followed by something along the lines of, "Can't you squeeze it all into half a day?" These objections come up so often in agile transformations that there are two common solutions used by agile coaches: the compressed approach and the piecemeal approach.

In the compressed approach, the curriculum is crammed into whatever timebox management provides. When you compress education, the biggest risk is in retention. This method almost always requires the heavy use of lecture and slides—and powering through them so you can get done in time. You may as well just ask the class to read the slides offline, for the value they will get.

In the piecemeal approach, the curriculum is broken up into small modules and sprinkled throughout the engagement. The teams never get into a rhythm or flow. We coach to do one thing when building, then try and teach the concepts of agile in little snippets around the other work. Again, retention is low, and it also means important concepts may not be taught until well after they are needed.

A highly interactive one- to two-day class, heavy on experiential exercises and team communication, will ensure that all key material is covered together and that retention of the concepts will be higher. And, going back to the key guidelines, this format leads to greater team relationships.

If you want your agile transformation to stick, respect the values of consistency, with both the terminology and the mindset; of building teams; and of putting in the time your teams need to lay a solid education foundation.