Liz Keogh's blog

Every now and then, someone comes up with a new way of looking at the world that becomes the next fashionable thing to do. Every time I’ve seen this, there’s usually a space of time in which a lot of people say, “Meh, it’s irrelevant”, or “Meh, consultants”, or “Meh, they’re only in it for the money.” After a while, things settle down and everyone is used to that new model or concept, and it’s no longer seen as edgy or strange. I’ve seen it with Agile, and Lean Software Development, and BDD, and now it’s the turn of Cynefin and Complexity Thinking.

I’d like to shortcut some of that with Cynefin, because I think it’s kind of cool, I’ve found it useful, and it’s not actually that hard to get your head around once you make the small mindshift. I’m going to share a bit about what I know of it, then talk about how it might actually be a useful concept for a dev to have in their head.

Some of us went to the Calm Alpha meet up, created a list afterwards, and have been using it to discuss which kinds of software can be categorised by which domains. I think our need to categorise everything is part of the problem, but I haven’t worked out how to solve it yet. In this post, I’ll be categorising things according the Cynefin definition of the terms, so resist the urge to say, “No! What I’m doing is simple!” or “But it’s complicated!” because Dave Snowden, who created the Cynefin model, uses those terms in a slightly different way to our common usage.

So here’s Dave’s Cynefin model.

Dave Snowden, released under CC BY 3.0 – thank you!

The Cynefin model consists of four domains – simple, complicated, complex and chaotic – with disorder in the middle. The edges of the domains aren’t strict – they’re domains, not quadrants. There’s also a little fold beneath the “simple” to “chaotic” boundary, to show how easily simplicity can tip into chaos. If you’re going to use this for a lot of items, it might be worth using the domains as attractors, rather than categories. Put the items down on a table, then work out where the lines go afterwards. If you can get your head round that, you’re already on your way to understanding complexity thinking.

Here’s how I tell what kind of programming I’m doing.

Simple

Everyone can work out how to do this. Like, everyone. The example the CE guys used was a bicycle chain falling off. It’s easy to work out how to get it back on again. If you’re programming, I imagine stuff like the turtle at the science museum, or Lego Mindstorms with its graphical drag-and-drop interface, might fall into this space. Children and non-programmers can do it.

In a simple environment, you sense, categorize and respond. You say, “Oh, it’s one of those problems.” No analysis is required.

Complicated

Complicated stuff is predictable, but requires expertise to understand. A watch is complicated. If you’re programming, complicated stuff will be well-understood, done before, not going to change as you develop it. Writing yet another CRUD form probably falls into this space.

In a complicated environment, you sense, analyze and respond. You say, “Let me have a look at this problem and I’ll tell you how to solve it, because I’m an expert at this.”

(I have a theory that most devs get really bored by doing the same predictable but complicated thing over and over again. We tend to turn it into open-source or automate it, reducing it to the far smaller but more complex problem of how to do the automation or use the open-source. Devs are drawn to complexity like moths to a bonfire. And we make it when we don’t have it…)

I reckon that if everything in software development was merely simple or complicated, Waterfall would work very well. You’d be able to set out to achieve some goal, work out how to do it, achieve the goal and say, “Job done.” Software doesn’t consist of only simple and complicated stuff, though. So let’s have a look at the other two domains.

Complex

My favourite way to understand complexity is that acting in the space causes the space to change, and cause and effect can only be understood in retrospect.

When you start writing tests, or having discussions, and the requirements begin changing underneath you because of what you discover as a result, that’s complex. You can look back at what you end up with and understand that it’s much better, but you can’t come up with it to start with, nor can you define what “better” will look like and try to reach it. It emerges as you work.

In a complex environment, you probe, sense and respond. You do something that can fail, safely, and it tells you things about the environment which you respond to, changing the environment . This is the land of high-feedback, risk and innovation: generally stuff you’ve never done before, anything that the business are unsure about, new technologies, etc. This is the domain in which Agile techniques really flourish. If you have a look at Cynefin’s pyramids, this is the one with very loose leadership and the people at the bottom all connected together, collaborating to solve a problem.

