Liz Keogh's blog

I’ve wanted to write this post for a while, and reading “Metaphors we live by” has given me some language and ideas to express it in. So here goes.

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’ve got a problem.

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…”

Sometimes people ask me, “When we’ve gone Agile… when we are fully Lean… what will it look like?”

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.

Chris McMahon mentioned my example of a coaching kanban board in the second of his series of posts against Kanban. That it comes across as simple and infantile in Chris’s example is my fault; I only really touched on the “signal” aspect of the kanban board in this conversation, and didn’t go into more detail. So, in this post, I hope to correct that.

Picture a scene. You’re one of five coaches, hired to help transform the IT department of Screwfix. As part of this effort, you’ve set up a lovely story board on which you put the things you’re working on. This is the kind of thing that we had on our boards (all stories in this post are just examples, I can’t remember the exact concerns):

Each day, the coaching team met for a daily stand-up around this board. Our goal was to put our little avatars on the boards to show what we were working on, and move the stories (on post-its) to “done” when we had finished. After a couple of weeks, we realised – we weren’t actually using the board.

“The problem is,” Andy said, “half the things that we’re doing aren’t the kind of things we can move to ‘done’. They’re ongoing.”

“Right,” I agreed, “and half of them aren’t even on this board. There’s all kinds of things we’re doing with respect to the competition, coaching individuals, writing workshops, etc., and they’re not even up here. I wonder what we can do differently?”

At the time, I was hearing a lot of buzz around the word “Kanban”, and reading the Poppendieck’s “Lean Software Development”. It occurred to me that we might be able to use it to help us manage our coaching efforts.

So, I drew up a new board, and talked to our head coach, Chris, about it. “I’ve realised that I can cope with about three concerns at a time,” I said. “If you try to get me to worry about a fourth, I’ll promise to do it, and then something else will drop off the radar. It doesn’t matter how much I promise to do four things, realistically I’ll only get three done well at any time. So, I’m going to limit myself to 3.” I talked to the other coaches, and we found our own limits: 3 for each of the other coaches, and 1 for our part-time coach, Antony. So here’s what our new board looked like:

“Why, Helen!” I exclaimed, grinning. “You’ve got a space there.” I took a new post-it and wrote, “GIVE ME WORK!” on it, then stuck it in Helen’s space.

“What? No!” Helen exclaimed. “I can’t possibly take on any more work!”

“Well, either your limit is wrong – it’s OK to only manage two things – or there’s something you’re working on that’s not up there. Team C’s quite big; is that taking up about twice as much time as normal?”

“Not really,” Helen said thoughtfully. “There’s something else I’m working on. Let me think a moment… Ah! Of course, I’m also running the Agile induction course.” She wrote a post-it to replace mine.

“That’s great,” Chris said. “Now I can see what you’re working on, and also what you’re not working on.” We had a chat about some of the items in our backlog, and talked about when we might be able to bring them into play.

The board was much more effective, helping us juggle our workload appropriately, until it came close to the time for me to leave. Suddenly, I found I had more work than I could possibly manage.

So I cornered Chris. “You know how I said if I ended up doing four things, something would drop off the radar?” I asked.

“Yes…”

“Well, turns out it’s my lunch-hour. I’m exhausted; this isn’t sustainable. Can we sort something out?”

“Of course!” Chris said. So we got the coaches around the board to look at what we were all working on.

Chris looked at the various teams, competitions, workshops, technological strategies and other coaching concerns. “I don’t really care too much about these,” he said, removing about ten items from our (overly large) backlog. “And we don’t need to worry about Team B any more – I think they’ve got it. I’d really like you to run the other coaching workshops before you leave though, Liz.”

“Right,” I said, “then someone else needs to take over the TDD training.”

“I can’t,” Helen said, “I’m not technical. I’ve just finished the last Agile induction course, though, so I’ve got space to pick something else up. Andy’s been facilitating the retros; why don’t I take that instead, and then Andy could do the TDD training?”

“That works,” Andy replied. We swapped stories accordingly, moving them into their new places.

“Fantastic,” I smiled. “Anyone fancy some lunch?”

Having the visual aid helped us prioritise our efforts, as well as letting us share and organise our concerns. The most important aspect of this, for me, was the realistic recognition of our limits, which allowed Chris to direct our focus much more effectively. The Kanban board was just a tool for us, not a process or methodology in its own right. Nor did it replace conversation. It just facilitated it, and acted as a visual radiator. I found it useful, and I hope you enjoyed reading about it.

I’ve been wanting to try out Edward de Bono’s Six Thinking Hats for a while now, and finally got the opportunity in a workshop last week.

I was working with a team who had a vague understanding of the roles we ought to be playing, and we wanted to clarify them. We only had a short time for the meeting, so we used the hats to help us. In an unstructured meeting, everyone will have a particular bias. Some people are very positive and look for the good in everything. Others are risk-averse. Others like to concentrate on the facts, or see the big picture. By focusing on each aspect of these in turn, we were able to give voice to everyone’s preferred bias.

As the facilitator, I took the blue hat – the big picture – and used it to introduce the agenda for the meeting, outline our objectives, and summarise what we’d learnt at each stage. Each stage was simply a brainstorm with post-it notes, which we stuck on different areas of the wall around the room.

The team started with the yellow hat, looking at the positive aspects of the problem – what our proposed solution would achieve, and what resources and people we had available or hoped to use to solve the problem.

Then we used the black hat to work out what risks might jeopardise our solution. I used the concept of a futurespective here, too, as a number of the participants confessed to having a positive bias. “It’s three years from now, and we failed. Why? What happened?”

The white hat – focused on facts – helped us look at what we knew about the problem and the solution, and what was still puzzling.

At each stage we spotted themes. I now took the blue hat again and repeated these briefly for everyone present.

We used the green hat creatively to work out what our roles should be, given the yellow, black and white hats.

As a result, we realised that up until the workshop, we had been very focused on technical detail, and not as much on the people-oriented aspects of the problem. I kept the red hat with its emotional focus in reserve in case anyone seemed unhappy, but everyone was smiling when they left, and my team-mates declared the workshop a success!

I borrowed the programme for the hats from Wikipedia, which has a great summary. We ran the meeting across virtual conferencing in three countries, using big, coloured pictures of hats to remind everyone of the focus, and to provide a visual anchor and memory aid. Dan mind-mapped the results; this also works very well with the pre-defined themes.

Next time I think real (or paper) hats may be in order…