Flatulent agile

I’ve been working with a number of larger, older organisations recently and it has really brought home to me the difference between the promise of a nimble, responsive teams and the reality of a sluggish, bureaucratic behemoth. Then, looking back over years of writings, posts, promises and dreams I see frequent repetitions of the phrase “Agile says that …” What? What exactly does agile ‘say’?

I’m not going to invoke the manifesto. It’s there if anyone wants to look at it and it is a valuable historical document. Its contents are as relevant today as they were when they were written (tinkering aside), but it is declarative not imperative. It is aspirational not procedural. We can’t ‘implement’ it or ‘transition’ to it.

Instead we have the plethora of methods that existed at the time of its original drafting and a few more besides. Many of them include recipes, processes, state diagrams – but they don’t seem to reliably help organisations improve their ability to deliver. These organisations need to change, but not according to some checklist brought down from the agile mountain chiselled in stone. The agile values and principles help us suggest ways of change, but that’s as far from a recipe as the contents of a box of oatcakes are from the serving suggestion in the picture.
There are plenty of winds in the world. There are the four winds. There are the trade winds. There are the winds of change. And there is… how shall I put this delicately?… bottom wind.

One of the definitions of flatulent is “generating excessive gas in the alimentary canal”, but it’s not that relevant to what we’re discussing. A more appropriate definition for my purposes is:

“having unsupported pretensions; inflated and empty; pompous; turgid”

I’ve heard […]

By |August 27th, 2015|Agile, doa, Musings|0 Comments

Always Be Coding

Last night I finally got around to watching Erik Meijer’s keynote from last year’s Reaktor conference. It was called “One Hacker Way” and, while it contains much that is apocryphal – or at least wildly inaccurate – it scores over the older, more pedestrian type of keynote in two important ways: first it is highly contentious, and second, Erik sports a bright, tie-dyed T-shirt.

Some of the highlights of this personal rant were:

“Agile is a cancer”
“TDD is for pussies”
Stand-ups eat into valuable coding time
Coders should be treated (and paid) like professional athletes
Hierarchical structures work for the army and the church, so they must be good

There were times that I found myself nodding in agreement, though – when he compared Scrum certification to a pyramid selling scheme, for instance – but mostly it was just opinion, conspicuously lacking the support of empirical data (which was one of his criticisms of agile).

I could go on, but if you’re still interested then I recommend you just go watch the video.