This is the most interesting domain for me. It’s the reason why we do things like BDD – using examples to discover more about what we’re doing – but it’s also the reason why, if we focus on trying to pin every small requirement down, we fail.

Chaotic

Chaos is your house catching fire. Chaos is accident and emergency. Chaos is that bug you released to production that brought your site down on the day of release, and you need to drop everything and fix it now.

In chaos, you act. You get out of the house. You stem the bleeding. You do something to get the situation under better control. When Egor Homakov hacked Github this week, Github responded by suspending his account immediately. They acted on the threat. After that they analyzed his actions, considered what he had done and reinstated his account. Act, sense, respond.

So why should I care as a dev?

I’ve found this model really useful for understanding why certain ways of approaching software work best in certain situations, and fail at other times.

The biggest failures I’ve seen have come from treating complex problems as if they’re complicated. For instance, a common Agile practice is to divide a problem into small chunks that we call “stories”, then start working on them. That’s actually a good way to work when most of the problem is complicated, but if you’re doing something new then you may want to go down the “probe, sense, respond” route instead. Hack something out, and get feedback on it. There’s no point guessing how you’re going to reach the goal, because as soon as you get feedback, there’s a good chance the goal itself will change.

Also, sensemaking is itself a complex thing. By trying to get feedback, you might find out how easy or hard it is just to get feedback. That could change the way in which you engage with the business. It might affect how much time you put into preparing for a planning meeting, whether you make a feature work fully or just fire off a screenshot, etc. As you seek to get that feedback the business will change the way in which they respond, too, so it might become easier or harder, and you need to be watching for those signs so you can help to change the process to match. As a dev, you’ll be the one feeling the frustration or ease from the process. It’s no good just relying on your coach or Scrum Master to help you, because he or she needs your insight too.

Knowing this model helps me know when to do TDD or automate BDD – defining a well-understood outcome, and working creatively with the software to reach it – and when to just use examples as ways of discovering more about what we’re trying to do. If I can clearly articulate the outcome and everyone agrees on it, then probably it’s good for TDD and BDD automation. Otherwise, having conversations is more important than automation, whether it’s with a pair-programmer at a class level or a business spokesperson or tester at a system level. Being able to tell the difference can help ensure that the conversations are the most interesting and effective conversations we can have. If I spot the conversations becoming boring, with people yawning or drifting off, then I know we’re trying to apply a complex method to a complicated or simple space and I can say, “Okay, I think we understand this well enough,” and work on something different instead.

(Also, knowing that the act of sensemaking is complex itself makes me look out for situations in which we’re misapplying methods.)

When chaos erupts, I know that letting my PM order us about for a bit is OK. Dropping everything we’re doing is also OK – forget the whole “developers need to be left alone to do their work” idea that the Scrum timebox normally provides. We fix the bug, hack the workaround, take the feature down, do whatever we need to do to get things under control. Chaos almost matches the “expedite” class of service in Kanban, except that I think you probably don’t even bother putting a card on the board until the need to expedite is over. After the emergency is over, we can look at whether it was just a one-off or whether there’s something we need to do to avoid happening again. For instance, being able to roll back a deployment cleanly and quickly gives us the ability to probe a release instead of crossing our fingers, moving something that might become chaotic into a complex space instead.

These are the kind of decisions that we make intuitively anyway, as developers, but human intuition is often flawed. We’re often uncomfortable with uncertainty, so we usually try to define outcomes regardless of whether they can be clearly defined or not. We’re definitely uncomfortable with chaos, and often make the mistake of treating a one-off chaotic incident as systemic, stamping controls over everything when what we really need is a way of probing, or trying things out safely. Having this model in my head has really helped me to become more comfortable with those situations, and to find approaches that fit them much better. Of course, this is massively useful when I’m coaching and acting as a change agent or helping a PM work out how to lead a team – but even as a dev, having this model makes a big difference to me and my day-to-day work.

