Agile

/Agile

Diamond recycling (and painting yourself into a corner)

The post I wrote recently on recycling tests in TDD got quite a few responses. I’m going to take this opportunity to respond to some of the points that got raised.
Do we really need to use the term “recycling”?
The TDD cycle as popularly taught includes the instruction to “write a failing test”. The point of my article was to observe that there are two ways to do that:

write a new test that fails
change an existing, passing test to make it fail

It’s this second approach that I’m calling “recycling”. Alistair Cockburn says that “it’s a mystery this should need a name” and it probably doesn’t. However, I’ve regularly seen novice TDD-ers get into a mess when making the current test pass causes other test(s) to fail. Their safety net is compromised and they have a few options, none of which seem very appealing:

Roll back to last green
Comment out the failing test(s)
Modify the failing test(s) to make them pass again

Whichever way you go to get out, you’ll want to try to avoid painting yourself into a similar corner in future.
Why do tests that used to pass start failing?
Ron Jeffries suggests that this will only happen if the tests don’t “say something universally true about the problem and solution.” Several people (including George Dinwiddie and Sandro Mancuso) demonstrated that this problem can be solved by writing a series of tests that each say something “universally true.” However, to me, this seems like a similar approach to that recommended by Alistair Cockburn in his “Thinking Before Programming” post.

I’m a big fan of thinking before programming. In the courses that I deliver, I routinely prevent students from touching the keyboard until they’ve thought their way around the problem. But, it’s just not realistic to expect that […]

By |December 9th, 2014|Agile, BDD, Cyber-Dojo, TDD, Uncategorized|3 Comments

User Story Mapping

I’ve been reading Jeff Patton’s work online for years, learning from his ideas and approaches. You’ve probably come across his Mona Lisa analogy for iterative and incremental development – and if you haven’t this is a good time to go and read it 😉

Well, he has just released a book, User Story Mapping, and it is every bit as good as I would have hoped. If you don’t know what User Story Mapping is then this book will (obviously) tell you, but you will learn a whole lot more than that. I believe that this is THE missing agile book.

Throughout the book Jeff uses examples from his clients to demonstrate the simple techniques that he uses. ANd the most important ingredient, for me, is the emphasis on the need for rapid feedback and the need to SLICE USER STORIES THINLY. He’s not alone in this regard – JB Rainsberger calls it “Product Sashimi” and Alistair Cockburn calls is “Elephant Carpaccio”.

Go buy this book today. Don’t let it languish on your bookshelf – read it. And start putting the advice into practice as soon as you can.

By |November 17th, 2014|Agile, Practices|1 Comment

To TDD or not to TDD? That is not the question.

Over the past few days a TDD debate has been raging (again) in the blog-o-sphere and on Twitter. A lot of big names have been making bold statements and setting out arguments, of both the carefully constructed and the rhetorically inflammatory variety. I’m not going to revisit those arguments – go read the relevant posts, which I have collected in a handy timeline at the end of this post.
Everyone is right
Instead of joining in the argument, I want to consider a conciliatory post by Cory House entitled “The TDD Divide: Everyone is right.” He proposes an explanation for these diametrically opposed views, based upon where you are in the software development eco-system:
Software “coaches” like Uncle Bob believe strongly in TDD and software craftsmanship because that’s their business. Software salespeople like Joel Spolsky, Jeff Atwood, and DHH believe in pragmatism and “good enough” because their goal isn’t perfection. It’s profit.
This is a helpful observation to make. We work in different contexts and these affect our behaviour and colour our perceptions. But I don’t believe this is the root cause of the disagreement. So what is?
How skilled are you?
In Japanese martial arts they follow an age old tradition known as Shu Ha Ri, which is a concept that describes the stages of learning to mastery. This roughly translates as “first learn, then detach, and finally transcend.” (I don’t want to overload you with Japanese philosophy, but if you are interested, please take a look at Endo Shihan’s short explanation)

This approach has been confirmed, and expanded on, in modern times by research conducted by Stuart and Hubert Dreyfus, which led to a paper published in 1980. There’s a lot of detail in their paper, but this diagram shows the main thrust […]

By |May 2nd, 2014|Agile, TDD, Unit testing|3 Comments

The most important change you can make to help your team succeed

How busy are you?
Are you close to a deadline? Is the team feeling pressure? Every team I visit seems to be under the same heavy workload, and consequently has a lot of improvements to the process, the environment, the technology that they can’t quite get to yet. They know they need to get to them, and they will…. when they have time.

But they won’t get time.

Ever.

TL;DR: Build slack into your iteration

