fbpx  

agile adoption

Create Agile Leaders First

Agile has been around for quite some time now. The big dogs, Scrum and Extreme Programming, have been around since the late 90’s, just a little over 20 years! Wow how time flies.

I’ve been teaching classes on Agile for quite some time now…just a little over 10 years. Early on, it was really just a Scrum class, but over the years it has evolved quite a bit to include Lean, Kanban, Extreme Programming, etc. depending on what is best for the organization.

Most of the time when I teach classes it’s for a company that’s already started their agile journey, as most claim they have. So going into each class I have some assumptions, primarily that management has a basic understanding of agile and understand their role in the transition. I also assume that the teams have some rudimentary understanding of the basic principles of agile.

However, during the classes I typically hear these kinds of comments/questions throughout.

  • Our Scrum Master is on at least 5 other projects.
  • We don’t have a Product Owner.
  • We have to track our time on every story, how do we do that in Jira?
  • We spend about 3 months creating a requirements document. Why do we need a Product Backlog?
  • QA is on a different team.
  • Management won’t let us add new stories until it goes to the change review board.

And the list goes on an on. Obviously they either started off on the wrong foot or they have lost their way.

How can we avoid this? Or, how can we course correct? The magic ingredient is to create agile leaders first, before you create agile teams. The best way to kill an agile transition is to ignore the role management must play.

Now, this isn’t an all or nothing proposition. I’m not saying “every manager must become an agile leader in this entire organization before we start working with the teams”. Heaven forbid. We need to approach the agile transition in an agile way of course! For example, if a specific division is chosen to start the journey, let’s begin by having some workshops and coaching with management in that division first, then we will weave in the teams. If you start with the teams while ignoring management, and tell the teams to “go forth and be agile”, management will not understand their role and will unintentionally become impediments. That’s where you get all the “Agile Sucks!” rants online.

Now, if a company approaches me for training to “make their development teams agile”, I let them know that they must start with management. I also let them know that training alone is not enough. Ignoring these two things almost guarantees failure.

So, what do you think? Should we start with creating agile leaders first or is it okay just to train up the teams, ignore management and call it a day? I’d love to hear your thoughts!

Trust

TrustI’ve been thinking a lot lately about what makes Agile work, and what types of things make Agile fail.

I like to strip things down to their smallest, most basic point. When I do this with Agile, I keep coming back to trust.

Many times Agile fails because leadership fails to trust the team. Or because team members fail to trust leadership. Sometimes it’s because team members and/or leadership fail to trust the chosen processes. Now and then it’s because team members fail to trust each other.

When Agile works, it’s because the members of the team trust each other. Leadership trusts the team. Everyone trusts the processes.

I do not think that Agile is such a difficult thing for people to learn. Agile is awesome because it is such a simple, easy concept.

I do, however, know that lack of trust can be a huge barrier to overcome.

I’ve worked with people who don’t trust. I can see them working against the team, reaching for their own goals, making assumptions that the team will turn on them if they aren’t somehow protected.

These are people who hoard responsibilities and avoid visibility. They chafe at requests for communication, and have a difficult time seeing the team as a unit with a shared goal, rather than as a group of individuals each working independently toward their own benefit.

I’ve also worked with people who have no problem trusting. People who gladly collaborate and who see the team’s successes as something shared, which everyone owns equally.

Sometimes it’s a personal thing, where an individual just can’t trust anyone – in any setting.

Often, however, it’s due to a culture of distrust in the business environment.

distrust1

We know that “culture” is a common barrier to Agile adoption. Cultures in the past – cultures which I feel are antiquated and outdated – have created environments where leadership must oversee every aspect of productivity. Where team members must account individually for their contribution.

That type of antiquated culture breeds distrust, and a lack of trust impedes a lot of other important aspects of Agile, such as visibility and communication.

If you want to adopt Agile, the first step is addressing your culture. Take a good hard look at the trust in your organization.

32B4EFC6-24B9-44B5-B86F3581785B6E39
Gone are the days when each person stood alone on their own pile of achievements.

Gone are the days when a success was owned by one person who was fast enough, sneaky enough, or powerful enough to put their name at the top.

Gone are the days when developers had to be monitored and babysat (usually by someone who had no idea what they were working on or how to tell if they were actually producing anything of value).

Gone are the days when we had to worry that if we didn’t hoard our tasks, someone else would step in and take them, getting that promotion or accolade.

Team-Events-For-Corporate-1
Today, we work in teams.  Each success belongs to a group of people.  (The team may choose to high-five one person who came through in a big way, but the “win” belongs to the team as a whole.)

Today, tasks flow freely through a group and you trust the person next to you to share your goals.

Today, visibility and communication have improved to a point where leadership no longer needs to bear down on team members in order to have an idea of where a project is in its development cycle.

Today, we trust our team members to self-organize, to create their own processes and choose their own tools.Trust is such a simple little word. We all know what it means, and I think we’d all like to do it.

The trick is identifying how your current culture – your processes, your tools, your relationships, your organizational hierarchy, and even the physical layout of your office space – creates distrust.

I am 100% convinced that Agile can work anywhere.

But without trust, it’s going to be a very difficult and painful process.

Talk to Us Today

barriers

 

post =