I was in a planning meeting with my project manager and several of the devs. “What happened?” the project manager said. “Why did this one story take so long?”

“There was some functionality we needed and didn’t know about,” I replied. “We managed to get it in before the deadline, though.” The business had been quite happy with that, and they were notoriously hard to please.

“If they’re going to change their mind like this,” the PM replied, “we’re going to have to introduce some kind of change control.”

“Please don’t,” I begged. “If you do that, the business will spend more time investing in getting things right to start with.”

“Exactly.”

“But they’ll still get it wrong. No amount of planning would have spotted that missing piece before we showed it to them! When they get it wrong now, though, they’ll encounter the change control and they’ll want to spend even more time getting it right first time. And they’ll still get it wrong, but now we’ll have made it more expensive for them to be wrong. We’ll have a formal process which means it takes even longer for us to find out what’s missing, by which time us devs will have to work to remember the code and the change will take longer. It will slow us down. So they’ll see that, and spend even more time trying to get it right, and before you know it they’ll be planning whole projects up front.”

We have a word for that. It’s called Waterfall.

That desire to control change creates a reinforcing feedback loop, in which the cost of change makes us want to invest up-front, which makes the change expensive later on, which makes us want to invest up-front, and so on.

In this case, it would have been pointless, except as a way of shifting blame and risk back to the analysts (and this was an internal project). The cost of change was quite low; we had clean code with a good suite of tests. It was only the cost of discovery, and the implementation that followed, that was really expensive.

Don’t confuse the cost of discovery with the cost of change.

Discovering something later on only costs more than planning for it if you’ve made a commitment to something else.

In fact, if you don’t plan for it, it can cost less. The newly-discovered knowledge will be fresh in everyone’s minds. Because the ideas haven’t been known for long, nobody’s mentally committed to them either, which makes them easier to question and clarify.

This is even more important when there’s a chance that the analysis might be wrong (and there’s always that chance; we learnt this from Waterfall). If you plan for something that you later have to revert, you’ve introduced a cost of change right there. Perhaps the cost is just changing some documents. Perhaps the developers have designed for the plan, and built on top of the thing which needs changing.

But we need to do some planning, right? Otherwise the chances of us being wrong and building on top of the wrong thing are even bigger, and there’s even more chance that we’ll have made commitments the wrong way. So how should we plan?

I’ve got few more guidelines I’d like to share. Here’s the first:

Keep the cost of change low.

This is more important even than planning, because there’s always a chance that we’ll get something wrong.

This is what we’re aiming for: the ideal, low cost of change on an Agile project.

The first thing to notice about this is that the cost of change is not zero. That’s going to become important in the next section, and it’s what drives the team’s desire for change control and starts kicking off that Waterfall loop.

The second thing to notice is that this bears little resemblance to actual, real Agile projects.

On a real Agile project, it’s likely that we have fluctuating levels of stress, concentration, experience and desire for feedback. All of these – or lack of them – will lead us to occasionally write code that is, shall we say, less than ideal.

It takes discipline to write code that’s easy to change. On a real Agile project, we tend not to do it all the time. Oh, we might say we do, but we don’t. Not always. And if we do, our team-mates don’t. The real skill isn’t in writing clean code – it’s in cleaning up the horrible mess we made the week before. And it takes even more discipline to do it afterwards, especially if you’re under pressure to just hack the next working thing in too.

If we don’t clean up and keep that cost of change low, we’re making a commitment to the wrong thing. The longer that commitment stays in place, the higher the cost of change will become. We’ll find ourselves on that Waterfall cost of change curve, and the longer we’re on it, the more expensive it is.

I’ve found the skill to clean up afterwards is even more important in high-learning projects, where a lot of the technology or domain is new, at least to the team. There’s no point in writing tests up front for a class when you don’t even know what’s possible, or what other frameworks and libraries will do for you, or what the business really want. In those environments, rather than TDD or BDD, teams tend to Spike and Stabilize. The spikes aren’t really prototypes – they’re small pieces of features, often with hard-coded data behind them, designed to get some feedback about techology or requirements. Dan North, who gave me the term, might write more about this later if we ask nicely, but for this post, we can simply bear in mind that the skill to stabilize later – ensuring that the cost of change is lowered – is often more important than the skill to keep the cost of change low up-front.

Because we get it wrong too.

Assume you got it wrong.

Human beings are hard-wired to try and get things right, and to pretend that they did even when they didn’t. I love this list of cognitive biases on Wikipedia. These are just some of the ways in which we get it wrong and don’t even notice.

If we assume that we got it wrong, then we start to look for feedback, and quickly. This is difficult for most human beings. We much prefer to get validation than feedback; to be told that we did it right, rather than finding out what we did wrong. Our brain gives us these little kicks of nice chemicals when we learn that we did something right, and it feels much better than the other kind.

If we can remember, though, that we probably got it wrong, our focus will change. Instead of trying to invest in good requirements and nice code, we’ll try to find out what we got wrong in the things we’ve already done. Of course, we need to invest in stabilizing what we’ve done, or the cost of change goes up, and that will make it more expensive later if we find out we were wrong, which is the assumption we were trying to make in the first place… ah, the paradox!

There’s a fine balance to be struck between getting quick feedback – often itself an expensive proposition, given the business of most domain experts – and getting it right up front. So where does the balance lie?

Don’t sweat the petty stuff.

If it’s easy to change, don’t worry about it. Analysts, learn what’s easy to change. Typos, colours, fonts, labels, sizes, placement on the screen, tab order, an extra field… these are all usually easy to change, and do not normally need to be specified up-front. Even if you have a particular style you want to see on a page or form, this can usually be abstracted out and changed later – just let the devs know that you want that consistency at some point.

