/Seb Rose

About Seb Rose

An independent software developer, trainer and consultant based in the UK. He specialises in working with teams adopting and refining their agile practices, with a particular focus on delivering software through the use of examples.

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

Rejecting CDD

One of the 12 agile principles is:

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

Indefinitely. Wow, that’s a long time!* How will we ever know if we’ve delivered on this principle? Well, we won’t. We’ll only know when we fail to deliver – when team members burn out. When it’s too late.

So, take a look a yourself and your team. How important is that first coffee in the morning? Or the second? Agilista, meet barista.

The first step in treating any addiction is to admit that it exists. You might not need that caffeine. Remember the manifesto – agile processes promote sustainable pace.

Practice what you preach and consider saying “No” to Caffeine Driven Development.

* With thanks to Douglas Adams: “Space is big. Really big. You just won’t believe how vastly, hugely, mindbogglingly big it is. I mean, you may think it’s a long way down the road to the chemist’s, but that’s just peanuts to space, listen…”

By |June 18th, 2013|Uncategorized|2 Comments

Be pure. Be vigilant. Behave.

There has been a bit of traffic on the Growing Object Oriented Software (GOOS) mailing list recently about how many tests you should write, and what sort they should be. Understandably it got back to the perennial discussion about what constitutes a unit test, what an integration test, what an acceptance test. And where does the testing pyramid fit into all this?

All important questions and yet somehow ephemeral in their unfathomability.

Torbjörn Kalin got to the heart of the matter with his concise response:

“What is the purpose of the test? What is it that we want to test? How do we test it?”

It doesn’t matter what you call it. The label is incidental. Turn to the rubber duck on top of your monitor and earnestly ask:

“What is it that I am worried might fail?”

If you don’t answer the question honestly, then Torquemada might just come a calling.


By |May 16th, 2013|Uncategorized|2 Comments

Simpler. Clearer. Faster.

The UK Government has invested £17 million over the past 2 years migrating from several rather old websites to the new, shiny website. James Stewart and Anna Shipman gave an uplifting talk at the Edinburgh BCS branch meeting on May 1st, describing how they had scaled from one small team of 12 to ten teams (and an organisation of over 200) in not much more than a year. Not only that, but they had delivered on-time and have since gone on to win the “Design Award of the Year.” Everything was not perfect – they admit to having worked unsustainable hours and of accruing significant technical debt – yet they appeared energised, motivated and undeniably happy.

Prior to that meeting I spent several days with a large corporate client where a large number of teams were being mobilised to develop a major, strategic implementation. They will have to learn new technologies and new methodologies at the same time as being asked to deliver mission critical functionality within a very tight schedule. These teams are in their early days, but there are early signs of the pain to come.

Both of these teams consider themselves to be agile. Neither of these teams consider themselves to be using behaviour driven development (BDD).

My corporate client is aiming to deliver a complex, monolithic application, and has a small number of product owners supported by a somewhat larger number of subject matter experts (SMEs). There is conceptually one backlog, but each team is having a subset of it pushed onto a team backlog from which they pull stories to be elaborated. There’s no clear division between each team’s role and hence each story may require the team to interact with different […]

By |May 3rd, 2013|Uncategorized|0 Comments

On alcoholism, chainsaws and deliberate practice

I’ve been running a lot of training courses recently and I’ve noticed that once people have chosen where they’re going to sit, they return to that position every day. We are creatures of habit, and some habits seem to form very quickly. If I rearrange the room before the second day, or ask people to change places, no-one seems particularly bothered – they simply go and find another seat. So, having a fixed seating position seems to be a habit that’s easy to slip into, yet easy enough to break.

Other habits are harder to shift. We’ve all probably tried to modify our behaviour using rational thought and wishful thinking. For short periods of time it can even look like we’ve succeeded, but then some stimulus knocks us off course and we revert to our previous behaviour. It’s for this reason (I guess) that members of Alcoholics Anonymous always consider themselves “alcoholics that haven’t had a drink for <some time>” where <some time> can range from hours to years. Avoiding your old behaviour is certainly the first challenge. The next, and harder, challenge is becoming comfortable with your new behaviour. This is as true for our work habits as it is for any others.

The habit that I see many teams having trouble breaking, is the habit of forgetting their quality aspirations when they come under pressure. As deadlines loom I often hear people talking about “adding the tests later” or doing something “just for now”. A lot has been said about technical debt (see Martin Fowler’s excellent post or my contribution to “97 Things Every Programmer Should Know”), but I think many of these habitual, time-driven responses can’t really be considered technical debt. They’re more like […]

By |April 26th, 2013|Uncategorized|0 Comments