“Dear management, we’re already agile”

Agile is good, but we need management support for it“. “Agile adoption should start from management“. “Our agile adoption failed because management didn’t support it“. You hear it all the time, right? Indeed, such claims are everywhere. For example, 7th VersionOne’s State of agile survey says that in 63% cases initial agile champions were from management and also 31% says that management support is the biggest barrier for further agile adoption.
Well, it seems to me more like excuse then like a real barrier. People sometimes forget that bottom-up approach to agile adoption is all legal. Mike Cohn in his book Succeeding with Agile call it a “natural” approach.

I think that one of the reasons for such view could be that people don’t start from principles, but from practices. Starting directly from practices like Scrum could make you believe that you need deep organizational changes to start your agile journey. And organizational change needs, you guess – management support. What’s even more interesting that another reason is waterfall itself. To be more precise waterfall’s big upfront planning rule. It’s a kind of thinking legacy built into our brains that everything, including agile adoption, should be planned in details to succeed. And such big upfront planning and big decisions need, again – management.

Well, wrong.

Agility is a set of principles applied not only to an organization, but to people, too. Uncle Bob goes even further from here and says that “TDD is a personal decision“. Such a thought can be applied to some other practices and principles like kanban, pair programming, refactoring,…
Everyone should be aware that adopting some agile principles DOES NOT depend about management. I was a part of a team that tried and succeed in adopting Scrum without explicit decision and guidance by management. You can start tomorrow. No excuses!
It will happen that your manager will come back from some conference or training and will ask you to adopt agile. Put yourself in a position that you can say: “Dear boss, we’re already agile”.

How to Teach Agile Those With No (Bad) Waterfall Experience

Recently, I had an opportunity to give a series of agile development lectures to students. Since the differences between agile and waterfall was my main driver during my first agile days, I started with it. But soon, I realized that none of them have any waterfall experience. They don’t know how bad it is, so they’re unable to realize real benefits from agile development. Of course, they guess there are some problems like responding to a change, but they have never felt waterfall problem on their own, so were unable to “buy” agile at first.

Then I remembered my CSM course in Vienna. There were some people who started their agile experience since day 1 at their workplace. It was a different kind of people compared to my students, but very similar about their waterfall experience – none.  They were very positive about agile, so I asked myself what was their strongest motive to use agile. The answer was obvious – a practice. They learned and “fell in love” with agile by doing agile, not by comparing it to waterfall.

Then I decided to teach my students with as much practice as possible. We did a hands on lab to learn TDD, simulated a sprint zero at a real case and learned muda by optimizing their classroom environment. It turned out that they like it a lot. They seem to have “bought” agile principles in an easy way.

So, if you need to convince a group of people who are free of bad waterfall experience, don’t talk too much about differences between agile and waterfall. Save this story for those of our kind who were frustrated by waterfall. Instead, try to teach them agile principles by giving them as much practice as you can.