No, your team is not agile.

If you are reading this, you probably are one of 3 people:?

1. You are in a leadership or management kind of position; lets agree that your name is Jane.
2. You are part of an approx. 8-person team, working hands on together to build some kind of software or IT application or even a part of a machine; lets agree that your name is Bill.
3. All others; let’s agree you have your actual name. (FYI, in an effort to make this argument without rambling, I shall mostly be referring to Jane and Bill.)

Okay, let’s go. 

Hello Jane, hi Bill, I think it is safe to say your team has just completed or is currently well on its way undergoing an ‘Agile Transformation’. 

Jane; you probably hired a bunch of consultants who came in and facilitated a week long ‘agile’ boot-camp with your people, explaining to them the fundamentals of ‘agile’ and how it will change your organization forever. You are probably pumped.

Bill, you probably were one of those who got pushed in to a room with this guy called a 'Certified Scrum Trainer', who then proceeded to preach to you the ‘scrum’ gospel for 16 hours in 2 days, at the end of which you took a 30 minute exam and all of a sudden you became a Master…a Certified Scrum Master! You even got a certificate and a license number, wasn’t that just awesome?

Now your days are filled with these new meetings, where everyone gets to talk, and the air is light, and you really feel like your voice is being heard. 

One new meeting, the ‘daily stand-up’ is so short that you loved it at first, but then you are beginning to wonder of it really makes sense to be checking in with Mike in regression testing every day. I mean  how many days is too many days in a row to have one guy say he is working on that test script from last sprint?

Anyway, best of all, you have this ‘sprint planning’ meeting where you get to sit down with Ashley—Project Manager turned Product Owner—who now simply has to clarify for your team what exactly it is she wants built, and then leave it to the team and Donnie—Business Analyst turned Scrum Master—to actually figure out how long is going to take for guys to have this done. No more gantt charts, or excel books with unending sheets detailing the project timelines and those red cells showing that the team is behind schedule.  You now have the autonomy to size up tasks and set priorities with Ashley, but she really can’t make you cram too much in to one sprint. I mean she could try but you will be quick to point out that that is an ‘agile anti-pattern’, (as the ‘Agile’ consultants said) and it completely defeats the vision to ‘Go Agile’.  

Notwithstanding this new autonomy you have, you still have the responsibility to show, or more –appropriately ‘demo’—something every 2 or 3 weeks. But then the expectations of that demo were set based primarily off of how fast your team delivered features last sprint, something Donnie insists you call the 'team velocity'. This means you are expected to only improve on what you did last time, and if it happens that you aren’t able to improve this velocity, for whatsoever reason, Ashley just has to deal with it. I mean the consultants did say ‘going agile’ takes time, right?

Jane & Bill, before you guys think I'm only being cynical, let me acknowledge the fact that there has actually been an improvement in the quality of work being done by the team. More features are being released, and there appears to be a higher sense of purpose and engagement amongst you and your peers. And this is why you think you are 'agile'. You believe you are getting the best out of your people, and business is good, or so it seems.

Well I hate to burst your bubble (yes, you really are living in one), but having been an active player in the 'agile space' for over 5 years and been at the fore front of multiple 'enterprise agile transformations', I believe it is my duty and ethical obligation to bring a few issues and misconceptions to your attention, before you have to learn them the hard way.

I shall list these reasons in point form, as each point feeds in to the other.

1. 'Agile teams' and/or 'agile organizations' do not exist.

There simply is no such thing as an 'agile team' or an 'agile organization' or even a team that is 'doing agile', at least not in the intended sense.

Merriam Webster’s dictionary defines the word ‘agile’ in the following ways;

• Agile, (adj.): - marked by ready ability to move with quick easy grace. For example, an agile dancer
• Agile, (adj.): - having a quick resourceful and adaptable character. For example, an agile mind.

Jane; as you can surely agree with me, the two definitions above do no justice describing your teams. You probably roll your eyes and say, “but you know that isn’t what I meant when I claimed my team was agile”. 

Well, that exactly is my point. When you claimed your team was agile, you surely were referring to the method of project management, used especially for software development, that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans. This reference of 'agile' here is the problem. Enter point (2).

2. You have been misled.

Jane; you have been sold the idea of ‘agile’ and methods of ‘agile’ but then the proponents of the whole movement never really intended it to be this way. You have purchased the product or better put, the services of those who want to help you meet your aspirations to be 'agile, but then you aren't getting the most out of it.

Think of it like buying a boat and only using it on weekends to sit and drink beer with your buddies on the marina. I mean that’s one cool beer drinking set up, but that isn’t what the boat was built for!

