How to Build True Agility With your Team

Agility as a term has been overloaded with multiple meanings, especially from the software development perspective. I define agility simply as the ability to change your perspective, your worldview (or orientation as Boyd would put it) and your actions to adapt to what’s happening in the real world. There are two key ideas in that definition. The first one is about change and the second is about adaptability. You need to be able to do both if you have any hope of being agile.

So how do you create agility in your team so that you can respond quickly when the situation changes? Suppose a disgruntled customer tweets something negative about you, and then on top of that he buys an ad that will promote that tweet to 20,000 twitter users. How long will it take you to respond?

It happened last year when a British Airways passenger, unhappy that the airline lost his father’s luggage, sent out a promoted tweet about their customer service being “horrendous” It took BA more than a day to respond to the customer. By then, the tweet had been picked by several media and news outlets. How would you have handled this if you were running the social media team at BA?

If you’re like most companies, you’d have to first find out. if you don’t have the necessary tools in place to get notified when something like this happens, you will unfortunately find out too late. This is the Observation stage of the OODA loop which I wrote about here. Assuming you find out early enough, you might have to go through a lot of bureaucratic red tape getting approval and sign off from everyone involved before a response is set in motion. Not very agile.

If your team was agile, you’d be able to respond a lot quicker and nip that negative publicity in the bud before it starts to spin out of control. Lets take another example. Suppose you notice a problem on your company’s website that is severely affecting conversion. You enter a support request. How soon can the problem be fixed?

If the web development team was agile (and I don’t necessarily mean that in the sense of following agile project management practices) someone can be pulled off of whatever they’re working on to fix the issue quickly. More often than not, the issue will go unnoticed for weeks, if not months and even then, it will take more time to be properly fixed.

So how do you become more agile?

Here are some of the principles of the agile software development manifesto. Let’s analyze them and see if we notice a pattern.

  1. Your highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  3. Business people and developers must work  together daily throughout the project.
  4. Working software is the primary measure of progress.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

What do you notice?

What do you get by satisfying the customer through delivering continuous valuable software on a regular basis? What do you achieve by working together with the business? What do you get when your measure of success is working software?

You get Mutual Trust!

What do you achieve by working with a team of motivated individuals who have the environment they require and the support and trust they need to get the job done? What do you get by communicating face to face and welcoming last minute requirements changes?

You get: Mutual Trust and Cohesion

And what do you get when your single point of focus is delivering quality software at all costs?

You get true Agility!

If you study the OODA loop in my previous post, there’s a part of it specifically about implicit guidance and control. This means that there could be a point where you don’t need a formal process to actually get something done. A coworker recently mentioned that they had gotten so good at working with the developers that they no longer needed to discuss things formally, a lot of design decisions were made and communicated implicitly. This allowed both the designers and the developers to operate quickly and get things done faster.

The first element is: Mutual Trust

In order to get to this level of operation, where the team knows exactly what to do and when to do it, the first element you need is mutual trust, unity and cohesion. Not just any type of trust, unity and cohesion, but the kind that is earned through working together through many different projects.

Of course it needn’t be said that at the same time, the team needs to also spend time together outside of the context of work. This will help them get a sense of how everyone on the team thinks and allow them to build that level of trust.

In order to achieve that kind of unity and cohesion, both parties need to be striving towards the same goal. And so the second element you need is the concept of a single point of focus. The idea with single point of a focus is that all the surrounding activities must support it and everyone involved, not just everyone on the team but also the rest of the company, needs to understand, support and work towards this focus.

The second element: Single Point of  Focus

When team members in different departments do not have a single point of focus, they will focus on creating silos and protecting their department’s turf. This is a sure-fire formula to get organizational politicking, power plays and turf wars and lots of bureaucratic red tape. 

How to destroy agility (or what not to do)

The easiest way to destroy agility is to mistrust employees by not believing in their ability to make their own decisions about what’s right and what they should pursue. When things are going great, there’s lots of trust in the team, but when sales start to shrink, many companies feel they need to pull the controls upstairs and start to manage by directive rather by mission.

One of the ways to communicate distrust is by micromanaging. When you micromanage, you are checking everything your team is producing and if you’re not satisfied, you probably end up even doing it yourself. This is very common and it’s a horrible way to manage people. I’ve been there before and it’s not fun. After a while you lose any desire to produce quality work that you can pride yourself on and you lose any initiative you may have had.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s