Why The Manifesto For Half-Arsed Agile Software Development Is Actually Important But Not Enough

Reading time ~ < 1 minutes

“That is, while the items on the left sound nice
in theory, we’re an enterprise company, and there’s
no way we’re letting go of the items on the right.”


Not mine but this resonates strongly with my experiences. I’ve seen varying levels of agile interpretation including this during my career so far. (By contrast, the team closest to the original principles that I worked with hadn’t even given their working practices and culture a name.)

The sad fact is that it’s all too easy to fall into the checkbook agile, control & distrust trap in large organizations. What I like about this spoof is that it captures Ron Jeffries thinking from this article in a concrete and direct way that even the most disconnected exec should recognize what their teams are doing wrong.

It also uses a subtle but powerful tool that makes this worth paying attention to rather than just reading, chuckling and inwardly despairing.

In trying to understand what you should do it’s important to understand what you should not do. The original manifesto is vague. Many of the myths that cause execs to distrust agile when they first read the manifesto are made manifest due to its vagueness. Similarly, developers that see a get out of jail free card on having to do anything but cut code in the manifesto are able to do so.

The negative ad-libs at the end of each point in this cynical version provide a clear “bad” marker; a new, tangible triangulation point to avoid.

What we need are equivalent “good” triangulation points based on business reality for large-scale software development rather than a noble vision so that we can help our teams and managers do the right thing.

Software Is Just A Means To An End

Reading time ~ < 1 minutes

Last year Chris Matts wrote an insightful post reflecting on the Agile Manifesto and business analysis. At the time it sparked some creative thinking but I didn’t turn it onto the right words.

Now I have them.

Writing software is just a means to an end. Our customers and users don’t always want software (with the exception of games). They want to be able to achieve something and fulfil their role.

Software was developed to help us achieve things in more effective, efficient, accurate ways. We have CAD tools because it’s seen as better than traditional draughtsmanship. We have Financials applications because it adds more value than traditional double-entry book-keeping. Software is written for commercial fighter aircraft because we made them too complicated for people to fly alone.

I could go on…

Remember you’re solving someone else’s problem or making someone’s life easier or safer, not just writing software for the sake of software.

The next time you think about adding a speculative “neat” feature or idea to the backlog, think about who will actually get value from it.

Admittedly, sometimes it might just be to tick the box on an RFP in which case your investment should be lower than if you’re delivering for real end user value but there is business value in doing something.

A Decade of What?

Reading time ~ 3 minutes

Ten years since the Agile Manifesto and where are we?

Before I get flamed, much of this article is deliberately tongue-in-cheek but there’s a serious element to it.

Flashback: Chicago 2009.

After an amazing week at my first ever Agile conference I had the privilege to sit in the hotel lobby relaxing & talking shop with a few presenters & attendees.

Although I’ve not made time to catch up with him since; the ~day I spent at Agile 2009 with one of that group of attendees was career-defining. In just a day he taught (or perhaps reminded) me to open my eyes and see the world as it really is – not how it’s marketed to us. This post is inspired by that experience.

During one of many conversations he asked me if I’d read Mordant’s Need.

Being a fan of the Thomas Covenant series  I had secondhand copies of both books in my personal library but had never read them.

Some weeks later I finished the textbooks I’d been working through and switched my bedtime reading to fiction for a while. I picked up “The Mirror of Her Dreams”, blasted through it and moved onto the second book – “A Man Rides Through”.

At some point at about 4AM after yet another bout of insomnia and a reading marathon my mental lights went on.

The entire first book builds up a classic “long con” – a confidence trick drawn out over years – to the detriment of everything else. Incredible.

Now for some fun. Picture this…

SnowyOwl Surf Resort – 2001:  Post-Y2K, the .com bubble is ready to burst,  everyone with half a brain is in software and the consulting gigs are drying up…

Guys. Things aren’t looking so hot for us Cobol developers any more. We need a new cash-cow to milk…

Time passes,  brainstorming happens (with the only thing to hand – those little pads of hotel room stickies)

…well, what are we any good at?

duhhh – Writing software.

OK, that’s a good start but it’s no fun any more – what do we all hate about writing software?

… Maintenance…



…Long isolated hours…

I’ve got it! Let’s take everything we loved about writing software, throw the rest away, package it up and market it back to all the noobie developers as a revolutionary new way of thinking!

Hmm. I think we’re going to need some marketing to pull this one off…

…I have an idea, my buddies at 4N keep complaining nobody except hotels wants to buy stickies any more and they’re gonna be out of work soon. I reckon we can arrange some sort of reciprocal deal.

Sales & Marketing join the team…

So here’s the deal. Marketing to developers is only going to get us so far. We need a top-down approach as well.

…How about we add in project management 101 and package the whole shooting match up into a name that execs will think means better, cheaper and faster.

…Let’s call it “Nimble”.

It’ll be great! I see it now, a pyramid training scheme, conferences, book deals and… oh boy – consulting gigs to die for!

…You know what, this just might work but it’s too easy. We need to throw some stuff into the mix to make it that little bit unreachable for the majority of our marks – keep ’em coming back for more.

While we’re at it, let’s roll in a whole new subset of jargon for extra obfuscation and overlay with some real punchy one-page marketing.

Some years pass…

MickeyWorld 2010 – “Nimble Conference” keynote speech:

…In fact, if Nimble’s not working for you, that’s because You’re doing it wrong.  Donate a million bucks to one of our Gurus and you too will have perfect development projects, products everyone wants and fault-free software.

Here’s the real data from one really successful project to prove how great it is.

Present day – all over the world:  Everyone’s all-in. Despite the vision of a digital paperless office, our stationary budgets have tripled – but don’t the walls look pretty!?

OK, back to reality.

I wouldn’t have things any other way right now. How else would we counteract the incredible momentum of Taylorism and the erosion of good old common sense. Writing software in the 21st century is all about the business, coding is just a fragment of the job.  Gone are the days of a neat idea and a pile of VC funding, so too is the ability to write cool games single-handed at weekends (most of the time).  Here’s how we can make software development fun again. Better still, now we have the tools and support to demonstrate that software teams deliver real business value.

Look beyond the methodology marketing, the processes, the practices, the tools and get back to the root of why we’re doing this. Software is generally a means to an end. Agile, Lean, Scrum, Voodoo, whatever; our goal is to deliver business value to the best of our abilities.

I’ve committed my career to this. I’m having a fantastic time. Much of what I’m seeing in the agile & lean community is great but for large-scale enterprise software product development and large corporations it still is very hard work to make this stuff stick.

I don’t plan on giving up any time soon.