There’s no such thing as Declarative and Imperative

I finally managed to catch up with Dan North last week at NDC Oslo (since we don’t seem to be able to do that in our home city).

We were talking about Declarative vs. Imperative, when Dan said something that surprised me. “There’s no such thing.”

He went on, “Every Declarative is a chunking-up of something else, and every Imperative is a chunking-down, and you can chunk up and down to different levels of abstraction.” Chunking up and chunking down are terms from NLP, and mean either becoming more abstract, or more specific respectively. Dan continued, “Even Java is a more declarative form of bytecode, and bytecode is a more declarative form of machine language.”

Of course, he’s correct. I wrote a blog post a while back on the Myth of What and How that explores this idea, too, so I shouldn’t have been that surprised.

The terms are still useful for getting us out of our feature-driven, code-oriented brain and into the mind of the business, focusing on the goals we want to achieve and the capabilities we’ll need to deliver.

However, from a BDD perspective, the most important thing is that if your scenarios are too hard to maintain, and becoming too detailed, you might want to try chunking them up a notch, and capture some conversations with people who naturally speak in terms that don’t involve the UI. And if that doesn’t help, try chunking it up some more, and talk to the people who have the goals and the visions.

Having the conversation is more important than capturing the conversation is more important than automating the conversation.

Posted in bdd, nlp | 2 Comments

Deliberate Discovery, Real Options and Cynefin

Last week, I held a hangout with a few people from the ALE community. A few people very much enjoyed it and got quite a lot out of it – it’s far less formal than most presentations. It takes me a minute or so to get going, but once I do, this turns out to be the first time I’ve ever approached the idea of embracing uncertainty without starting with BDD or using it as a backbone.

There are quite a lot of experiments in this – it’s the first time I ever led a hangout – so please excuse the lack of preparation!

If you want to see something more formal, I also held a webinar called “Fail Fast, Fail Safe”,  on similar and related issues, complete with slides. I get to rant a lot in this one about people who “guarantee success” with Agile and Lean, and show some examples of how we all tend to do it without realising, anyway. Unfortunately we had a few technical difficulties outside of my control, so I drop out for a minute or so a few times. It got good votes despite the problems.

Big thanks to Ivana, and to Emily at Arrows Group, for arranging these sessions and making sure they were recorded for posterity!

Posted in Uncategorized | Tagged , , , | Leave a comment

BDD and Complexity Thinking tutorials at NDC Oslo

This year I’ll be running two 1-day workshops at NDC Oslo:

Behaviour-Driven Development

Have you ever wanted to know exactly what your customers want? Or helped them to clarify their requirements? Have you ever wanted to quickly pick up a new domain, or prove that the application behaves as expected?

BDD is a set of practices which help software development teams to have conversations about the behavior of their system by talking through examples of how a user might use it.

Over the last nine years the adoption of BDD has grown globally, with dozens of tools created, used by hundreds of projects around the world. In this tutorial we look at the original reasons behind the creation of BDD, bringing the focus back to the language and conversations which lie at its heart. We look at how BDD’s patterns can be applied at multiple scales – from the initial project vision all the way to the code – to deliberately discover and address ignorance in every aspect of software development, producing reliable, maintainable software that matters.

This tutorial will be non-technical, focusing on conversations rather than automation. We’ll also be looking how to identify the places in which BDD doesn’t work so well, which plays nicely into…

Complexity Thinking

Have you ever wondered why big-analysis up-front never worked? Or wished you had the language to explain that to other people? Ever wondered why some things seem straight-forward while others defy analysis and prediction?

In this tutorial we’ll look at Cynefin, a framework for making sense of the world and the problems we encounter in it. We’ll also look at Deliberate Discovery and Real Options, and how they play into it, and we’ll practice coming up with experiments we could run in complex spaces that would still allow us to keep our options open.

This tutorial, highly applicable to software development, may also change the way in which you live your life…

NDC Oslo

As well as these tutorials, I’ll be talking about “Cynefin for Devs”, which covers the overlap between the two tutorials, looking at how complexity thinking is specifically applicable to BDD and IT in general.

NDC Oslo runs from 12th to 14th June with tutorials on 10th and 11th. I hope to see you there!

Posted in bdd, complexity, conference | Leave a comment