It’s more important for us to know the rough shape of what you want to see, and the flow and process of that information. We don’t want to know every field on an order item. We just want to know that it needs to be sent to the warehouse and stored locally because you’re going to check the money in the till and count the stock. The fine detail of that is pretty easy to change, so we can get feedback on it later. Getting the fine detail right would definitely be an investment, and we might have got the big picture wrong.

Deliberately discover things you’ve never done before.

Dan North wrote an excellent post on Deliberate Discovery, and I’ve been using it to manage risk on my projects for a while now. It’s one of the most important tools in my toolbox, along with Real Options to which it’s strongly related, so I want to cover how I use it here.

I really like using Cynefin to help me work out what to target for discovery. We treat a lot of software as if it’s complex, and we talk about self-organising teams and high learning environments, but in reality there are huge chunks in most applications which follow well-established rules, have been done a thousand times before and probably have libraries or third-party apps to do the job for you. They’re not complex. They’re complicated. They require the application of a bit of expertise, and are likely to be done right and never changed again. User registration and logging in are great examples of this. You don’t need a big, thick document to describe them. The fine details might change, of course, but we already know not to sweat the petty stuff.

It is OK to plan some aspects of a system as if it’s Waterfall – for instance, deciding up-front whether you want to use your own login or let Google authenticate. Even better than requirements documents, and quicker, is to say, “It’s user registration. Make it work like Twitter’s, but we also need the user’s loyalty card number. We should offer to send them a card if they don’t have one.” Dan North calls this pattern “Ginger Cake” – it’s like a chocolate cake, but with ginger. He even cuts and pastes code. And it’s OK! Honestly, it is! This code is also absolutely prime for TDDing – if you actually have to write it yourself, that is, since it’s been done before so someone’s probably written something to do it for you already. You can also give this code to junior devs, for whom it’s new, and guide them in TDDing, making it perfect pair-programming territory. Everything you have ever been told about Agile software development applies particularly in this place.

Fortunately, most applications have a minimum set of requirements that they share with other, similar applications. David Anderson calls these commodities – table stakes that you have to have just to play the game – so *most* code in an application will end up going this way.

The places in which we’re most likely to get it wrong, and need fast feedback, are places where we’re doing something new. They might be technological, particular to a domain, or just things that the team themselves have never looked at. My favourite book for understanding risk is “Waltzing with Bears”, which starts the first chapter with, “If a project has no risks, don’t do it.” It’s these new, risky aspects of the project that differentiate it from others and make it valuable in the first place!

For new and risky aspects of a project, the best thing to do is assume you got it wrong, and work out how quickly you can get feedback on how wrong you are.

Any new or unknown aspect of a project will need to be changed.

I was chatting to one of our analysts. “I can see this feature is in analysis at the moment,” I said. “Does that mean it’s the next thing we want the developers to do?”

“Oh, no,” the analyst said. “It’s only there because the analysis is quite complex. It’s all new stuff, so we’re having to be careful with it and it’s taking a bit of time. Once we get the analysis done, the development should be very easy, so we’ll do it later.”

“Oh, the development will be easy, I’m sure… but wouldn’t you like to find out what you did wrong now, rather than later, while it’s still fresh in your mind?”

The analyst smiled. The company was very much more used to Waterfall, and the idea that it was OK to get it wrong was something very new.

It’s OK to get it wrong, as long as you get feedback quickly, while the cost of change is still low. By working out which parts of a project are unknown or new, and targeting those first, we make small investments while the cost of change is still low.

Keep your options open – do the risky stuff first and keep tech debt low.

Anyone who’s run into me at conferences will know how much I love Real Options, and it’s really at the heart of the cost of change.

The only reason change costs more is because of the commitment that we already made. Chris Matts describes technical debt as an “unhedged call option”. Edit: while Chris came up with the metaphor, it was Steve Freeman who described it. He says, “You give someone the right to buy Chocolate Santas from you at 30 cents each. That’s fine, as long as the price of chocolate stays low. As soon as it goes up, you still have to pay to make the Santas, and now you’re in trouble and your company is going bust, because you didn’t give yourself the option to get the chocolate somewhere else.”

Similarly, technical debt is absolutely fine until we’re called on to act, and act fast. At that point, we’re in trouble. This is the biggest reason for keeping the cost of change low – because it gives us the option for change, later. It’s a frequently-cited reason for replacing legacy projects – and, bizarrely, often forgotten when the pressure mounts and the business want their replacement app.

This isn’t helped by common practices of estimation and the associated promises, which often lead to that pressure building up in the first place. Rather than making these promises up-front, why not try the risky bits first? I often hard-code data so that I can get feedback on a new UI early, or I spike something out using a new library or framework, or connect to that third-party application just to see what the API is really like to use, or have a chat with the team writing that other system we’re going to need in June, so I can find out how communicative and receptive to feedback they are. Doing this means that we give ourselves the most time to recover from any unexpected discoveries, and we can worry about the more predictable aspects of a system later.

Once we’ve got spikes out of the way, adding tests to act as documentation and examples for any legacy code we’ve created, cleaning it up so it’s self-commenting, ensuring that architectural and modular components are properly decoupled, etc., all help us to stabilize the code. At the same time, the effort involved in creating stable code is itself an investment. If there’s a good chance that the code might be wrong, it could be worth getting feedback on that – knocking up integration tests, showing it to the business, testing it, getting it live – before it’s made stable.

That way, the commitment made is small, and the cost of change is low.

Just remember to clean up and keep it that way!

Update: Dan is currently writing about Spike and Stabilize and Ginger Cake as part of his “Patterns of Effective Delivery”. If you’re interested in finding out more, you might like to watch his Roots talk on the topics.

A feature is something tangible that works and which we could potentially deliver, if it was enough to provide business benefit. Usually a bit of a screen or page, together with all the logic and validation associated with it, is a feature. A feature is the highest-level thing which a developer could work on without doing significant bits of analysis. It’s a part of an idea made at least concrete enough to imagine.

