Doing Agile vs Being Agile

doing agile vs being agileDoing Agile is not the same as Being Agile according to Michael Sahota and I couldn’t agree more. Doing Agile can be learned in a 2-3 day class that teaches the basics of Scrum and Kanban. Being Agile requires much more: a cultural shift to an agile mindset as well as changes to the way employees are managed, motivated, trained and hired.

There’s no question that Doing Agile by itself leads to certain benefits: improved communication and visibility to what each team member is working on, some increases in productivity and perhaps the ability to set priorities with intent as conditions change.

But the transformative benefits occur from Being Agile, by which I mean consistently, predictably responding quickly in the face of change, delighting customers and achieving excellence through engaged employees all working together towards common goals.

What does it take for marketers to achieve Being Agile? Here are some ways your team can move towards this goal.

Self-Managing Teams

Scrum prescribes that teams be self-managing, but in my experience this prescription is seldom followed. It is critical for managers in an agile environment to get out of the habit of giving orders and of having all the answers, and instead give both authority and accountability to the team. Strangely enough, this can be harder for team members and middle managers than for organizational leaders.

In a top down organization, employees are trained to seek approval for every action.  Managers are the answer men (or women) and the approvers. Some employees and some middle managers will be adrift in an organization where decision making and responsibility are pushed down to the lowest possible level. Employees will feel adrift because they are accustomed to being told what to do. This doesn’t require thinking and responsibility is shrugged off with the phrase “I was just doing what I was told”.

Middle managers will feel adrift because they formerly saw their job as translating orders from above into “managing their team”, which meant telling them what to do and checking back frequently to make sure that they were in fact doing it.  Middle managers also spend a lot of time in meetings approving initiatives or decisions brought to them. If this goes away, what is the role of the middle manager?

The Role of Management in Agile Organizations

To achieve Being Agile, managers must take on a new set of responsibilities.

Providing Clarity of Purpose

I’ve recently been teaching Intent-based leadership as described by David Marquet. David describes the two pillars of intent-based leadership as clarity and competence.  Leaders must clearly communicate purpose and the current major goals of the organization. Their job is to ensure that every member of the organization has clarity on that purpose and those goals.  This is not easy.

In many organizations, I’ll ask them “what is the purpose of this organization and what are the top 3-5 goals at the present time?”.  Sometimes I get confused looks, sometimes I get multiple conflicting answers from different people in the organization, and only once in a while do I get the same clear and consistent answer from everyone in the organization.

Teaching Competence

Giving a team member responsibility for performing a certain function isn’t going to result in success if the team member doesn’t have the skills to perform that function. Another responsibility of the manager in an Agile organization is to teach. Rather than make decisions or approve decisions, managers in an agile organization should teach people how to make great decisions.

David Marquet has a great example in this video. Normally, only the captain of a U.S. Navy submarine can give the order to submerge. The reasoning is that the captain is ultimately responsible if anything goes wrong.  David Marquet wanted to give his officers authority and responsibility for submerging the ship, but of course he also wanted to ensure the safety of the ship. So it wasn’t enough for the officer to state, “Captain, I intend to submerge the ship”.  They also had to ensure that it was safe: all the crew members were below decks, all hatches were closed, the ship was rigged for diving, the bottom was deep enough, etc. Eventually, the officers would say, “Captain, I intend to submerge the ship, all crew members are below, all hatches are closed” and so on, convincing the Captain that it was safe.  In other words, the Captain passed off his competence to his men, and they in turn to their men.

When every employee makes decisions as if the CEO was looking over their shoulder, consistent with the purpose, goals and values of the organization, you’ve achieved Being Agile.

Rapid Iterations with Learning Intent

One of the core values of Agile Marketing is “Rapid iterations over big bang campaigns”.  When I teach this, heads nod and everyone seems to think this is a good idea. But implementing this in practice seems to evade many teams.

To achieve Being Agile, an organization must build a high tempo testing culture. When people hear this, they often think this only applies to search engine marketing or perhaps testing a few display ads and their click thru rate. You know this is the case when you hear, “Oh yeah, testing, that’s the responsibility of the testing group over there”.

Rapid iterations with learning intent applies much more broadly than simply testing a few ads.  It means that marketing approaches everything with the attitude that we’re going to get something out in front of customers quickly, gather their feedback, and iterate our way to success.

This requires a mindset of learning intent and a relentless focus on delighting the customer through constant improvement. It also requires that teams measure their tempo. How many tests a week are we performing? How long does it take us to build a new campaign? How rigorous are we being in terms of stating our hypothesis up front and making decisions based on customer feedback?

I hope this helps. I’ve found the distinction between Doing Agile vs Being Agile to be very helpful in my coaching, and I’m challenged every day to help organizations achieve Being Agile.


  1. Jim, I also agree with you on the difference. Unfortunately, as it happens with a lot of other “trends” many many companies believe that “Agile” can be just transferred in 2 – 3 days workshops. It is just frustrating to see managers “trying to do agile” that threat their own people as “computers” and expect that “Agile OS” will be installed in just a couple days after the workshop.

    Doing Agile is not the same of Being Agile.

    • Alberto, that’s right and a good analogy. It’s not like installing a new operating system. The other thing that executives in particular are often slow to comprehend is that being agile requires change on their part, in terms of how they think about their jobs and how they interact with their people. They have to stop doing some things (micro-managing, business reviews which are really giving permission meetings) and they need to start doing other things (providing great clarity on the key initiatives and making hard trade offs on priorities, as well as increasing the competence of the whole team through a combination of hiring and training). Thanks for the comment.

Speak Your Mind