Respect for People: it’s a Test, not a Pillar

On Monday at LKNA13, I ran an ignite talk on the title above. It was prompted by a video clip of John Seddon talking to Jeffrey Liker, suggesting that running interventions to make people more respectful might not be a good idea.

I partly agree with him. What is that we really want from our teams and our people? Tom Gilb has what he calls a “mafia offer” where you have to choose which of two things you value to sacrifice. I propose this related thought experiment:

Imagine that all the scientific data told you that the right way to get knowledge workers delivering was by brow-beating, yelling and command-and-control. What would you do as a manager or change agent? Would you focus on respect, or delivery? Which is actually more important?

Fortunately, we don’t have to make the choice. It turns out that the right thing to do is also the nice thing to do. All the good practices for delivering software tend to be respectful.

Yet we do make that choice, intuitively. A lot of the time, I see managers and change agents focusing on respect in order to get delivery. What if we turned that around? What if focusing on delivery could generate respect?

What is respect anyway?

Douglas Hubbard, in his talk on “How to measure anything”, proposed two questions:

  • Why do we care?
  • What do we observe when we have more of it?

I care about respect because it helps us get better outcomes. That doesn’t necessarily mean making people happy; I don’t believe that happiness is a good test.

I observe that respectful communication is focused on outcomes, or on options: either offering options to others, or explicitly retaining them. I observe that this tends to happen through forgiveness and transparency. I find that knowing about people’s constraints is useful. I find that respectful communication tends to be reflective, too, which matches the etymology of respect: it comes from the Latin specere or spicere meaning to look, so  it literally translates as “look back” or “look again”.

Conversely, disrespectful communication seems to happen more when constraints are unknown or non-existent, the system is unforgiving, and desired outcomes are unclear.

This maps very nicely to Dan Pink’s aspects of motivation: autonomy, mastery and purpose. Autonomy can only happen when people have the skills to do the job, and the constraints on them are just enough to allow them to organize to do it. Mastery happens when a system is forgiving enough to allow people to learn. Purpose happens when we share outcomes transparently. So respect and motivation are heavily linked.

But wait! I’ve just described a system of skilled people, learning together to find out what outcomes are desired and what the right thing to do might look like.

That looks an awful lot like software delivery anyway. Maybe the most respectful thing we can do is to get out of people’s way and let them get their job done?

Some systems encourage disrespect

In a system which encourages disrespect, we have to act as individuals if we want respect, and that intervention may not actually be rewarded.

Any system which has a lack of constraint (so people may not be skilled enough to act within it), a lack of forgiveness (so people cannot reverse decisions easily or take back their mistakes) and a lack of transparency (so desired outcomes cannot easily be known), is likely to cause disrespect.

Readers, meet Twitter: the place in which conversation is highly public, constrained only by the character limit, and in which we can only guess at people’s intent.

I have seen more disrespectful communication over Twitter than any other medium. It’s closely followed by email, which has the same problems as Twitter while enabling us to write even more. At least with email we have the space to express our intent and to ask reflective questions.

Disrespectful communication may not help you

We sometimes tell ourselves to count to 10 before responding to someone. This is because it gives us time to think about the outcomes that might result from our response.

I do this a lot. While I count to 10, I think about the options that I might be limiting for myself; the outcome that I truly want; examples of outcomes that I might get as a result of what I’m about to say.

I’ve been told that I come across as respectful, a lot of the time (nobody’s perfect). The thing is, I don’t think of myself as being respectful. I think of this behaviour as utterly self-serving, since it allows me to make mistakes while chasing the things I want. It also helps to set up systems in which other people respond the same way, giving us all more options and clearer understanding of intent.

Disrespectful communication often burns our bridges, leaving us with no options to reverse our decisions. We do it because we’re human, but not because it’s useful.

Caveat

These are highly experimental thoughts. It may be that no system is sufficient to counter the influence of those people who are determined to be disrespectful: people who hide their goals, hold grudges, and expect more from the people around them than can reasonably be given.

It’s just possible, however, that if we help to build systems which are focused, constrained, transparent and forgiving, we might actually end up helping to change those people’s behaviour as a result.

I would love to find out. So, if you behave differently as a result of this post, or set up different types of systems, please let me know what happens.