A story is a part of a feature on which we can get feedback from relevant stakeholders. For instance, we might code the UI, then the validation and messages, then an aspect or two of the behaviour behind the UI. Each of these would be a possible story. The only real reason for splitting features into stories is to get faster feedback and a better idea of progress.

A task is a part of a story which doesn’t allow us to get feedback from relevant stakeholders. If you can get feedback, it’s probably a story rather than a task, because it affects the UI in some way, or at least gives something that can be visibly verified and critiqued and which stakeholders care about. There are lots of UIs and lots of stakeholders and users, so “put logging in to help maintenance debug the situation where the elephant appears on the screen” might be a perfectly good story. Anything that’s just a part of a story is a task.

A task can’t really be tested either, even by a developer. You have no idea if a database has the right tables or data until you connect it to something. You have no idea if an interface to another system will work until it’s actually talking to that system. You might unit-test it, or run some queries, but it’s a level below the feedback and user testing available for features and stories. (There are higher levels of testing too, in which we can look for user capabilities and business outcomes, stakeholder goals, profit / loss, etc. – so you can’t really tell if *anything* works until you put it into production – but that’s a blog post for another day).

Why do some teams split stories into tasks?

A lot of Scrum teams particularly do this, because it’s traditionally taught as part of the Certified Scrum Master course. Hopefully good CSTs, and their CSMs, are teaching the benefits along with the practices.

It can lead to more accurate estimates. Splitting stories into tasks can help developers to think about the amount of work involved in a story, and find any pieces they missed.

It can help with collaboration. By splitting a story into tasks, developers can each take that task – usually a different horizontal slice – and work with minimal merge conflicts and just a bit of adjustment to get their piece working with other people’s. Splitting a story into tasks is useful for swarming, and a lot of swarming teams do this instinctively, even if they haven’t written the tasks down.

It can help senior developers mentor junior developers and verify that they’re taking a good approach towards a story. Some mistakes are worth avoiding.

They can be used as a measure of progress to someone tracking the team, like a PM or Scrum Master.

Why don’t other teams do this?

Some teams prefer to focus on delivering something on which they can get feedback, and find the tasks distracting.

There are also other ways of getting accurate estimates. Talking through scenarios can help with this. A lot of teams don’t use estimates anyway, preferring to stick to SLAs or their own instinctive understanding of how much work they can get done and whether they’re going to release on time. Anther purpose of estimation is usually so that the business stakeholders can have trust and confidence in the team, and there are different ways of getting the trust of stakeholders, too.

What bad things might happen if we split our stories into tasks?

Splitting stories into tasks might indeed distract from delivering something on which the team can get feedback. When a developer sees a list of tasks in front of him, he tends to work through those tasks methodically. He might not notice that, for instance, the team isn’t going to deliver *any* stories this week.

Using tasks to estimate team progress can also be misleading. If all the developers end up working on their own stories, the PM might see lots of tasks being done. If none of those stories are ready for the showcase, though, the team won’t be able to get feedback from their stakeholders – and might end up building the wrong things altogether! Also, the Pareto Principle suggests that 20% of the causes are responsible for 80% of the effects – or that the last 20% of the story might take 80% of the time. Often developers will start with the easy bits and leave the hard things until last.

People seeing the tasks can use them to micro-manage the team, asking who’s working on which task, or even assigning particular tasks ahead of time! But anyone with a manager or Scrum Master who does this has bigger problems than the task-splitting, I think.

Why do you absolutely hate people splitting tasks then putting hourly estimates on them?

First and foremost, this harks back to the old myth that time = work done. Even if developers are only held to be productive 50 or 60% of their “ideal” working day, the focus is still on the number of hours spent, rather than useful software being produced. It’s perfectly possible to spend hours on something that doesn’t work. A team which signs off all its tasks is subtly encouraged to say that they’re “done” without checking that the software they’re producing is useful.

What about the developer who plays with something else while turning over a problem in the back of his mind, then delivers an ingenious solution in 2 hours? Or the developer who wants to try out another way of solving the problem which might involve a steep learning curve, but which would benefit the project in the long run? By pinning these developers down to their hourly estimates, insisting on a certain timescale of productivity, we encourage them to tread the path they had in mind when they made the estimate, even if a different idea occurs to them at the time. Since human beings get a kick out of being right – suffering horribly from confirmation bias and the preference for validation – just the act of estimating the hours will pin them down subconsciously. They may not even think about the problem or have the new idea! Hourly estimates can stifle innovation, and the less wriggle room there is, the more innovation will be stifled.

Finally, it encourages micro-management. A project manager who sees a developer working on some tasks that should have taken 8 hours, but have taken all week, might wonder why that developer is taking so long. However, uncomfortable enquiries will only cause the developer to pad their estimates next time – and work expands to fill the time available, so the team will eventually slow down.

Should we do it or not?

If you think splitting stories into tasks might be helpful, try it. If it doesn’t help, stop. However, please resist the urge to put hourly estimates on them – or to ask that your team does so.

Requirements come from above

In a straw-man Waterfall project, requirements are delivered to senior developers to design. Senior developers deliver the designs to junior developers to implement. Managers instruct teams in how to progress. We have, in our language and hierarchical organisation, a metaphor which maps “up” to the origin of the project, and “down” to the implementing details. We also think in terms of seniority and power, with the originators of the vision having that seniority and power, and the more junior developers and testers being at the bottom of the pile. We even talk about the team members “on the ground”.

Think of every organisational chart with the managers at the top, or the V-model in which the requirements are split into increasing detail towards the bottom.

In life, things naturally flow downwards.

Orders come from above

The other hierarchy with which we’re familiar is the military. We can map our employment and communication hierarchies to those of the military. We even talk about companies fighting for market share, defending their reputation, a hostile trading environment, captains of industry, command-and-control management, etc. It’s hardly surprising that we have, in our subconsciousness, another pattern: that the more junior members of a company should obey orders. (This isn’t necessarily true even in the military, but it fits our perception of it.)