My final thought is that whole experience was vaguely reminiscent of a scene from the excellent movie “Glengarry Glen Ross”, where Alec Baldwin’s character harangues the dejected real-estate salesmen:
F*** YOU, that’s my name!! You know why, mister? ‘Cause you drove a Hyundai to get here tonight, I drove an $80,000 BMW. That’s my name!! And your name is “you’re wanting”. And you can’t play in a hacker’s game. You can’t write code. Then go home home and tell your wife your troubles. Because only one thing counts in this life! Checking in code! You hear me, you f***in’ faggots? A-B-C. A-Always, B-Be, C-Coding. Always be coding! Always be coding!
And, if you’re over 32 (when Erik […]

By |January 16th, 2015|Agile, doa, Musings, Practices, TDD, Unit testing|1 Comment

The context and definition challenge

We’re very good at rationalising. Almost any statement can be justified by the retroactive application of the twin constraints of “context” and “definition.”

As an example, Chris Matts (@papachrismatts) talked about the “death of Agile” in a recent blog post of his, and I took issue with that. We talked about it briefly at a couple of conferences and he explained why it made sense to him:

– context: “Agile” as a set of recipes, not values (c.f. Scrum, SAFe, DAD and accompanying certifications)
– definition: “Dead” means devalued through repeatedly over-promising and under-delivering

I still don’t think that agile has died, and neither does Chris in the general sense, but given the specific circumstances of his post the statement makes sense. But it took me time and effort to gain that understanding – time and effort that someone looking for a reference to support their view might not invest.

Neil Killick (@neil_killick) makes a good point that we often use controversy to stimulate debate, so should we care that our words can be misinterpreted, or quoted out of context? I think the answer is sometimes. Influential members of any community should consider carefully how the constituency that they are addressing might (mis)interpret their statements. No matter how much you may hope that people will think for themselves, the pronouncements of “thought leaders” carry a weight that cannot be ignored.

Misinterpretation of the written word is all too common, however. The “Three Amigos” meeting at the heart of Behaviour Driven Development (BDD) emphasises the need to have frequent, open, high bandwidth collaboration between technical and non-technical participants for just this reason. The differing perspectives of the participants challenge the implicit assumptions of the others.

If you make strong assertions in your tweets, […]

By |December 3rd, 2013|Agile, doa|0 Comments

Value by association

Do you care what label is on your shirt? Or your car? Or your laptop? I bet you do, but why? Is there something substantive underneath the fashion-victim facade or is it just some sort of post-modern tribalism?

A few of us have been debating the death (or otherwise) of agile, and it seems to come down to whether the agile brand has become devalued. I’d like to move the discussion back a decade or so and ask whether there was ever any value to the brand – value to the customer that is. (After all one of the principles in the manifesto states that “Our highest priority is to satisfy the customer.”)

I don’t believe that a customer derives any value from a consultant simply because they are ‘agile.’ I don’t believe in ‘value by association.’ I don’t trust brands.

If you want a plumber or lawyer do you seriously just look through the Yellow Pages (or contemporary equivalent)? Really? Don’t you ask friends and family for recommendations first? And if their recommendations are all busy won’t you look for referrals or reviews or some “independent” verification of someone’s suitability for taking your money?

I don’t even think a personal recommendation is enough. Competence needs to be qualified. A family lawyer is not necessarily the right person to use in a patent law suit. Someone who has successfully deployed agile in a small organisation is not qualified to deploy agile at the portfolio level in a multinational (thanks @tastapod).

As well as ‘competence’, we should take into account ‘attitude’ when we choose who to work with. I use ‘competence’ in the sense that someone has the knowledge, skill and experience requisite to perform the task that I need done. […]

By |October 4th, 2013|doa, Uncategorized|0 Comments

Death of agile – Intro

Welcome to the “Death of agile” series. Most of these posts take the form of open letters to members of the community, but this introductory post sets the stage and outlines my understanding of what agile is, and where it fits into the pantheon of software development methods.

See also:

Open letter to Dan North
Open letter to Chris Matts
Open letter to Gabriel Steinhardt

Cast your mind back (if you’re old enough) to the 1990s. There was there a proliferation of lightweight development methods, such as DSDM, Crystal, XP, Scrum and more. These approaches became popular because organisations were finding that their traditional development techniques were frequently leading to project failures. With the traditional methods it only became apparent that things were not going well after a lot of work had been done and a lot of money had been spent. The lightweight methods, however, worked with short iterations, engaging the customer early and often, to ensure that the product kept moving in the right direction, or that it could be cancelled early and cheaply.

Then in 2000 a bunch of consultants representing these lightweight methods came together to see if they had anything in common. The result was the Agile Manifesto, which is itself fairly lightweight. The manifesto talks about values – valuing people, valuing the flexibility, valuing trust, valuing communication – and emphasises that the customer values stuff that works. The manifesto doesn’t talk about how this should happen, what roles should exist or what technical practices should be followed. In fact the manifesto contains NO DETAILS.

Kevlin Henney said it beautifully in a recent online interview: ” greatest weakness is when it is perceived as a fixed set of practices, which explains why a lot of people, within, […]

By |September 25th, 2013|doa|1 Comment

Gabriel Steinhardt – an open letter

Welcome to another post in my “Death of agile” series. This post is an open letter to Gabriel Steinhardt, a Product Management expert from Blackblot.

See also:

Death of agile
Open letter to Dan North
Open letter to Chris Matts

Dear Gabriel,

In your keynote at Agile On The Beach and your subsequent blog post you characterise agile practitioners as “confused … about how Agile should be implemented.”

Let me clear one thing up for you: agile is not a “product development method.” If you take a brief look at the Agile Manifesto you will quickly see that it is a set of guiding values and principles. Specifically the manifesto makes no mention of a “Product Owner”, so any confusion that you might have encountered over interpretations of this role is strictly limited to implementations of Scrum.

More generally, I assert that confusion among adherents to a philosophy, methodology or belief system does not logically invalidate that system. There is confusion and disagreement among Product Managers, despite your implication to the contrary. I have no opinion on your company’s product management methodology, but I’m sure I could find successful project managers who disagree about its utility.

Recall that agile approaches first came into existence to avoid expensive project failures that were attributed to ‘Big Design Up Front’ approaches favoured by traditional waterfall methods. Your suggestion that developers have no place in the ‘problem’ space, and all communication should be mediated through a “Product Architect”, seems like a retrograde step that brought back memories of nightmares I have no wish to relive.

You go on to admit that you “do not know much about Agile or other product development methods which reside in the solution space.” Agile approaches are not limited to the solution space and […]

By |September 25th, 2013|doa|0 Comments

Dan North – an open letter

Welcome to another post in my “Death of agile” series. This post is an open letter to Dan North, the ‘father’ of BDD.

See also:

Death of agile
Open letter to Chris Matts
Open letter to Gabriel Steinhardt

Dear Dan,

I’ve been meaning to talk to you about some of your recent conference keynotes, specifically “Patterns Of Effective Delivery” and “Agile Doesn’t Scale.” It’s not that I have any issues with your observations, but I think the audiences you deliver them to might not be taking them in the way you intend.

In “Patterns Of Effective Delivery” (and your Accelerated Agile course) you describe how an amazing team of developers are able to quickly and effectively develop trading software without adhering to any of the technical practices that are generally recommended, such as test driven development (TDD) or peer review. It’s an entertaining keynote, but I worry that the accelerated patterns you describe are not applicable to the majority of software teams and that if the audience mistakenly adopt them it might do them serious harm.

Then in “Agile Doesn’t Scale” you say, well, that agile doesn’t scale. In our email exchange you point out that none of the popular agile methods say much about scaling to larger organisations and that the techniques that do claim to scale are largely unproven. There are numerous examples of successful, multi-team, agile projects out there, and just because they don’t use out-of-the-box solutions, doesn’t mean they’re not agile. People might assume that agile approaches are only useful for small projects.


By |September 25th, 2013|doa|1 Comment