Posted in complexity, feedback, real options | 2 Comments

If you can’t write tests first, at least write tests second

I had a very interesting discussion at GOTO Chicago with the awesome Corey Haines, software journeyman and founder of the Code Retreat movement.

We were talking about the “Spike and Stabilize” pattern, and whether it was a good idea to suggest (as I have) that experienced TDDers can skip TDD under situations of flux and high uncertainty. I still maintain that you have to be really good at TDD to write spikes and stabilize them, and agree with Corey that most developers will get more traction from throwing away their prototypes once they have feedback, and start again “properly”.

However, I think the skill of being able to take existing, messy code, clean it up, and bring it under test, is hugely important.

Developers aren’t born knowing how to do TDD effectively. New developers will always be coming into our industry, and they’ll always be making a mess until they learn how to make things clean. If you can write your tests first, that’s absolutely fantastic! But if you can’t – or if someone on your team can’t – then being able to tidy up the code, and being able to show others how to do it, is IMO even more important than getting it right in the first place… and it’s not just novice devs who make the messes, either. We’re all human.

So if you can’t write tests first, at least write tests second. Then try writing them first next time.

Posted in spike and stabilize | 4 Comments

The Five Whos

Many of the companies I visit start with much the same problem: the development team aren’t collaborating effectively either internally or with the business, so they would like to adopt Agile, or better forms of Agile.

Usually these are pretty awesome companies producing quality software, and it can take a while to work out what the real problem is, and why they want to collaborate more effectively in the first place (other than a vague feeling that “it’s good”).

Asking around for more context, I usually find that while much of the software written is fantastic, a lot of it gets thrown away towards the end of the project, or is surplus to what’s truly needed for the release, and what the clients would really like is for that to happen much less, and releases to happen more often – the promise of Agile, delivered.

Asking further, it often transpires that the projects have either been created without a clear vision in mind, or that the vision has not been communicated clearly, or that the needs of peripheral stakeholders are only being taken into account in a very woolly fashion, perhaps with a single story card saying “Monitoring”.

If you ask the development team, “Why are you doing that?” five times, they will perfectly happily give the answer – as long as it’s a requirement that’s core to the project, at least. They may even, sometimes, be right.

Ask about something like security or performance, though, or try to find out who has the final say on whether something’s ready for production, and in larger companies the development team often don’t know. They think they know why, and that’s usually more dangerous than being aware that we don’t know. I can often tell because their stories either start with, “As a user…”, or miss that line completely, or it’s only ever one Product Owner who gets to come to the showcase.

I’ve just written a blog post for the Lean Systems Society called “Value Streams are Made of People”, which is related to this. Here’s a paraphrased tl;dr:

Before we ask why, ask who. Who will be the first person who cares outside of the development team if we don’t do this? Who do they have to tell, or if they were to (hypothetically) hide it, who would be the next person to notice? Who cares after that? And who’s the person whose job, or company or – heaven forfend – life is on the line as a result?

If we don’t know who cares, how can we know who to ask to find out why?

Posted in business value, stakeholders, stories | Leave a comment

BDD for Life – revisited at GOTO Chicago

A couple of years back, I ran a talk on how to apply some of BDD’s techniques to your whole life, and to life coaching.

I am very excited to announce that this year, at GOTO Chicago (April 23rd – 24th), I will be revisiting that talk, but this time I’ll be looking at some of the more crazy stuff we’ve introduced into BDD’s toolbox over the last few years, too.

There will be even more focus on Real Options and Deliberate Discovery – but I’ll be using Cynefin to show where, and how, you can usefully apply them in your life. I’ll be talking about Dan North’s “Three Ages” delivery pattern, and showing how that applies to our everyday activities. I’ll still be looking at well-formed outcomes as a test, but I’ll also show how we can never quite achieve the things we want the most, and every outcome we think of is just an example of what might happen. I’ll show how to fail, quickly and safely, using Feature Injection; how to get your life under test, TDD-style, before you refactor it; how and when to use real-life libraries and open-source to cut down the amount of work you have to do; and how to create your own for other people to use.

Want to come? Just use the code “keog150″ when registering here, and you can get $150 off your entrance price. Looking forward to seeing you there!

Posted in bdd, conference, life | Leave a comment