Turning the world upside-down

I once heard of a business analyst who got tired of explaining the requirements to the developers. “I’ve told you three times already!” she snapped. “Everything’s clear. Just do it.” The BA sees the developers as working to fulfil her requirements. They serve her needs, rather than the other way around.

When we write and deliver software to a user on an Agile project, we ask them for their feedback.

• Is this useful to you?
• Is this easy to use?
• Is anything difficult to use?
• Does it help you to do your job more effectively?
• Can you think of any ways we could make this more intuitive?
• What would you like next?

Because we think of communication in terms of orders, we also think of junior staff delivering value to senior staff. We don’t necessarily think in terms of the communication itself being a form of delivery. If we did, we might ask for feedback from the users of our communication.

• Is this communication useful to you?
• How easy was our communication to use?
• Was anything difficult to understand?
• Did it help you to do your job more effectively?
• Can you think of any format you’d find more intuitive than this?
• Any questions?

If the BA above was a piece of software, her users would be filing bug reports, working around her, and using her competitors instead. I imagine instead that she’ll get a poor review and teams will prefer to work with her colleagues. If they only have the one BA to work with, the project will probably fail – the developers won’t be able to use her to get their job done.

Stakeholders aren’t users

I’ve written about this before, and it takes on a new importance in the context of users, and stakeholders, of communication. When we get a management report, we often think, “So what?” We hit the delete key. Instead, we could try to think, “Who is it that cares about us understanding this? Why does he care?” It’s often the case that a user is meant to do something, as part of his job, which is for the benefit of someone else. Similarly, we may be asked to understand or act on something for someone else’s benefit – and it won’t be the person delivering the message either.

The stakeholders of communication on a project are often stakeholders of the project itself – the security expert, the chief architect, the facilities manager, etc.

Project experience

Eric gave me the concept of a “Project experience”. In the same way that we can think of communication as a form of delivery, we can think of the experience that our stakeholders and customers have when they ask us, as a project team, to deliver their code. We can ask usability questions about the team.

• How easy is it to use the team?
• Is it easy to see what’s going on and get information about the progress of the team?
• Is it easy to undo a mistake?
• Is it easy to input a new idea?

We often hold retrospectives amongst ourselves to work out how to change our processes. I’d also like to see us actively getting feedback from the people who use the project. And next time someone gives you some instructions which are unclear or don’t help you to do your job, perhaps this metaphor will help.

You want to measure, and improve, something about your project or people. You’ve got a good idea about how to do this. Perhaps the metric you want to use is already widely measured. Perhaps it’s been in the industry for a while. It might be a KPI, related to a management incentive or perhaps you simply want to replace your existing metrics with something better.

Before you put that measurement in place, borrow my Evil Hat.

The Seventh Hat

Edward de Bono identified six different ways in which people prefer to think, and created the six famous thinking hats.

Unfortunately for humanity, there’s a seventh way in which we think. It comes unconsciously from our innate desire for an easy life, our craving for approval, and mechanisms of feedback which tell us whether we’re doing the right or the wrong thing. It comes more consciously from our desire to be paid more, keep or improve our jobs, and make our bosses happy. If we’re determined to be evil, we can think of it as a way of manipulating the system for our personal gain.

The problem is, even if we aren’t evil, we do start responding subconsciously to the feedback provided by our measurements and responses to them. Like an electrical current, we tend to take the path of least resistance. If we’re seeing problems as a result of the metrics, we’ll address the problems – and if we’re doing it subconsciously, we may not actually analyze the cause of those problems, or the effect of our changes outside of the system. We’ll respond to praise for achieving the targets, and to criticism for missing them – even if the targets and the praise are implicit.

By putting on the Evil Hat, we can move those subconscious reactions into the conscious realm. Pretend, for a moment, that you have no care whatsoever for the success of your project, your team or the bigger picture. You are merely interested in your own personal gain. You are not interested in making life better for anyone else but yourself. This is what your brain is already doing, before the altruism in your conscious mind or subconscious habit kicks in (and there are plenty of arguments to suggest that altruism itself is merely done for psychologically selfish reasons).

Congratulations. The Evil Hat has just turned you into a sociopath.

Sociopaths can destroy your company or project

When a sociopath wants something, they can resort to any means necessary to get it. This article, Sociopaths in High Places, illustrates some of the behaviour we can expect from sociopaths, including bullying, cruelty, manipulation and outright fraud.

This only happens because sociopaths don’t care about other people. Of course, most of us are born with empathy. We feel other people’s pain. Don’t we?

When we’re stressed, our adrenaline levels rise. We are primed for fight or flight. Our instincts are turned inwards, to our own survival. We are more likely to act in our own interests, and less likely to worry about those around us. This rather lovely article talks about the circular nature of stress and concentration, relating the feeling of compassion to the state of relaxation. The opposite is also true.

So, let’s imagine that we’ve been set some targets, and we’re not meeting them. Our boss (who has targets of his own) is putting the pressure on us. Now we’re starting to feel stressed, which makes us less empathic. Even if we’re not sociopaths ourselves, we’re capable of selfishness, and it’s starting to show.

Sociopaths are in charge

The targets in any company tend to filter down from the top. The shareholders want a profit. The CEOs, board members and upper management are in charge of delivering that profit. Their targets and metrics are clear. As Chris Matts has said when talking about Feature Injection, they need to “make money, save money or protect money”.

Two psychologists, Paul Babiak and Robert Hare, started applying a checklist for psychopaths to the boardroom members of corporations, and published some of their findings in a book, “Snakes in suits”. This transcript of a radio interview with the authors and other experts illustrates some of the behaviours they found.

