Most organizations today have tried Agile approaches and the majority are finding them helpful. There are a significant number of people for whom Agile has not been helpful or it hasn’t worked. Or, they tried it but they did not get the benefits that they had hoped they would get. When I peel back the onion, I hear some of the same reasons for Agile not working.
A common question I get during my Agile training courses is what is the difference between Agile Adoption and Agile Transformation. It's a great question. I see five key differences worth talking about.
But first let's agree on our terminology. These are my working definitions for these two terms though I realize that people don't use these two terms consistently.
I met with some of the key internal champions for Agile at a client recently and they asked for my help. They have been trying to encourage the Agile and Scrum teams in the organization and mature their practices and they found that their teams had hit a wall and were not progressing. It was as if they had run into a brick wall.
That brick wall was the executive leadership team. The leadership team said they wanted the benefits of Agile, but frequently acted in ways that undercut the agile teams. The attitude of the leadership team seems to be:
I work with a lot of teams and help them to adopt Agile thinking and methods. While I am pretty passionate about Agile and many of the team members are as well, I work with many team members who are afraid of Agile. Why would people fear Agile if it is such a great thing? Perhaps it isn't viewed as such a great thing by everyone. Here are some reasons why they might fear agile and 'being Agile'.
#1 Change of Any Type is Difficult
In a happy coincidence of events, I achieved my Certified Agile Leader certification from the Scrum Alliance last week. I was researching agile transformation and came across Michael Sahota's book, An Agile Adoption and Transformation Survival Guide. I really liked the book and so I invited him to connect on LinkedIn. In a bit of serendipity, Michael responded that he would be in Chicago to teach the Certified Agile Leader course on September 22, and he invited me to attend his course.
It is an interesting conundrum - managers and leaders say they want to be more Agile, yet they are usually the ones who are responsible for putting the brakes on further Agile Adoption. It is a lot like me saying that I want to get 6 pack abs but I don't want to exercise or eat healthy food. What I say is not aligned with my actions.
So why do I say that managers are putting on the brakes on Agile? Well, first it's because it is what I've seen happen at one organization after another. Managers and leaders control what is happening - directly or indirectly.
Last week I posted that I thought one of the most common reasons that people say Agile did not work for them was the inability to colocate teams. Several people commented that they thought I missed the boat (which is quite possible) and that the most common reason that agile doesn't work is that managers cannot change their command and control behaviors and create an environment where people can do their best work. I agree.
Most of the clients who seek out our help ask about Agile adoption. They usually have a couple of teams developing solutions using a traditional approach, and they'd like them to begin using Agile. For them, it is just a process change. They want their teams to develop faster, or to collaborate closely with the business people. Or they want a simpler process for introducing change that is fast and allows them to be more responsive.
A key part of an Agile Transformation for an organization is forming the development teams. The starting point for most organizations is typically a functional organization such as developers, business analysts, and testers who report to their respective managers. It is common for each person to be assigned to multiple projects. So how do we go from that to having dedicated team members on cross-functional teams?