Random thoughts about agile software development

I'm going freelance next month in a company that my wife and I are starting. Part of what I've been doing is consulting on various issues companies have and part of that is this whole notion of "agility". I fear that the term "agile" is becoming a meaningless buzzword because, while the core principles are sound, companies are just using the word to say "we have no process." It's a fine line between a process so lightweight that you don't even notice it and a process that doesn't exist and it's understandable that some companies will incorporate "agile" into their buzzword bingo without understanding what it really means. This is sad because it not only dilutes the utility of agile, but it creates a perfect straw man for agile detractors.

So what is agile, really? You can watch my YAPC::EU Keynote speech entitled Agile Companies Go P.O.P. to get an idea of what agile really is, but in a nutshell, agile is a full-spectrum continuum that I describe as People, Organization, and Process (hence the P.O.P.). Most people seem to focus on process and forgets everything else. What's worse, "process" gets reduced down to XP, Scrum, Kanban, and so on. Then, instead of considering the merits of agility, people nitpick issues like pair programming, TDD, or whatever gets their goat about a particular system. They don't actually think about agility. This is frustrating for me.

To give you an example of what I mean by POP, consider the BBC. They're a great place to work, I highly recommend them and I really enjoyed the years I worked there ... but they're not agile. Oh, they say they use a "modified scrum" and the BBC says they're agile and in truth, many of their teams are agile, but the BBC itself is not. I can think of no better way of explaining this than to talk about my first week of working there.

A gentleman wielding a mug walked up to me and said "hello". I said "hello" back and asked who he was and he replied "I'm your boss."

This is not a great way to find out who your boss is, nor was it a particularly brilliant way for me to make a good first impression, but being the fool that I am, I doubled down. I replied, in a reply that to me is truly epic (if I may be ever so humble):

"I'm sorry, but this gentleman to my right is the team lead. That lady behind me is the project manager. That lady over there is the product owner and that gentleman sitting over there says that he's my boss."

The mug-wielder (a really great guy, actually) just laughed and said "I completely understand. We'll have coffee next week."

It was six months before I saw him again, but as it turns out, he was, briefly, my boss. It seems that, amongst other things, the BBC had adopted the horror of Matrix management and threw in a dose of Neo for good measure.

Just to really drive the point home: a couple of months after I was nestled firmly into the comforting arms of Auntie Beeb, there was an "all-hands" meeting and, amongst other things, it was announced that the BBC had finally given approval for teams to switch from CVS to SVN.

Yes, you read that right. That was the time when SVN was dying and everyone seemed to be switching to Git or Mercurial and the BBC had finally gotten on the SVN train. When asked why it took so long to get approval for the switch, the person making the announcement replied that he had understood that people would be more productive with SVN, but no one had ever made a business case for it.

Oh my. On one hand, for an organization as large as the BBC, you can understand a certain amount of caution. On the other hand, it felt like they were announcing that they've decided all workstations will henceforth be issued with mice. Or for a more compelling argument: Forge, the new "one size fits all" development platform. You'd have to have been there when it was announced to properly appreciate that mess, but I remember an email to the Forge mailing list where a PHP developer couldn't get "Hello world" running on Forge. The mind-numbingly complex answer caused much laughter and tears, and the subsequent justifications of the Rube Goldberg-inspired workflow were nothing short of astonishing.

Yes, the BBC uses Scrum. No, the BBC is not agile. Great place and I loved working there, but there are many there who don't "get" agile.

To round out this random collection of thoughts about agility, I mentioned that the BBC uses a "modified Scrum". Many companies use a "modified $agile_method" and that makes me nervous the way a car salesman makes me nervous when he explains that "this car has brakes".

Of course the damned car has brakes. It's a car. That's part of what a car is. If you have to explain it ...

Every agile methodology explains that it's a heuristic and you need to mold it to your business and culture. Of course, as soon as you do, some rules lawyer is going to tell you that "this isn't agile!"

Ignore them. Of course it's agile. Agile is about agility. Duh. If you can't adjust your processes to fit your needs, you're not agile. If you do adjust your processes to fit your needs, it's not a "modified Scrum", it's just "Scrum." People say "modified" like they're making an excuse when no excuse it necessary.

I'll write more about agility in the future, but I felt this was a good start to give you an idea of where I'm coming from. Oh yeah, and don't forget to watch my P.O.P. presentation.

And now I'm kicking myself because I didn't pitch the P.O.P. talk for YAPC::NA.


Heh. I actually think the "no process" folk are the least of your worries.

Generally the people who have the biggest problems are the folk who think they are agile - but aren't really. They've sent a project manager on a CSM course and they've come back - added a couple of Scrum practices (usually leaving out the really important ones like the process-changing retrospectives) and think that's job done. Suddenly all the project managers are renamed "scrum masters" and the company is "agile".


As you say - it's the philosophy and organisational change stuff that's hard.

Also - I do think you do have to be careful with the "adopt your process to fit your needs" approach. Because a weak reading of that produces the bad systems I just talked about. People adopt the "easy" stuff that fits in with their current way of working, and avoid the "hard" stuff that requires serious changes in their working context (no matter how much that context is the thing that's really f**king them up).

Yes all agile processes are designed to be optimised and changed over times... but those changes are aligned with the underlying agile values and principles.

The "modified agile" phrase raises my hackles too - because it usually means it's been modified into waterfall, or whatever their old process was, and it's not actually providing them with any useful value.

And now I'm kicking myself because I didn't pitch the P.O.P. talk for YAPC::NA.

This is strictly MHO, but please don't let that stop you - submit it anyway! Or, please consider making this a half-length or lightning talk?

Excellent post, Ovid. I posted something very similar recently ... if you don't mind me pimping my blog:

My Theory About Agile

Love to hear your thoughts on it.

About Ovid

user-pic Freelance Perl/Testing/Agile consultant and trainer. See http://www.allaroundtheworld.fr/ for our services. If you have a problem with Perl, we will solve it for you. And don't forget to buy my book! http://www.amazon.com/Beginning-Perl-Curtis-Poe/dp/1118013840/