It’s often easier for a psychopath to achieve their goals by destroying others. Certainly, they have no empathic reason to want to help others, and they will protect themselves and the power they amass quite jealously. There are some phrases that we can look for to see if we or our colleagues are becoming less empathic with stress:

“It’s not my fault.”

“X did it.”

This is us, protecting our power and our jobs at the expense of someone else. We’re not thinking about the impact on others when we say these things. We’re doing it to protect ourselves.

Of course, true sociopaths and psychopaths (Wikipedia defines the difference nicely) will protect themselves in advance, so rarely have to resort to passing the blame – it will already be obvious to all powerful onlookers that they are blameless. Or, worse, the powerful onlookers will themselves have sociopathic tendencies, and be in cahoots with their sociopathic comrades.

As the stress mounts, the more clever amongst us will start protecting ourselves. We keep those emails, do everything in writing, and insist that processes are followed, making sure that we cannot be blamed for anything more than being cogs in a giant machine. The more creative amongst us find ways of becoming more influential and indispensable – hoarding knowledge, hiding our lack of skill, making friends in high places, setting others up to take the fall. As the habits develop, we become more and more sociopathic ourselves. Anyone who finds themselves unable to dispense with morality leaves, and the company culture is now fully riddled with blame.

Sociopaths can save your company or project

As Robert Hare says in the radio interview:

Enlightened self-interest is not a bad idea for psychopaths, and try to indicate or convince them that there are ways in which they can get what they want and need without having to actually harm other people. “Enlightened self-interest is not a bad idea for psychopaths…” Now it’s easier said than done, because their behavioural patterns are fairly entrenched. But these are not stupid people, I mean the range of intelligence amongst psychopathic populations is the same as it is in the general population. These are people who know what’s going on.

So, what’s going on?

The word is spreading. Self-organising teams, in which the members are not merely cogs, are more performant. Employee empowerment and learning improves company morale, reduces expensive employee turnover and can help make money. Transparency in the workplace fosters productivity. Incremental delivery reduces risk, resulting in more successful projects and more fulfilled staff; even governments are listening.

It turns out that in most cases, doing the empathic thing – creating positive cultures and professional experiences for employees – is also the most profitable thing, helping those sociopathic CEOs. It’s the most productive thing, helping their cahooting managers. If it involves transparency, it’s hard for anyone else to manipulate, and because an enabled, positive, productive workforce creates options it reduces risk and provides the greatest possible control in the event of uncertainty.

The sociopaths of the world – CEOs, managers, and democratic governments – are also starting to listen. If you know yourself to be a sociopath or a psychopath, you’re in a position of power, and you’re not paying attention, then you’re losing this race.

If, however, you are already cynically manipulating your company culture to be better, faster, more productive, empowered, self-organising, transparent, learning, improving, Lean, Agile, incremental, feedback-driven, forward-thinking, creative, optimistic and prepared, then congratulations. You are about to rule your slice of the world. Just what you always wanted.

Put on the Evil Hat

By pretending to a certain amount of sociopathy before we start introducing metrics and targets, we can ask ourselves, “How will we respond to these targets?” Will we game the system, manipulating these in a way which serves our purposes, but not the whole? Are they perverse incentives in disguise? Will we see anti-patterns emerge as a result?

We can also use the Evil Hat to turn this around. What metrics and targets could we put in place that would lead to even more productive behaviours? That would lead to success, and therefore maximise our personal gain? How can we make sure that the things we’re measuring are the things we most want?

It’s Good to be Evil

I was in a meeting when someone suggested introducing a KPI for measuring team leaders. “One of their jobs is to remove obstacles from the path of the team,” a manager suggested. “We should measure how many obstacles they remove.”

“Excuse me a moment,” I grinned. “That sounds like fun. Just let me put on my Evil Hat, and I’ll tell you what I’m going to do in response…”

The only answer I can come up with is this:

Things will be changing. You’ll be in a better place to respond to change. Your people will have a culture of courage and respect, and will seek continuous improvement, feedback and learning.

I don’t know what your process will look like. The Lean and Agile communities have some ideas you can use to start with. Not all of them will work. Your processes will change, and keep changing.

I have no idea what skills your people will need. The people you have are good people; start with them. The need for their skills will change, and keep changing.

I don’t know what language, tools or technologies you’ll be using. Start with something that’s easy to change. Technology will change, and keep changing.

I don’t know which projects will succeed. Start with the most important project, or the most risky, or the one which has the highest cost of delay. Your market, your business and your customers will change, and keep changing.

There is no end-state with Agile or Lean. You’ll be improving, and continue to improve, trying new things out and discarding the ones which don’t work.

If you do find yourself with an end-state, the chances are that you’ve documented your processes somewhere, and are now asking your teams to adhere to them. Either your process is perfect, or you haven’t reached the end-state yet. I’m guessing your process isn’t perfect. Change, and keep changing.

I will also be running a workshop on giving and receiving effective personal feedback, and judging the Programming with the Stars competition.

We have been asked, as presenters, to provide materials for our sessions. Unfortunately the BDD clinic has capacity for 300 people! So, I’m not going to be able to bring enough post-its, index cards, pens, pencils etc. with me from England. If you’re coming to the clinic and fancy writing down any of our grains of wisdom or the pearls that you form around them, please bring your own. I imagine most of the vendors and exhibitors will have free pens that you can grab (try the Thoughtworks stand, they’re very friendly).

If you’re coming to the Feedback workshop and you can’t remember what you learnt, I should have done my job better. You might want to bring some paper and pens anyway. There’s always room for improvement!

I think it depends on how a feedback sandwich is used. I tend to use it to make a safe space in which I can share feedback with people without them feeling like the world’s just been cut out from underneath them. I find it helps me phrase feedback in a very positive, constructive manner.

This is not, to me, the most effective feedback sandwich, despite adhering to any rules I might previously have given:

So, here’s how I’m using the feedback sandwich now (all other rules of giving effective feedback also apply).

