Sept. 10, 2015

3 Reasons Why Agile Training Is Not Enough

Agile has a tendency to throw surprises at you, and having a co-pilot with you can be invaluable

I just got off the phone from talking to a potential client about their agile transformation. They are looking to adopt agile practices across 4-6 teams, they have some idea of what they want (Scrum) and why (to speed up time-to-market), and are looking for some training. Just training. With the belief that that will get the teams to be agile. Please, no.

As a coaching company, of course we believe in coaching. We've  already written about  - why we train - as part of that coaching strategy. And there are many times that just training is an excellent strategy for an organization - to inject new energy into the teams, or bring new cohorts of developers up to speed with agile - all great reasons to just deliver training. But I get so frustrated when teams start their agile journey with a training and a handful of books or blogposts to go on.

Don't get me wrong - just training works. Almost too well. We know many agile teams that have launched successfully from a single training session. The teams are happy, and delivering working software. Management is satisfied. Product owners are getting product out of the door. So why am I so glum?

Here are 3 reasons training alone is rarely a good idea.

1) Missed Opportunity

Agile should blow your socks off. Teams that truly adopt agile outperform traditional product delivery by a lot. Unfortunately, many teams that use training to launch agile teams succeed, at least in comparison to their old way of thinking. They used just enough agile practices to be able to deliver working software with a little more transparency, and could make a case that agile was working. The frustrating thing is that they were barely in first gear. We often hear these companies see agile as an alternative to more traditional, sequential delivery methods, instead of a replacement. They see the two as similarly effective, and talk about projects suited to agile and projects suited to waterfall. This is so frustrating given the opportunity agile represents. It feels like driving a Ferrari but only ever in first gear. You're moving, but what a wasted opportunity!

Kid cars

Let's take the car-driving analogy a little further. I drive a Ford SUV. It's a great car, and gets me from A to B exceptionally well. No complaints. Mileage is good, the ride is good, and I can transport my entire family in comfort. I'd like to drive a Tesla Model X. Same car - an SUV. And I can match the performance of the Ford SUV without too much difficulty. So comparing the Ford with the Tesla, I might argue that they are equivalent. And I might then think about which trips to use the Ford on and which to use the Tesla on. But this is to ignore the innumerable benefits of one option over the other. In so many ways, the Tesla is incomparable to the Ford. Whether on performance, fuel efficiency or plain cool factor, the Tesla beats the Ford hands down. There is no comparison.

Those agile teams that reproduce similar or marginally better productivity than their old teams suggest old and new processes are comparable, when in actual fact, Agile practices will take you so much further so much quicker. But if you never get out of first gear, you'll never find out.

2) Burned Bridges

People have a limited patience for change. Asking teams to try agile 'one more time'  is going to meet stiff resistance or simply be ignored if there are too many bad experiences. Therefore, every attempt at change is important. A poorly executed transition creates a barrier for the next attempt. It's one reason our annual pilgrimage to get fit and healthy is so hard. We have so many failed experiences to look back on we simply don't have the energy or capacity to make it work 'this year'.

One client we worked with had trained the entire development organization and 'launched' many development teams.

By the time we hit the ground, there were a large number of teams that had tried agile, found out how hard it was and, for the most part, stepped back into their old ways of working. They were frustrated when the promises made in training failed to materialize quickly, and lacked the experience to be able to continually grow towards a more effective and productive solution. Those promises remained elusive and many people lost the belief that they could ever be achieved. Most of these teams rolled back to where they started from and stubbornly pushed back at agile practices introduced later on.

Teams have a lot of trust in decisions made, such as to adopt a new way of working. But each time these efforts fail to deliver, that trust is eroded and a barrier is created to future efforts. Training alone can leave teams with a poor experience that becomes that much harder to overcome in future.

3) Practice Makes Perfect

Experience counts. Agile is based on sensing and responding to situations. Each situation is different, and every response is based on applying well-defined agile principles. The art of continual learning is not a formulaic what- to- do-when, but how to tell whether what you did worked or not. Training is very effective for communicating how predictable, linear systems work. If you introduce a new accounting tool, or a new expenses system, the likelihood is that a training, both in person or virtual, will be enough to get everyone up to speed and using the new tool or process. Think of this as a one-to-one relationship - where possible actions are clear and unambiguous, training is sufficient.

Now consider learning to drive. We would never consider training alone to be enough. Driving is a completely different skill. We need to learn the fundamentals, and practice the core skills. But real competence only comes with lots of practice and, quite frankly, a little experience of what can go wrong, hopefully in the form of a safe-to-fail experience. Agile is much the same. Just like in a car, the fundamentals appear to be straightforward. A pedal to push here, a lever to pull there, and a steering wheel by which to steer. And just like learning to drive, agile has a tendency to throw surprises at you, and having a co-pilot with you in those early days can be invaluable in successfully learning how to use agile principles and practices in the workplace.

What next?

As agile software development becomes the norm in many organizations, at least in expectation if not reality, more and more teams are seeking training to kick-start their transformation. In many cases, training is the right answer. There are good reasons to refresh knowledge and expertise. It's one reason I still look for time management classes and books; a refresher of basic principles and a look at latest practices helps keep our skills sharp and relevant. I'm also always impressed at how many people I talk to understand how and why to properly manage an organizational change such as agile adoption. So perhaps this article is aimed at the budget holders and managers who mandate a change to agile, but then short-change it through a squeeze on resources, eventually settling for just a little training. Recognize why the results you expect might be slow in coming.

Photo iStock

Image of davesharrock

Dave Sharrock

Agile coach passionate about getting things done; helping teams exceed expectations, delivering organizational excellence, and all while having fun doing what they do.
blog comments powered by Disqus
Image of davesharrock

Dave Sharrock

Agile coach passionate about getting things done; helping teams exceed expectations, delivering organizational excellence, and all while having fun doing what they do.

Latest Posts

Jan Barnes joining agile42

Jan Barnes joining agile42 as an Agile coach in the Canada team

Image of davesharrock

Dave Sharrock

Agile coach passionate about getting things done; helping teams exceed expectations, delivering organizational excellence, and all while having fun doing what they do.

Mike Freislich on the inevitability of change

Video of Mike Freislich interview with Klaus Leopold on the Lean Business Agility podcast

Image of abragad

Alessio Bragadini

Web community manager of agile42, trying to post relevant, informational, fun bits of content on the blog and social networks

Agile Portfolio Management in it-daily.net

A new article in German magazine it-daily.net

Image of marion

Marion Eickmann

I am one of the founders of agile42. Even though I am not an engineer I consider myself almost a "Techi" as I have been working in the field of software development for 10 years now.

Why Agile Transformations Fail – Do You Fall Into The Same Pitfalls?

Insights from TAC2017: Why do agile transformations fail? Identify whether your team or organization falls into the same pitfalls.

Image of hwong

Hazel Wong

Marketing Assistant at agile42. Passionate about gaining insights from data in order to create content that resonates with the audience. Eager to help teams and companies open their mindset about the application of agile methods to address their challenges.

Sponsoring Let's Test South Africa

Let's Test South Africa 2017 sponsored by agile42

Image of joperold

Joanne Perold

Agile Coach in South Africa. Explorer, learner, experiencer, part time philosopher, working with teams and organisations to be more agile.