I hope it will help you too.

When I started coaching Agile methodologies, I didn’t know how much I didn’t know.

I had come from Thoughtworks, a company whose tools and processes are mostly driven by Extreme Programming, aka XP. In that respect, most of what I learnt and coached was very similar to Scrum, albeit with different words. We called them iterations instead of sprints, and had stand-ups instead of daily scrums. We had planning meetings, but we didn’t make commitments – just estimates. We had collaborative code ownership and a focus on delivery instead of a cross-functional team, which meant that we ended up with flexible and blurred roles anyway. We had the same problems – getting people co-located, helping business stakeholders become more comfortable with the risk and uncertainty of software delivery, and changing the culture and the infrastructure of the organisations in which we worked. We also had a number of technical practices like unit testing and continuous delivery that aren’t really prescribed by either Scrum or Kanban, but which both put forward as a Really Good Idea.

In the last few years, I’ve been privileged to be part of the Kanban community. I don’t consider myself part of the Scrum community as such, but I’m part of the larger Agile movement and strongly aligned through my background in XP.

In this post, I’d like to cover some of the differences I’ve seen between Scrum and Kanban, and add in some insights from the Cognitive Edge training I’ve done using Cynefin and complexity thinking. This isn’t going to be a full description or comparison, but it should hopefully provide some food for thought, and allow people to see some of the different tools available from both approaches.

Disclaimer: I haven’t explained every term I’ve used, or every practice I’m referencing. I’m assuming familiarity. If you don’t have it, you can to run a search on anything I haven’t linked. I’m also using the terms “Scrum” and “Kanban” as aliases for the community and / or leadership, and I haven’t made much distinction between Scrum.org and the Scrum Alliance. This is deliberate, and I welcome feedback.

Scrum and Kanban have more similarities than differences.

Both methodologies put people and their interactions at the heart. Both have a clear focus on value, fast delivery and the continuing growth of the team and its ability to achieve those valuable deliveries. Both contain mechanisms for feedback and improvement, allowing processes to change according to context. Scrum used to have a very prescriptive format – not dissimilar to XP – but this has been flexed in recent editions of the Scrum Guide, as alternatives to some of the practices have emerged. It’s not even beyond the realms of possibility that some of the alternatives have emerged from the Kanban movement!

Also recently, Scrum has started to evolve from being a set of processes to being a very loose framework in which processes can themselves evolve. Used this way, it joins Kanban as a meta-process, from which the real process emerges and continues to emerge.

IMO, both are infinitely better than that broken model called Waterfall, and both are better than having no process at all.

Scrum isn’t about the Scrum Meetings, and Kanban isn’t about the Kanban Signal.

Both methodologies are named after just one small aspect of their whole. In Scrum, the scrum meetings allow the team to share learning and information about how they’re doing and to make decisions about what to work on next. In Kanban, the kanban signal – showing that someone is free to help move a piece of work closer to delivery – provides a similar focus point. Scrum teams frequently use a card wall that’s similar to that of a Kanban team. Kanban teams frequently have daily meetings like Scrum. To an outside observer, the differences could seem so small as to be irrelevant.

Kanban measures lead and cycle time, Scrum measures velocity.

Both Kanban and Scrum have their origins in “Lean” thinking. We like to think of “Lean” as the set of principles behind the Toyota Production System – the process by which Toyota builds and churns out its cars – but both methodologies have an implicit recognition that software development holds more similarities with product development than a production line. In Toyota, kanban cards are used to help eliminate large amounts of spare parts and other inventory building up; providing a buffer which lets work flow through the system. Both Scrum and Kanban value this flow. Kanban suggests limits on the amount of work in progress, allowing constraints to be addressed. Scrum encourages collaboration, causing less work in progress. Scrum uses the proxy of velocity and estimation, which can help to prevent metrics around productivity becoming targets. Kanban uses lead and cycle time, tying its measurements to valuable targets that are hard to game.