I value this…

Whenever someone gives me some advice or criticism, it makes me want to change things so that I’m more effective, or so that the problem is fixed.

For instance, a graphic designer gave me some feedback on my new business cards. “You need to revisit the whole card,” he told me. “Change the shape, add some texture. Put in a tag line, something catchy that people can remember you by.”

Well, I’m not a graphical artist! Nor am I pretending to be, so the feedback didn’t really get me down. I knew I couldn’t get new business cards ready in time for the conference, nor can I really afford the services of a graphical artist right now. I thought to myself, “I could just give out my email address; that’s worked for me before. I don’t really need to take my business cards to the conference.”

Then it occurred to me much later that perhaps that wasn’t the artist’s intention. So I asked him: “Would it be better for me not to take the cards at all?”

“Oh, no! That’s not what I meant. They’re fine, I mean, they’ll do the job if that’s what you want. I just wanted to give you some help to improve them.”

“Fantastic!” I smiled. “So, what do you like about them?”

“I like the colour scheme, and the symbol you’ve chosen – the big red moon – is very powerful.” And then he described the things he liked about the card.

Without anchoring the things that I value, I am in danger of losing them altogether. If I bring up someone’s annoying behaviour when they pair program with me, they might just stop pair programming. If I suggest a different way of solving a problem, they might stop thinking of themselves as problem-solvers. The human mind has this dangerous way of abstracting generalisations from particular situations, and confidence can be easily knocked! Even in the situation with the business cards, where I didn’t really feel depressed by the feedback, I was in danger of throwing away valuable work.

So, I can anchor the things I value; things that might change as a result of what I’m about to say.

And…

The next bit of the “feedback sandwich” is the trickiest. It’s always tempting to put the word “but” or “however” in here! The word “but” has the impact of negating the first part of the sentence. I’ve heard this example a lot:

Mum: Well, he’s ugly, but he’s rich.
Daughter: Yes, Mum. He’s rich, but he’s ugly.

See what I mean?

Even the act of thinking “but” tends to lead me to phrase it unconsciously. So I’ve been trying to replace it with the word “and”. Like “should” in BDD, this leads my brain to go a different way. Instead of thinking of how to phrase the negative advice in a way which is palatable, I find myself phrasing things very differently.

This has led me to new ways of providing feedback. I can even talk to managers now!

I don’t always need to criticise the behaviour that’s causing me problems in order to suggest changing it. Thinking about the last part of the feedback sandwich, and using that to work out what goes after the “and…”, helps me work out what to say.

…I want this.

There’s some place that I want to get to; some goal that I want to achieve. NLP’s well-formed outcomes can help here, or if you’re a software developer, think about the SMART technique for writing tests. How will you know that you’ve got to the place that you want to be in? What will you see? What will you hear? What will you be doing – or not doing – differently?

Even when there’s some particular unpalatable behaviour that really does need to stop, this can help.

Even when it’s really unpalatable behaviour.

Provide options

I like the feedback sandwich because it sits very well with GROW, in which we move to our Goal from our Reality, looking at Options and selecting a Way Forward. Reality is the current behaviour that we value (not the problem!) and the Goal is where we want to get to.

In the examples of feedback I’ve given above, I’ve provided multiple options, or left an opening for them. Even when there’s only one option that can realistically be taken – nobody’s going to say “no” when I ask for more time to type code without having a back-seat driver telling me what to do – I’ve phrased it in a way which makes the other option available. Using words like “maybe”, or asking questions like “What do you think? Can you help me?” can invite other options, things that we haven’t thought of.

There’s safety in these options. By providing them, and allowing the coachee to make the choice, we’re saying, “You have the power here. You get to make the choices.” All I’m doing is sharing a place that I want to get to with you, and leaving it up to you to decide how to get there. You can ask me for help if you want, and even give me feedback if there’s something that I can do that might make a difference.

I was reading this article which starts with an assertion, “old commented-out code is an abomination”. That makes me wince, because an abomination is something hateful, wicked or shamefully vile, and what I see is someone learning! That’s not vile at all; it’s a wonderful thing, and I heartily encourage it. Instead of insisting that the code is deleted, I might suggest trying it out, and seeing which one works best. I might even talk about the benefits of deleting the code. Creating it as an option, instead of “the only right way”, will allow Alphonse to feel safe trying out other things, too.

(Incidentally, the way that the feedback is given in the scenario with Alphonse isn’t very safe. Giving feedback in private is usually better than giving it in public.)

Big thanks to Chris Matts and Real Options for helping me see the similarities between GROW and the sandwich model, and fitting Options into it. I’ve found it’s worth paying to create Options, and I might sacrifice some related feedback I want to give, or my idea of “the right way to solve it”, in order to do so. This has been very effective, and I find it a very natural way of giving feedback now.

Why don’t you give it a try?

Once upon a time, during World War II, there was an island on which planes landed. The islanders loved the planes landing, because they brought goods that the islanders couldn’t normally get. The soldiers shared the goods with the islanders, and the islanders considered themselves wealthy, lucky, and blessed by the gods.

When the planes stopped landing, the islanders missed the cargo that the planes had brought, and decided they’d try to bring them back.

They did the same things that they’d seen the soldiers do to make the planes land. They created signal fires, waved at the sky, wore coconut-headphones on their ears and made replica planes from wood and straw. The cult which surrounded this sympathetic magic came to be known as a cargo cult.

What’s Cargo-Cult Agile?

As the Wikipedia author says, the islanders mistook a necessary condition for the planes arriving as being a sufficient condition for the planes arriving.

Teams and individuals sometimes make this same mistake with Agile. They believe that by following the practices of XP, Scrum or some other methodology, they’ll be successful in creating a culture which allows them to succeed.