The nature of time
When I started trying to write a book I spoke to a colleague, Jon Jagger. I whined that I just didn’t seem to be finding the time and he replied with wise words: “You won’t find the time. You’ve got to make the time.”

The same is true for any tasks that support the development team that don’t obviously deliver immediate working software for the customer. The reasons for this are many, but the root cause is normally disempowered teams. Teams who ask their product owner to prioritise tasks that the product owner has no way of prioritising appropriately. Most POs should not be asked to choose between a user story that delivers a feature they understand and a technical task that they don’t. It’s a no-brainer – they’ll always choose the user story to maximise customer value. Even if the technical task will actually deliver greater customer value.

Before I continue, I’d like to remind you of two things: sustainable pace and commitment
Sustainable pace
The agile manifesto is quite restrained in its pronouncements. One of the 12 principles it states is this: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” This doesn’t mean we don’t work hard. It doesn’t mean we never come in early, work […]

By |April 30th, 2014|Agile, Practices|2 Comments

5 rules of continuous delivery

Inspired by Sandi Metz’s BaRuCo 2013 presentation “Rules” (which you should watch if you haven’t yet) I started thinking about whether there were some  rules that might be useful in the continuous delivery domain to “screen for cooperative types”.

I came up with these as a starting point:

Check in everything – we’re used to putting source code in version control, but we’re often less good at configuration management. Do you control your test data? Your database scripts? Your operating system patch level? If not how can you be sure that the environment you provision tomorrow will be identical to the one you provisioned last week?
Automate everything – “to err is human”, as the saying goes. Any manual process is susceptible to failures, so get rid of as many as you can. Some continuous delivery pipelines still have manual approval steps in them as part of the process, but the presence of the human is not functionally essential.
Continuous != occasionally – the more we do something, the easier it gets. One of the reasons to do something continuously is to decrease the cost and remove the fear. If it “costs too much” to deploy often, then work on reducing the cost not reducing the frequency.
Collaborate – people are not plug compatible. To get the most from the different people in the organisation we need to work together. For me, this was one of the major “innovations” of devops – no more ‘us’ and ‘them’, just ‘we’.
One step at a time – it’s hard to do everything all at once, which is why we iterate in software development. Continuous delivery is no different – don’t expect everything to “just happen”.

Do these make sense to you? What essential ingredients have […]

By |February 28th, 2014|Agile, Continuous Delivery, Practices|3 Comments

Continuous delivery – the novel

I find myself recommending the same books over and over again. When speaking to techies I invariably recommend GOOS; when speaking to managers The Mythical Man Month or Waltzing With Bears. Over the past year or two, I’ve also pointed a lot of organisations at Continuous Delivery by Jez Humble and Dave Farley. It’s an important book, but I think it could have been shorter, and that’s an important consideration for the target audience. If you consider the other books I recommend that weigh in at 384, 336 and 196 pages respectively, Continuous Delivery extends to 512 and it feels longer. That’s not because it isn’t good – it is – but because it is detailed and quite dense.

Last week I finally heeded Liz Keogh’s advice and read The Phoenix Project (“a novel about IT, Devops and helping your business win”). In terms of prose style, it doesn’t compete with Liz’s own efforts, but it is very readable and does a great job of getting some quite tricky concepts across (Lean, Theory of Constraints, The Three Ways). The authors acknowledge their debt to Goldratt’s The Goal, and indeed they are ploughing the same furrow, but in the field of software. Amazon says the print copy is 343 pages long, but I read it on the Kindle and it felt shorter than that.

The reason I’m adding this book to my recommended list isn’t just because it’s short and readable. It’s because it makes some very frightening concepts very easy to digest. I didn’t know how to explain quite why I liked it so much until I found myself reading a Venkat Rao post this morning, where he describes how we change our minds:

You have to:

1. Learn new […]

By |February 24th, 2014|Agile, Practices, Systems|1 Comment

Eat your own dogma food

The software development community experiences fad after fad. Consultants and thought leaders dream up new methodologies; old practices are relabelled and promoted as the next big thing; flame wars are fought over names, tabs and brace position.

One of the few practices that has stood the test of time is that of “eating your own dog food”, which essentially means that you’ll be the first user of any software that you’re developing. In more polite (and optimistic) circles this is also known as “drinking your own champagne”. When it comes to development practices, I think we need to adopt the same approach.

If you’re going to make dogmatic statements about how software should be developed, then you as a developer should be prepared to stick to them yourself. No more  “do as I say, not as I do”. It’s time to eat your own dogma food.

By |January 14th, 2014|Agile, Practices|0 Comments

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
https://groups.google.com/forum/#!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

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