Scrum starts with the right context; Kanban improves the existing context.

I once asked a Scrum practitioner, “What do you do if you don’t have a cross-functional team and you’re not co-located?” He told me that that’s the hardest bit of Scrum – starting from the right context. I realised that these difficulties, once overcome, also provide significant value. Just starting from the right context might be a good idea!

On the other hand, Kanban is neutral regarding context. Of course we think that being co-located is a good idea. Of course we’d love to have multi-skilled, flexible, collaborative professionals. If only this was as common in the industry as we’d like. Kanban’s focus on metrics and its measurements of lead and cycle time might make the impact of not having these apparent, so it’s a good place to start. (I used to think it was only suitable for highly skilled, disciplined, advanced teams, but experience and experimentation has taught me otherwise).

Kanban visualises what’s happening; Scrum visualises an ideal.

This is one of the biggest differences for me. The extent to which Kanban visualises reality is extreme enough that the board might not even have linear flow. Whatever the process policies are – whether helpful or otherwise – Kanban focuses on making them explicit, so that they can be addressed and improved. If the team happen to work with five different phases, this is reflected. If the team write technical stories, they go on the board.

In contrast, Scrum teams tend to set up a visualisation of an ideal process, helping teams to adopt that process. Done prescriptively, Scrum provides a “big bang” starting point. Because it consists of step-by-step practices, it’s easier for beginners to adopt. That could be Scrum’s blessing – but it’s also its curse.

Certification and early adoption.

Scrum has certification. Kanban doesn’t.

Yet.

In the early days of Scrum, there were few enough trainers and experienced Agilists that no matter who taught Scrum, it was done pragmatically. Early adopters tend to experiment, and those experiments led to a better understanding; to a focus on people and interaction, rather than process. Unfortunately the “Scrum Master” certificates are easy to get, compared to any other discipline that asserts a quality of mastery or independence. The training provides simple practices that are relatively easy for teams to adopt. Scrum is taught by a wider group of people, and the quality control over that teaching has become harder to maintain.

As a result, Scrum has been widely adopted and is considered pretty mainstream – the default Agile methodology – but the certificates associated with it provide a level of confidence that the training generally doesn’t support. I’ve met a couple of excellent Scrum trainers, but I’ve also seen “masters”, armed with their certificates, instituting mini-waterfall and silo’d teams as they replace those parts of Scrum that aren’t prescriptive, or that they don’t understand, or that they can’t achieve within a context that they can’t change.

Any examination or certification body suffers from a paradox: while the people who rely on those qualifications need them to be rigorous, the people teaching and taking those qualifications would much rather they were easy. The Scrum Alliance and Scrum.org between them have both helped to set up and reinforce the desirability of their certifications, and I can only imagine the difficulty that their leaders face in balancing the financial incentives involved against the good of the IT community and industry.

In contrast, Kanban is still in an early adopter phase. We’re still working out, as a community, what’s possible. Most Kanban practitioners and coaches are bright, experienced, willing to experiment, desiring of feedback and able to share and learn from each other in a relatively small community. Scrum no longer has that luxury. We don’t know what will happen if and when the Kanban community treads the same path, but we do have the advantage of being able to learn from what’s happened with Scrum.

You can also bet that the leaders are being watched carefully by the rest of the community to see how they meet this challenge. So far I think they’re doing an excellent job. So far there are no certificates available. So far.

Some thoughts spurred by Cynefin.

The Cynefin model of complexity thinking teaches us that in a complex environment – one in which cause and effect can only be understood in retrospect, and which includes most systems with people in, as far as I can tell – we should increase the opportunities and incentives for interaction, so that the practices best suited to the context can emerge.

Waterfall treated software development as complicated, using Cynefin’s domain definition; as though each project was a thing that could be taken apart into many pieces, analyzed, then put back together as a whole. Unfortunately the ability of human beings to make mistakes, combined with our inability to either effectively communicate our intent or see into the future, has meant that this was always doomed to fail. (Most successful Waterfall teams, who complain to me that I label it unfairly, have not practiced it in a pure form, and have included elements of iteration, feedback and common sense. When these are lacking, any methodology is doomed to failure, but Waterfall above all others doesn’t mandate or even leave much room for them.)