Unfortunately, the islanders hadn’t realised that the soldiers created the airstrips because there were planes that wanted to land. The planes caused the airstrips – not the other way round! Without the planes, there would have been no desire for control towers or signal fires, for radios or waving arms, or for headphones, coconut or otherwise. And although these artifacts made it easier for the planes to land, the soldiers could have experienced some success with just a bare strip of earth and a little caution.

Agile values

In World War II, the leaders who wanted to win the war realised that planes were necessary. The air-strips helped them to use the planes effectively.

In Agile, the Agile practices that we know have emerged from teams that wanted to deliver valuable, working software, and who had discovered certain personal values that were effective in delivery. The practices they used allowed them to leverage those personal values effectively, but really, a bare strip of dirt – or any kind of process that reminded them what they were trying to achieve – would have enabled them to experience some kind of success.

I’ve found lots of different names for the values that allow teams to be successful – collaboration, trust, responsibility, innovation, camaraderie, rapport, honesty, transparency, helpfulness, forthrightness, motivation, responsiveness, agility, idealism, pragmatism, curiosity… the list goes on. They’re all wonderful ways of expressing those personal values, and I’ve seen or heard of teams succeeding with these values, regardless of which methodology they use. Partly this is because the values they’ve adopted allow them to try things out, to feel safe in questioning the processes they follow, to recognise better ways, and to be pragmatic in balancing the adoption of new ways of doing things with the responsibility for delivery.

I’ve also found that the following five values encompass pretty much everything that I’ve written in the list above, either alone or in combination:

• respect – the belief that other people are valuable, able to teach you something and amaze you, able to succeed given experience and support, interested in others’ well-being and success, and motivated by the desire to make the world a better place; and that any behaviour to the contrary is caused by external pressures or ordinary, forgivable human frailty
• courage – willingness to try new things which might not work, to accept personal risk for professional gain, to make oneself vulnerable in order to learn, and to lead others to do the same
• communication – the art of making oneself clearly understood, understanding others and feeding back any lack of understanding so that it can be corrected, listening and imagining, being aware of the impact of communications (verbal and otherwise), and finding other ways to communicate when required.
• simplicity – the ability and desire to reduce complexity, mitigate or isolate it where it’s inevitable, and avoid introducing it; to start, where it’s possible to start, without worrying about how or where it will end.
• feedback – knowing that our perception of our world and the ways in which we model it may be inaccurate, actively seeking out those inaccuracies (which may require courage!), trusting any existing mechanisms which can inform us of those inaccuracies, and listening to them when they do.

These are the five values of Extreme Programming, as outlined by Kent Beck (the poor definitions are my own).

As a coach, I’ve run competitive workshops in which these values formed the basis of the point-scoring. I’ve seen companies, especially Screwfix, adopt Agile using these values as a backbone, and seen them successfully release projects with previously unimagined scope and resource constraints. I’ve seen Scrum adoptions that were failing take on these values and begin working out the kinks, and XP adoptions that were rigidly bound by their processes, but whose employees lived by these values, become more fluid and successful as they aligned themselves accordingly.

I’ve also seen methodologies adopted without these values, leading to rebellion and the quick return to known, established practices that don’t leverage them. I’ve seen mailing lists on Agile topics become cliques – at least, I don’t feel I can post in them because of the lack of respect shown by some participants to others. And Kent Beck himself had to add that value – Respect – because it turned out not to be as obvious as he would have liked.

Measuring values

I’ve used the Dreyfus Model of Skills Aquisition frequently to measure how well the adoption of particular practices is progressing. I’ve found it useful to map the levels to these values as well, where:

1. Novice: still shows anti-patterns, behaviours which are not aligned with the values
2. Beginner: behaves like a normal human being, and would be pleasant to work with
3. Practitioner / Competent: is a model for these values, has few “off-days” and is forgiving of others on theirs
4. Knowledgeable: maintains these values intuitively, not only as part of their work-life, and can lead others in adopting them; has become a better person as a result of adopting these values
5. Expert: maintains these values in the face of adversity and in environments where these values create vulnerability; can articulate the benefits of holding these values both personally and professionally; can teach others and provide constructive feedback to help them adopt the values and leverage them more effectively.

That “Practitioner / Competent” level, 3, is in my experience the average that a team needs to achieve in each of these values in order to successfully adopt any Agile or Lean methodology. They also appear to lead to more enriched, fulfilling lives at work.

Landing planes

The great thing about these values is that it’s hard to introduce perverse incentives when using them as a metric. One participant in a workshop asked, “What if we just pretend?” Well, you can’t pretend to communicate better without actually communicating better. You can’t pretend to make things simpler without reducing complexity. You can say that you don’t believe in these values, or that you don’t think they’re helpful – but in my experience, teams who’ve tried them have discovered that they’re so much more fun than not maintaining them, they haven’t looked back. Even pretending to value these values leads to good habits, and the reaction of co-workers has often been positive enough to cause them to be subconsciously ingrained.

So, give it a try, and if you’re thinking of adopting Agile or Lean, land those planes first. The practices will follow, and make a lot more sense.

Indeed, reading the response, it seems almost inconceivable that anyone could possibly be offended by his presentation. Matt warned people beforehand that there would be potentially offensive images, I believe in his stated intentions, and I heed his call that we should be contributing something useful to the discussion.

So, I’d like to give you, the reader, a little bit of insight into the human brain, how it makes connections and comparisons, and help you to understand your power over other people and their perceptions.

I’d like to start by telling you another story.

The Tale of the T-Shirt

On one dress-down Friday, a colleague came in wearing a beach T-shirt, featuring a topless woman coming out of the surf. It was just a black and white image, and the focus was on the scene as a whole, but nonetheless some of us felt that it was inappropriate. So I asked him not to wear it again.

“Why?” our colleague said. “I didn’t think it would offend anyone.”

