Yearly Archives: 2013


Aslak’s view of BDD, Cucumber and automated testing

This is a quote from Aslak Hellesoy on the Cukes Google group.

“Even on this list, the majority of people seem to think that Cucumber == Automated Tests == BDD, which is WRONG.

What people need to understand is:

Cucumber is a tool for BDD
Cucumber is a tool for Specification By Example
Specification By Example is just a better name for BDD
Specification By Example / BDD means examples (Scenarios) are written *before* implementation
Specification By Example should happen iteratively, in collaboration with non-technical stakeholders
Automated Tests are a by-product of Specification By Example
Writing Automated Tests does *not* imply you’re doing Specification By Example
Using Cucumber for Automated Tests without doing Specification By Example is stupid
Cucumber is not a tool for Automated Testing, it’s a tool for Collaborative, Executable Specifications”

Aslak Hellesoy    – 12th December 2013
Cukes Google Group!topic/cukes/XFB7CjWuI14

By |December 14th, 2013|Agile, Cucumber|0 Comments

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

The Beer Belly testing anti-pattern

The ‘Testing Pyramid’ is often trotted out to illustrate a suggested distribution of tests. More small “unit” tests; less deep “end-to-end” tests. And various people have observed common anti-patterns, specifically the Ice Cream Cone, where there are lots of end-2-end tests and hardly any unit tests.


The anti-pattern that I see most often is the Beer Belly. This stems from a misunderstanding of what constitutes a unit test. It’s proven difficult to define exactly what a unit test is, but Mike Feathers described what ISN’T a unit test – notably tests that hit the network, the file system or the database. Most developers don’t seem to have taken this on board and write many tests that rely on some (or all) of these external components.

Combine this tendency to write integration tests instead of unit tests with a whole pile of manual test scripts and you get the classic beer belly topped with a big, cloudy head of woe.

And you know the best way to cure a hangover. Hair of the dog, anyone?

By |November 21st, 2013|Practices|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

Introducing 2nd party

It’s always a good idea to wrap any component that we don’t own behind an interface that we do own. There are a number of benefits:

1) We can tailor/narrow the interface to expose only the behaviour that we need
2) When we choose to change the external component, we’ll only have to modify the facade code behind our interface (as long as the interface isn’t leaky)
3) We can maintain our own suite of acceptance tests that run against the external component through our wrapper to ensure that it provides the behaviour we expect. New versions of the external component should be verified using this suite before they are accepted.

So far, so good. The confusion creeps in with the definition of ownership. 3rd party code is provided by some other organisation – you don’t own it. Components developed and maintained by other teams within your own organisation don’t fit into the 3rd party category. However, if you need to speak to another team or another department to get a change made to a component, then you clearly don’t own it. Our colleagues down the hall may work for the same company as us, but that might make it even harder to get bug fixes or change requests approved.

I was working with recently with a large european client, where someone told me that they call this sort of code 2nd party. I liked it so much, I bought him a cupcake.

By |June 23rd, 2013|Uncategorized|1 Comment