When we look at applying Scrum prescriptively to a Waterfall team, we’re looking at pushing forward increasing levels of interaction in a context in which interaction is easy – where teams are co-located, have all relevant skills, are willing to collaborate and can share learning. Scrum’s acts of estimation and breaking stories into tasks force team members to talk to each other. The act of commitment which Scrum recommends in planning meetings causes a team to discuss their concerns frankly. The cycle of feedback and retrospection allows the team to discuss whether they’re delivering value and how to do it more effectively.

But Waterfall is no longer the context from which we always come. Many Agile adoptions aren’t taken up by teams doing Waterfall; they’re taken by teams who have abandoned their process altogether, and are talking and sharing their learning in order to work out what to do next, while having no metrics against which they can improve or track their progress and risk.

The context in which Scrum starts is not often possible. We’re not always co-located – many start-ups and companies now allow developers to work from home, and the industry still seems to suffer from a delusion that offshore work is cheap to obtain. We may not have multi-skilled people – it takes some time to learn skills. In both the environments which are already more collaborative than Scrum, and the ones which are a long way from being able to do it successfully, Kanban can be useful.

I fear that this may include the majority of environments and the IT industry, and that’s why I choose to hold myself closer to the Kanban community than the Scrum one. IMO, Kanban works in a larger set of contexts than Scrum does, even though for a subset Scrum might achieve results faster.

They’re still more similar than they are different… and I still like XP too.

Uncertainty’s the muse of all that’s new,
And ignorance the space in which she plays;
A year’s enough to prove a vision true,
But we could prove it false in only days.
We dream, and chase our dream, and never fear
To fail, and fail. Up, up! And on again,
But ask us to pursue another’s goals
And failure makes us mice where we were men.
Ah, best laid plans! Where were you at the end
Who chained us and constrained us from the start?
We knew you made a fickle, fragile friend;
You tricked us when you claimed you had a heart!
We thought less travelled roads would see us winning
In places other fools had feared to stray -
If only we had known from the beginning
The ignorance we found along the way.
And yet, a list of dangers and disasters
Filled out, and scanned, and added to some more
Would still have left out some of what we mastered -
We didn’t know we didn’t know before.

We planned our way with maps we’d made already
Assuming the terrain would be the same,
Expecting well-paved roads to keep us steady
And any local creatures to be tame.
We loaded up our caravans and wagons
With good advice, best practices and tools
But didn’t spot the legend – “Here be dragons!”
So we got burnt, again. They say that fools
Rush in, and yet we count ourselves as wise,
We praise each other’s skill and raise a glass
To intellect – ignoring the demise
Of expeditions just as skilled as ours.
When they return, worn out, their pride in shreds,
We laugh and say, “A death march! You expect
Such things to fail.” And in our clever heads
It’s obvious – at least in retrospect.
The dragons of our ignorance will slay us
If we don’t slay them first. We could be brave
And work for kings who don’t refuse to pay us
When we’re delayed because we found their cave.

They say that matter cannot be created,
A fundamental principle and law,
While dragons keep emerging, unabated;
As many as you slay, there’s still one more.
Our ignorance is limitless – be grateful,
Or else we’d find we’ve nothing left to learn;
To be surprised by dragons may be fateful,
But truth be told, it’s best laid plans that burn.
We could seek out the dragons in their dungeons
And tread there softly, ready to retreat;
We could seek other roads, postponing large ones,
And only fight the ones we might defeat.
The world could be a world of dragon slayers
And stand as men and women, not as mice;
The joy that comes from learning more should sway us;
The fiercest dragons won’t surprise us twice.
Discover tiny dragons, be they few,
And all the mightiest, with equal praise -
Uncertainty’s our muse of all that’s new,
And ignorance the space in which she plays.

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…