Branching and Continuous Delivery video discussion

Following on from my previous post and discussions online, we arranged a Google Hangout to discuss things in more detail. I was joined by Dave Farley, Lars Kruse, Olve Maudal and Mike Long and you can watch the unedited video here:

I don’t think we reached any agreement and after the video ended Olve suggested that we meet again to focus on specific topics, in several sessions. Olve’s suggestions were (paraphrased by me):

pre/post-commit checks and their effect on feedback speed
benevolent dictator/trusted serf as a general model
even more about branching

If you’d like to see more, please Tweet with the hashtag #cdBranching indicating which (if any) you’d like to hear more about.

By |May 20th, 2015|Agile, Continuous Delivery, ContinuousDelivery|1 Comment

BCS: Agile Foundations

Preconceptions challenged
I really wanted to dislike this book, and in some respects I managed to achieve my goal. This is a book published to support yet another spurious agile certification (YASAC?), and I really don’t like that. The authors continuously use ‘Agile’ as a capital-A, noun, rather than the lower-case-a adjective that it clearly ought to be, and I have ranted about that before. And then they resort to anthropomorphising in the fashion “Agile doesn’t say …”, which I find hugely objectionable.

On the other hand, this book does deliver on its claim to provide “a comprehensive introduction to the core values and principles of Agile methodologies.” It describes, without too much embellishment, the fundamental and constituent principles of approaches that support a responsive development process.

The writing is clear and mostly correct, though some things are stated as facts, when they are clearly not. For example:

“There are generally three styles of Agile delivery …”
“A key concept in Agile is emergent or opportunistic design.”
“TDD validates that … the design is appropriate with minimal technical debt”

Broad horizons
This book really triumphs by continually going further and offering the reader broader avenues of discovery. There are continuous references to techniques, approaches and research that go far beyond the usual agile trivia. There’s mention of BDD, Real Options, Feature Injection, Cynefin, Maslow’s hierarchy of needs, Reinertsen’s economic model and Kotter’s 8 stage model – to name just a few.

Some of these are explained in reasonable detail, others are just mentioned in passing, but all contribute to making this book a valuable resource for someone who wants to escape the narrow confines of a typical agile transformation. There’s more to it than stand-ups and planning poker, after all.
The book is split into 4 sections:

Introducing Agile: A whistle stop tour around the manifesto, that still manages to mention […]

By |May 13th, 2015|Agile, Practices|0 Comments

Rolling Rocks Downhill

It’s almost a year since I posted a glowing review of “The Phoenix Project” – a business novel, following in the footsteps of Goldratt’s “The Goal”, about continuous delivery. If you haven’t yet read it, then I’m going to recommend that you hold fire, and read “Rolling Rocks Downhill” by Clarke Ching instead.

I should point out that Clarke is a personal friend of mine and a fellow resident of Edinburgh, so I may be a little biased. But I don’t think that this is why I feel this way – it’s just that Clarke’s book feels more real. Both “Rolling rocks….” and “Phoenix…” have a common ancestor – “The Goal”; both apply the Theory of Constraints to an IT environment; and both lead eventually to triumph for the team and the lead protagonist.

There’s something decidedly european about Clarke’s book, which makes me feel more comfortable. The reactions of the characters were less cheesy and I really felt like people I know would behave in the manner described. (Maybe that’s because these characters really are based upon people I know ;)) There really are cultural differences between Europe and North America, and this book throws them into sharp relief. The inclusion of the familiar problems caused by repeated acquisitions and a distributed organisation only added to the feeling that this story actually described the real world, rather than an imaginary universe powered by wishful thinking. The only time that my patience wore thin was around the interventions of the “flowmaster”, Rob Lally, who is ironically a real person.

A truly useful addition in Clarke’s novel is the description of the Evaporating Cloud diagram, which (I now know) is one of the 6 thinking processes from the theory of constraints. For […]

By |February 12th, 2015|Agile, Continuous Delivery, Practices|1 Comment

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|0 Comments

Half a glass

Is this glass half empty or half full?

There’s normally more than one way to interpret a situation, but we often forget that the situation itself may be under our control.

I often find my clients have backed themselves into a corner by accepting an overly restrictive understanding of what they’re trying to achieve. They will tell me, for example, that this story is too big BUT that it can’t be split, because then it wouldn’t deliver value. Or, they might be saying that there’s no point writing unit tests BECAUSE the architecture doesn’t support it. Or even, it’s not worth fixing this flickering test, because it ALWAYS works when they run it locally.

I encourage them to rethink the situation. A slice through that story may not deliver the final solution the customer needs, but it will act as a small increment towards the solution. Minor refactorings are usually enough to make a section of the code independently testable. That flickering test is undermining any confidence there might be in the test suite – fix it or delete it.

Don’t try to put a spin on a half-full glass – rethink the glass.

Instead of asking if the glass is half-full or half-empty, use half a glass.

(It turns out that wittier minds than mine have already applied themselves to this proverb – here’s a bumper collection.)

By |December 15th, 2014|Agile, Musings, Practices|0 Comments

Recycling tests in TDD

The standard way that TDD is described is as Red-Green-Refactor:

Red: write a failing test
Green: get it to pass as quickly as possible
Refactor: improve the design, using the tests as a safety net

TL;DR; I’ve found that step 1) might be better expressed as:

Red: write a failing test, or make an existing test fail

Print Diamond
One of the katas that I use in my TDD training is “Print Diamond”. The problem statement is quite simple:
Given a letter, print a diamond starting with ‘A’ with the supplied letter at the widest point.

For example: print-diamond ‘C’ prints

 B B
C   C
 B B
I’ve used Cyber-Dojo to demonstrate two different approaches so you can follow along with my example, but I recommend you try this kata on your own before reading further. .
The usual approach is to start with a test for the simple case where the diamond consists of just a single ‘A’:
> PrintDiamond(‘A’) 

The next test is usually for a proper diamond consisting of ‘A’ and ‘B’:
> PrintDiamond(‘B’)

It’s easy enough to get this to pass by hardcoding the result. Then we move on to the letter ‘C’:
> PrintDiamond(‘C’)

 B B
C   C
 B B

The code is now screaming for us to refactor it, but to keep all the tests passing most people try to solve the entire problem at once. That’s hard, because we’ll need to cope with multiple lines, varying indentation, and repeated characters with a varying number of spaces between them.
The approach that I’ve been playing with is to start as usual, with the simplest case:
> PrintDiamond(‘A’) 


For the second test, however, we start by decomposing the diamond problem into […]

By |November 23rd, 2014|BDD, Cyber-Dojo, Practices, TDD|12 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.


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

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