Agile: Do Or Do Not, There Is No Try

Recently, Paul Stack asked me a leading question in preparation for his post: "Is it really agile?". The question was:

"do you think organisations are turning their back on agile?"

My answer to this question was "no", and here are my thoughts.

Who are we talking about here?

Firstly, we need to establish that there are two kinds of organisation. Those that are actually living, breathing, functioning agile teams that have no problems adopting all the processes, ship regularly and deliver things of high value to their customers. These guys are not who we are going to be looking at here.

We are interested in the remainder, the guys that may or may not be "trying" agile, but for one or more reasons, cannot be considered "agile" (more on this to follow in a later post). This is to keep it simple so we can just focus on the current "problem".

The three wannabe agile-eers

Let's look a bit more closely at these agile wannabes.

In my experience (as well as talking to a variety of people from many organisations), I find that organisations not doing agile fall in to one of these three categories:

1. They honestly believe they are doing agile, but don't realise they are doing something wrong, or they change/remove practices because they "know better" or it "doesn't apply to us". Let's call these "The [Self] Proclaimers"
2. They think agile is a bunch of BS and just "another way for developers to get out of doing work". Let's call these "The Non-Believers"
3. They simply haven't heard of it, or do not know what it all means. Let's call these "The Lost Souls".

I'll go over the last two first, because I actually feel that these are really the minority.

The Non-Believers

This is plain and simple "this agile stuff is a load of BS and it's simply not applicable or not all it's cracked up to be". This is often coupled with "it doesn't work with the type of projects that we do" or disbelief that lightweight processes can *possibly* produce better quality results the incredibly thorough process that has been formed over the last 30 years.

This pains me for two reasons:

1. The organisation in question are working in a fast paced industry and outright refusing to look at what is changing in the environment around them.
2. Rather than experimenting with something new, they are reverting to "I know what's best" before even giving something a fair shot.

Tech and a stagnant environment do not mix. Yes, your company may have got along just fine in the last 20 years, but times are changing my friend.

My advice

Managers, stop hating/being dismissive and start finding out. Talk to people, there is an abundant, thriving agile community full of incredibly talented people out there (sure, there is also a lot more untalented people as well now that it's become a bit of a buzzword). Ask questions, lot's of them. It will become pretty clear pretty quickly if people know what the are talking about. Hire them part time (I personally don't believe a "scrum master" is a valid full time job, at least post initial roll-out - sorry guys). Yes, I will be happily be this guy (shameless plug - email me if interested).

Developers, have a chat with your managers. Let them know how much this means to you. Offer applicable advice on how you think agile could improve current processes. Come up with some metrics where possible. If you continue to have problems, consider moving elsewhere. There are plenty of great agile shops doing great things that will snap you up.

The Lost Souls

These poor guys are so out of touch that they really have no idea what agile even is or supposed to do. Aside from wondering what the hell their CTO has been doing, this really leaves us in a bind because if the organisation was to suddenly "discover" agile, then they would have a LOT to take on in both learning and deployment. Ouchies. Thankfully, these companies really seem to be in the minority now. However, some do still exist.

My advice

Same as above really. However keep in mind that we are starting at square 1. In some cases this can be a benefit since it can be easier to get started if people just take the current practices as-is. On the flipside, you could also encounter a lot of resistance. Perhaps more because there is so much to take in.

Take it slow and steady. Learn lots from those in-the-know.

The [Self] Proclaimers

I think these guys are now the vast majority of companies, they have seen about agile, and given it their best shot. Then then tend to end up in one or more of these situations:

• They don't participate in one or more key agile practices.
• They "adapt" practices (normally adding more "process") because "agile isn't enough" or "it's our own flavour".
• The guys heading up the agile rollout move on to another organisation and those that remain don't have the knowledge/passion to follow it through.
• They are simply lying (yes, I have experienced this).

My advice

These guys are the trickiest to deal with, since they often genuinely believe that they know better.

Managers, stop and listen. Just stop trying to "be in charge" and listen to your dev team. Are they surprised you are listening? Do they have pain points that are slowing them down day after day? Why are they there? Can you remove them? Do you need to know more information about agile? What exactly is it these agile guys do? Can you let someone in the team take responsiblity? How about you get some training yourself, or hire someone to come in and help out? Start respondng to what people are saying. In every organisation like this I have seen one thing in common - all the managers "think" things will be nice, but never take action. Either take action or enable someone else to.

Developers, I warn you, this can be a slog to get through. Keep voicing concerns with current processes. Metrics can often be a big help because no matter what a manager thinks, "numbers don't lie". Try using the questions above to assess what the manager knows, what is blocking them? Help them to help you. In most cases, the developers know what needs to happen, but if unsure, talk to other developers or get someone in to assist. This can be really useful because they become that "target" if anything goes wrong, or meetings etc. are required.

The bottom line

It boils down to this:

When your competitor "gets" agile, they will ship more than you, faster than you and at a higher quality than you. They will have a lower bottom line, and they will erode away at your market until you have nothing left. Waterfall and other broken processes will work, of course they will - but agile works better.

How can you expect to beat a processes designed from the ground up to produce fast, effective and valuable results?