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

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?

Make Cucumber features more readable with this one weird trick

“Sorry I’ve written such a long letter; I didn’t have time to write a short one.”

– Blaise Pascal

If you’ve got an issue with your customers not reading your feature files, then try this: it’ll help ensure their eyes stop glazing over.

As I travel around coaching teams doing BDD, a common problem I see with Gherkin features is that they are nigh on unreadable except by the people that wrote them… and even then, the writers often have trouble explaining what they mean.

This often happens when non-technical stakeholders have little to no involvement in writing features, leaving technical people free to be as obscure as they like. It’s easy to write an obscure feature: it takes a lot less effort to ramble and choose the first words that come to mind, rather than crafting carefully considered prose. The pain comes later: an obscure feature is imprecise, error-prone and unmaintainable, as the effort required to understand it will stop others from maintaining it.

How I help people simplify their features

When asked to review the language of a preamble, I read the feature out loud, and then ask the writer of the feature what it means.

A deep breath often follows. “Ok, this is the one where…” The writer will explain the feature clearly and concisely using completely different words to what is actually written in the feature. They use great contextual information that’s missing from the written preamble, and work to ensure I really understand what’s going on.

Once I’ve got a good response that I can understand, I ask the writer to replace the preamble with exactly what they just said.

It’s never exactly what they said (natural language is different to spoken language, after all) but it’s always better than what they had before.

Sometimes, when asked what the feature means, the writer will give a short hesitant explanation, and then proceed to read out the preamble again. My response is normally: “yes, but what does it mean?” Occasionally I have to ask five or six times until I get a considered, clear response.

This also works for scenarios, scenario descriptions, tag names, etc.

Why this works

Sometimes it’s easy for us to get so wrapped up in the detail of the features that we’re writing that we’re unable to see the wood for the trees. Our features read much more like computer code than they do plain natural language.

Features are communication tools first and foremost, and leveraging different ways of communicating while writing them will help to ensure they’re as carefully considered as possible.

(This works for natural prose, too. if you write a blog, documentation or even just emails to colleagues, taking a moment to read your text out loud will tell you in an instant whether it makes sense.)

A challenge

Pick a feature on your project, and read it out loud. If it makes no sense, explain what the feature does to a colleague and ask them to write it down for you. If it reads awkwardly and could be improved, take ten minutes to do so. Your future readers will thank you for it.

How to give BDD a chance

Adopting BDD is hard.

It’s not that the tools are difficult to use: they’re already great on many platforms and fast improving in others.

It’s not that the technology is unproven: there are many examples of successful projects implemented using BDD.

Adopting BDD is hard because people aren’t perfect.

Everyone has their own agenda, and their own priorities. The product managers must write stories. The project managers must deliver stories. The devs must add features as quickly as possible. The QA’s must find as many bugs as possible.

Wait, what?

What we measure defines us

Our ultimate goal is to deliver working software that does what a customer asks. But often individuals are judged on quite different metrics.

If a developer is implicitly judged on their ability to add features quickly then anything that causes them to slow down whilst they learn new testing skills will naturally fall to the bottom of their priority list.

If a QA’s personal goals are all about the number of test cases they check for, then they’re unlikely to be able to make the analyst switch and drive the quality of the project from the front.

If we’re not helping our team look good with a suggestion, then we are going to have to work much harder to win them over. If the team is the atomic unit of success then we stand much more of a chance of being heard.

I wish I was the project lead!

It’s common for team members to wish they could become the lead on their team, because then they’d be able to change things and do it properly! Right?

Let me burst the bubble: leads have no more intrinsic ability to drive adoption than the rest of us. In fact, it’s worse for them, because everything they suggest is viewed with added scrutiny as a potential fad.

Sure, a lead could try and mandate a switch to BDD, but that’s not going to work. Here’s a newsflash: the only people we can control are ourselves.

If leads try to control people in the switch to BDD, at worst they’ll get a flat out rebellion. At best, they’ll get “mannequin BDD”: a team that goes through the motions but loses its soul, and delivers none of the benefits. We’ve all seen how that worked out for mandatory large-scale Agile switchovers.

How to give BDD a chance

Adopting BDD is hard. To give it the best chance on your team, try the following:

• Make your team look good. If we make our case in a way that devalues other team members (“look! BDD will mean we don’t need QA’s anymore!”) then it’s unlikely to garner wide acceptance. “Saving people’s time” is a good benefit, and eventually it will happen in practice, but “finding more bugs” and “shipping better software” focuses on making our team look good, rather than making them feel superfluous.

• Prove it. Show your team that it works. They won’t want to invest their time in something that they can’t trust. If we are able to demonstrably prove success at a small scale on our own work, then our peers are more likely to attempt to learn it.

• Get out of the way. Sometimes we’re working with people who are difficult to approach with new ideas if they haven’t thought of them themselves. In these cases, we’ll need to tread softly. We might not get to take the credit, and we might need to humbly reconcile ourselves to that. After all, we’re trying to introduce BDD to make our project better, not for personal praise and glory. Right?

Have you been through a BDD adoption process? How did you find it? What helped the practices take root in your team?