“It’s not really that it’s offensive,” I said, “but think about this. I’m pair-programming with you, sitting next to you at a table. Someone else comes along to talk to both of us. They see your T-shirt, with that image, and then they scan across from that image to me. Can you see the comparison they’re making in their mind? Even subconsciously? That’s why I would prefer you not to wear that T-shirt – so that people don’t think about topless women while they’re talking to me, and while I’m trying to work. At worst, the comparison is offensive. At best, the t-shirt is distracting.”

Our colleague took the feedback very well, and agreed not to wear the t-shirt again.

How the brain makes associations

The human brain consists of a bunch of neurons, between which connections and pathways are built. Those pathways form associations. There are associations of which we’re conscious, associations of which we’re not conscious, and a blurred space in between.

Here’s a conscious association. If I want to remind myself to pick up my dry-cleaning after work, I can hide my handbag. Sound strange? Well, as soon as I go to pick up my handbag, and it’s not where I left it, I’ll remember why I hid it. I’ve built myself a conscious association between the absence of the handbag, and the task I had to remember.

For a subconscious association, watch yourself thinking of all the things you remember about Germany, when I say the word “Germany”, or “Elephant”. The vast majority of our associations are not in, and often not available to, our conscious mind. They add to our personality, drive the learning we get from our experiences, and there are simply too many of them for us to be aware of them all.

For an example of the blurred space between, I offer my fiancé’s habit of driving directly home from the station, even though we agreed we’d stop at the Chinese takeaway on the way home. He associates the act of driving down a particular road with a particular route, and consciously manipulates the car to follow his subconscious association.

So what does this have to do with pr0n stars?

Human beings learn associations by – amongst other things – proximity; either in time, or in place. That is; they will build associations more easily if two or more things are experienced close together.

If you’ve watched Matt’s slideshow, and you find yourself using CouchDB on a project in the future, will you be thinking of his slideshow? It was very memorable. I think I will find it hard in the future to disassociate that slideshow from the featured product. That’s a conscious association I’ve built. I’m aware of it.

There’s a subconscious association going on in that show, too; another proximity which is harder to spot. We’ve just experienced words of technology – key phrases like scalability, REST, public interfaces – with images of women whom we’re told are available for visual sexual gratification. There are a few men in some of the images; they appear to me to be in positions of power and influence. The images of women, on the other hand, tend to be submissive. So we’re learning, subconsciously, that women associated with technology are also associated with sexual gratification and submissiveness. (The only strong women in the slideshow are associated with conflict, which we try to avoid.)

If you doubt this is true, look through the presentation (and bear in mind that it might be considered Not Safe For Work). At some point, Matt introduces a picture of a typical development team. To which team member are your eyes drawn, and why?

At the very least, we start making comparisons. No wonder she doesn’t look happy.

The power of people with influence

Earlier this year, I finished reading Robert Cialdini’s “Influence”. It’s a very readable, memorable book. It explains some of the ways in which associations are made. In particular, he describes these mechanisms for influencing other people (his titles, my poor definitions):
 

• Social proof – if other people do it, we should do it too
• Authority – if someone in a leadership position tells us to do it, we should do it

Examples which Cialdini uses to demonstrate these concepts include the mass suicide at Jonestown, and the Milgram experiment.

So, if a community is building associations, or you’re recognised as or portraying yourself as an authority telling people to build associations, those associations will be stronger than normal. People will be more likely to act on those associations. In the same way that my fiancé takes the turning for home, “routes” will be set which the brain naturally follows, and acts upon. And it will seem perfectly reasonable, or justifiable, to do so – at the time.

So what can you do now?

If you were sitting in Matt’s presentation, or have experienced similar presentations or associations in the past:

• you might consciously choose to wear a topless women on your t-shirt, because your brain subconsciously confirms that it’s acceptable.
• You might expect women to be more submissive; to accept delegated tasks more easily, or question process less, or accept lower pay.
• You might find it uncomfortable to have a female manager or team lead.
• You might cause the women around you start dressing in less feminine ways, to distance themselves from any association.
• You might erroneously think you have a chance of scoring with your female colleague (notwithstanding cases of genuine mutual attraction).
• You might not expect the woman on your team to be able to teach you anything new.

And, if you’re Matt, or one of the many commenters whose opinions I’ve read, you might not completely understand the backlash. Hopefully this post helps.

If you’re not suffering these or similar biases, trust my experience that others are, or have done, and start thinking about how you might have been influenced. The associations aren’t helpful for me, and I doubt they’re helpful for the people who have them. Recognising the influence of others will help you to consciously choose different paths.

Hopefully if you’ve found the presentation through this blog, you’ve now read through this post and are now better guarded against these associations. (That’s why I didn’t put the link at the top).

You can also strengthen more useful associations. Go find the women in your team and talk to them about their technical abilities; the things that brought them to IT; times when they’ve felt empowered and assertive. Find strong female role-models – I recommend Esther Derby, Desi McAdam, Sarah Taraporewalla, Johanna Rothman, Cyndi Mitchell, Rachel Davies, Angela Martin, and many others too numerous to list here. If you’re looking for something more entertaining to get into your subconscious, try Ellen Ripley, Buffy Summers, Alan Moore’s “Promethea” or Manda Scott’s “Boudica” series.

And, if you’re thinking of presenting something similar in the future, be aware of the power that you have.

On engendering subconscious reactions

Matt entitled his response, “On Engendering Strong Reactions“. I’m worried about the subconscious reactions; about the effect that it has on the people who see that presentation and the way in which they react to me, and to my other female colleagues, afterwards. Matt said, “I would have hoped that people who were likely to be offended would have simply chosen not to attend my talk or read my slides on the internet”.  That doesn’t stop the associations being built, and I can’t necessarily avoid working with people who have built those associations.

So I’m not offended by the presentation – I can understand why some women might be – but I am concerned by it. Hopefully this provides some positive insight into why. Matt – I hope you find it useful and enlightening; please let me know.