When is a tester not a tester?

No, I’m not trawling through my xmas cracker jokes. I was looking through the programme for DevWeek 2014 and both my sessions are tagged as “Test”. This is following a pattern started at ScanDev last year and followed by several other conferences at home and abroad.

Why am I bothered? It’s not that I mind being associated with testing at all. I don’t think of testers as a lower form of life. I *love* testers. It’s for the same reason that Dan North and Chris Matts started using the “should” word instead of the “test” word all those years ago –┬ádevelopers think that the test track is not for them.

Both my sessions at DevWeek are about types of testing that developers should be doing routinely. “So long, and thanks for all the tests” explores what makes a test valuable and what practices developers should consider adopting. “Mutation testing – better code by making bugs” is an alternative to code meaningless coverage metrics that can help developers ensure they’re sticking to their definition of done.

Q. When is a tester not a tester?
A. When they’re a developer.

You’re right. It’s not funny. So, it’s ideal for a cracker.

By |January 9th, 2014|Practices, Unit testing|0 Comments

Tax or investment – which do you prefer?

I was working with a client last week who were trying to fit some new technical practices into their daily routine. The way they were trying to ‘account’ for this in their iteration planning was by introducing a 10% ‘tax’ on their velocity. In other words, they were reducing the number of story points that they would accept into the iteration to make up for the time spent getting better at TDD (for example).

Quite apart from whether you think this is a good way to go about it (I don’t) there’s a real issue of terminology. Maybe taxes are levied for the good of the nation, but very few people feel ecstatic about paying them. Taxes ensure you keep getting what you already take for granted.

This team was trying to improve their work, so that they could deliver better value. By calling this a tax I think they were setting the wrong tone for discussions with their customers and management. Far better to describe it, accurately, as an investment. An investment in the staff, the organisation and the product. An investment that would produce returns.

Phil Karlton famously said: “There are only two hard things in Computer Science: cache invalidation and naming things.” It turns out it’s not just in computer science that it’s hard. Who knew?

Do you have any great examples of poorly chosen names, that give people the wrong impression of something?

By |October 24th, 2013|Agile|1 Comment

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

Chris Matts – an open letter

Welcome to another post in my “Death of agile” series. This post is an open letter to Chris Matts, the ‘father’ of Real Options and Feature Injection and co-parent of BDD.

See also:

Death of agile
Open letter to Dan North
Open letter to Gabriel Steinhardt

Dear Chris,

I recently came across one of your blog posts inspired by some of the vendors you met at Agile 2013 in Nashville. You were clearly outraged by the SAFE family of products that claim to ‘scale agile’ despite the absence of any convincing case studies, and from this you extrapolated the demise of agile.

I’d like to ask you to think again. No matter what sphere of human endeavour you look at, there have always been people gullible enough to buy snake oil, silver bullets or Spanish prisoners. And wherever there is demand there will always be those willing to satisfy that demand, unscrupulously if necessary.

When Harry Lime killed and crippled many Viennese with his sale of black market penicillin, did it to discredit the efficacy of that medication? I don’t think it was Graham Greene’s intent we reach that conclusion. Likewise, I don’t think that the marketing of unvalidated development methods discredits agile approaches or equates to the “death of agile.”

Agile is a set of values and principles that guide our approach to delivering value to our customers. It is as valid today as it was at the beginning of the millennia and I believe that this is no time to start lamenting.


By |September 25th, 2013|Uncategorized|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