The Story Card Is Not The Story

Pairing works for everything

We’ve all heard much discussion and general chatter about the value of pair programming. Amongst other benefits, it focuses the mind, speeds knowledge transfer, and builds in code review.

What’s not talked about so often is the value of pairing on non-coding tasks. Does it add the same level of value? Many of us would naturally pair up on demanding tasks, when we are doing things that require the input of several people, or when we’re unsure about how to proceed. What happens if we make it an explicit part of our day to day work? What benefits would we see?

I’ve been trying where possible to pair explicitly on tasks at Eden in the last few weeks and to encourage others to do the same. We’ve found the following so far:

Pairing works on UX and Design. Spencer is currently teaching User Experience (UX) and Design skills to a number of people internally. Pairing on UX and design work really helps people to pick up skills in a particular tool such as Photoshop, but also drives discussion about design and flow which wouldn’t normally have arisen. We’ve found the result to be better output, and an increased confidence in the person who’s less experienced.

Pairing works on Sales and Business Development. Last week I paired up with Richard, one of the guys I’m mentoring at the moment, to send some sales emails to three or four potential clients. One of these was to a potential new customer who I knew was interested in speaking to us, but whom I’d not emailled before. In explaining my reasoning for the words I was writing, he was able to learn about how to structure emails such as this, and I got valuable insight into how I should approach the task from someone with a different point of view.

Pairing even works on VAT returns! When you’re doing necessary and repetitive tasks such as the preparing the quarterly VAT return, it really helps to have someone beside you spurring you on. Last month I had to prepare one of these returns, and half-jokingly asked whether anyone was interested in helping me out. Thankfully, Elliot stepped up to the challenge. He started learning which expenses fall into the four or five VAT categories that exist, and how to prepare and submit a return online. Just by explaining the vagaries of EU, exempt, zero-rated, and outside-scope expenses to someone else, the job went much quicker, all the figures were double-checked, and it was simply much more fun.

Clearly pairing isn’t going to work all the time. People often need space from others to think, to avoid distraction, and to recharge. Rather than being dogmatic, what I’m asking is this: at the moment non-pairing in our work is the default, and pairing is the exception. What if this was reversed? What difference would this make to our teams?

Next time you approach a non-coding task at work, perhaps have a think about whether a pair would be beneficial, or what someone might learn through working with you. I could well be wrong, but I’ve yet to find a task where pairing doesn’t add some benefit. Can anyone think of one?

Your Code Is A Liability

Every chunk of code you commit is more for someone else to read, digest and understand.

Every complex “clever” expression requires another few minutes of effort for each of your team. They must now interpret what you wrote and why you wrote it.

Every line you add limits your project’s responsiveness to change.

Your code is a liability. Never forget this.

Why you can scale agile with the right attitudes

The more I work with teams, the more I think agile at any scale lives or dies based on attitudes of people in the organisation, rather than the scale at which you are attempting to do it.

Software development is hard, and it’s harder the greater the scale as Rachel’s post eloquently argues. However, I don’t think the scale is always the limiting factor here.

I’ve seen small teams with such a lack of trust that they burden themselves with suffocating process, and larger organisations with so much trust that they’re able to operate at the speed of organisations a quarter of their size.

As organisations get bigger, the trust required gets greater. If the trust exists, teams are able to remain independent and don’t get burdened with process.

If you need to work at one thing to make your large organisation more agile, work on building trust between teams, and between teams and management. Try small wins, quick feedback, and constant celebration. Decentralise decisions, give people ownership in their areas, and act like they’re as good as you know they are.

If middle and upper management could be persuaded to give up control and provide leadership instead, your scale matters much less than you might think.

Why BDD works solo, and why that matters for everyone

“The monotony and solitude of a quiet life stimulates the creative mind.”

– Albert Einstein

It’s possible to play chess and many other games completely solo, without anyone else to play against.

Incredibly, our minds are able to take on the role of both players in a competitive match. Our brains allow us to place ourselves in the opposing player’s shoes. Even more impressively, we are able to hide certain information from our own decision making process – such as what we’re planning to do next turn. We can analyse this incomplete set of information and play a move based solely on that, even if it’s sub-optimal.

BDD can be done solo

Using Behaviour-driven Development (BDD) on our own is much the same as playing a game against ourselves.

Instead of playing the opposing role, we take on the role of the stakeholder. We put ourselves in the shoes of the person paying for or commissioning the project. Because the BDD practice of writing gherkin-style features forces us to think in plain English, we jettison the role of programmer for a moment, and drift in the non-technical solution thought-space.

Why is this important? It’s a valuable exercise for a couple of reasons:

• We gain a fresh perspective on what we are doing. By taking our heads out of the code and putting ourselves into the role of the stakeholder, we are able to see the wood for the trees and get perspective on the code we’re writing right now. It might be interesting code to write, but does it matter?

• We gain a fresh perspective on the stresses of others. Every developer should take the opportunity to be a stakeholder once in a while. It’s very helpful to see what life it like on the other side of the estimation table. If all the members on a team are able empathise with the constraints and pressures our colleagues from different disciplines have, our team will run much more smoothly.

BDD solo is why BDD matters in the first place

Sometimes we confuse the concepts behind BDD with the tools used to practice BDD, like 3 amigo meetings, story breakdown and Cucumber.

BDD isn’t about the tools we use, it’s about the communication in the team. It’s about having the right conversations at the right times, hammering things out together, airing and refining thoughts and ideas, beating out ambiguity and forging common goals. This is why it matters.

If it was just about the tools, BDD would have been lost in the noise years ago, and BDD solo would be an expensive overhead. Why add another layer of tool complexity if it’s just us?

However, because BDD is about the concepts, not the tools, BDD works just fine solo: the process of deliberately stepping outside our developer role and thinking through our project from a product perspective gains us insight and understanding. This works no matter what tools, languages, frameworks or practices we may prefer.

When we’re solo, we dispense with a lot of the tools we don’t need. We don’t need to schedule a 3 amigo meeting with ourselves, for example. We’re left with a very pure form of BDD, set free from the needed constraints of multi-person teams.

Then we can begin to understand which of the common practices of BDD are only there to work around problems and can be discarded as needed, and which are truly foundational.

Try it out

Try using BDD on a personal project. Play the product owner, and write some Gherkin-style features. Pretend you can’t code. Really think about your problem without thinking about exactly how you’re going to solve it.

Whilst doing this, reflect on what practices you really need, and which you don’t. Which tools are less useful on your own? Which are more useful?

If you feel we’re just wasting time, I’d challenge us to think about what that’s telling us about our own ‘standard’ agile practice. How much of it is truly making us more agile, and how much of it is simply getting in the way?

4 questions to discover if you're *really* agile...

Here’s a challenge: how many of these questions are are true for your team? (Be honest.)

• Does our team value processes and tools (i.e. our task tracker, source control program, our agile process, our meeting cadence, etc) over conversations between team members?

• Does our team attempt to document everything (perhaps through long comprehensive ticket descriptions, or massively detailed cucumber features) before focusing on working software?

• Does our team think about about SLAs, response times and formal release procedures before shipping something and having a conversation with the customer about it?

• Is following the plan that you agreed in sprint planning more important than changing it in response to a customer?

If our projects sound like this, we’re doing exactly the opposite of the agile manifesto.

The anti-agile manifesto

Processes and tools over individuals and interactions

Comprehensive documentation over working software

Contract negotiation over customer collaboration

Following a plan over responding to change

Read both versions through. Which one sounds most like your project?