The point I’m trying to make is the word ‘agile’ is an adjective, which has been somehow turned in a noun, and sometimes even spelled “Agile”, with a capital letter, and it is becoming highly overused and even misused, the same way ‘organic’, ‘natural’ and ‘eco’ are being commercialized to make people buy things. I’m advocating that you put an end of it and adopt a culture of true Business Agility.

The Fact you view the division of your tasks into short phases of work and frequent reassessment and adaptation of plans (scrum) as being agile is a problem because while it might help break down and accelerate your projects quite a bit, it keeps you stuck in your that cycle, never questioning your modus operandi. It might get you halfway down the line, but doesn’t allow you achieve true agility, which, if we are being honest, is what you longed for in the first place.

Agile isn’t something you do, it’s something you become. There aren’t agile programmers—there are programmers who program with agility. You don’t work on agile teams—your teams should exhibit agility. You don’t use agile tools (think Jira, Version One, etc.)—you should use tools that enhance your agility.

3. Agile isn’t something you do, agility is how you do things.

Bill; you might ask “if you are criticizing what my team does, what then does it mean to do to things with agility?” Glad you asked, I’ll tell you.

As put by Pragmatic Dave, in his talk @GOTO2015 (https://www.youtube.com/watch?v=a-BOSpxYJ9M)—Dave is one of the 17 guys who got together at Utah and penned the Manifesto for Agile Software Development, or the now so-called ‘Agile Manifesto’—to do anything with agility, be it developing software or innovating to make a business more efficient, you follow 5 simple steps:

i) You find out where you are

ii) You define your goal

iii) You take a small step towards that goal

iv) You adjust your understanding based on what you learned

v)  You repeat.

Most importantly, you always keep in mind that when faced with two or more alternatives that deliver roughly the same value, you take the path that makes future change easier.

This is what it means to do things with agility, in its simplest terms. It means you are working in a way that permits you move fast and quickly adapt to changes as you go. It DOES NOT mean Scrum, or Kanban, or even Extreme Programming. These are all frameworks designed to build things with agility, but they DO NOT equate to being agile fundamentally. They are not always true, or best suited for all circumstances. 

Doing a daily stand-up doesn’t always make you build or develop with agility, but being able to have feedback from your customer (preferably in real time) and being able to implement insight from said feedback in to your processes moving forward, is always acting with agility. It is true that having practices, embedded in frameworks like Scrum or Kanban help you do that, however calling your team and/or business 'agile' because it is employing these practices, without even mentioning if your team and/or business is achieving true 'business agility', which is what prompted you to adopt said practices in the first place is border line self-deluding and flat out wrong.

4. More isn't always the answer.

Jane, you pride yourself on the fact that your team's velocity is increasing, and they are constantly hitting their targets right? Well let me ask you this; when was the last time you went outside of your daily job responsibilities to investigate how the customer is interacting with your product or service? Or do you think it is Ashley's job as Product Owner to always be driving the business case?

Those 17 features the team delivered last week, how many of them were actually explored by the end-user? Did they need all 17 features to begin with? Or is it possible that 9 features alone could have helped them achieve the same desired (why not a better) outcome as the 17?

I'll let you be the judge here for a minute; which of these sound better:

• My team delivered 17 features last sprint.
• The work my team did last sprint helped the company find net $350,000 in savings, or enabled the firm acquire 175 new customers.

My argument is that too many teams who go agile, of which you might be one, focus too much on development efficiency, rather than product impact. Some teams do not even achieve said development efficiency because they are stuck in the ways of a particular framework, forgetting that development or business agility is alway more important than any framework for agile software development.

Too many teams focus on building what their customers want, forgetting that sometimes customers themselves do not know what they want, until it is presented to them. I personally believe that you should ask your user what they want, but do not base your entire strategy off of their response, and worst of all never ask your developers what they think the users want. For as Henry Ford said; “If I had asked people what they wanted, they would have said faster horses!”

Instead I am advocating that you immerse yourself in their environment and see how they are interacting with your products, so you can understand them better. A company that does this well is Toyota, when they send a guy out to live with a middle-class family in Texas which owns a Camry.

So Bill, yes, your team may be that ideal cross-functional group of people that have everything, and everyone, necessary to produce a working, tested increment of product, but that doesn't make you an agile team, because there really is no such thing as that. And your focus should be more on how your organization as a whole is working in a way that permits you move fast and quickly adapt to changes as you go, which is the definition of true business agility.

 So tell me, do you really still think your team is agile? I'd love to know.