We have a strange desire for control.
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 few people here at the Lean Software & Systems Conference have asked me to write more about using the Dreyfus Model to game culture.
I’ve already written quite a bit about the Dreyfus Model – how to use it to create experts, grow teams, etc. – but this is more of an experience report.
I was working with a number of other coaches to transform a small IT organisation. We were asked to come up with some strategies for spreading the adopton happening in a couple of teams. When we presented our options, the head of IT went with one of the faster ones: giving us an afternoon every 2 weeks to play a game with the developers.
We assigned developers and testers to teams made up of people they hadn’t worked with before, one tester to two developers. Then we gave each team the requirements for the Game of Life – just the basics:
- Cells with less than two neighbours die
- Cells with more than three neighbours die
- Cells with exactly three neighbours are born in empty spaces.
We gave them 15 points for developing these rules, and also scored them according to the cultural values we saw, taken from Kent Beck’s XP books:
- Respect
- Communication
- Courage
- Simplicity
- Feedback
We were already using Dreyfus models with numeric values to help individuals move forward. We adapted these for the game:
- Novice: team exhibit antipatterns
- Experienced Beginner: team are human
- Practitioner: team are behaving like successful Agile team members
- Knowledgeable Practitioner: team behaviour influences others
- Expert: superhuman.
By the end of the game I don’t remember that we had any 2s left, let alone 1s, and one team were exhibiting 4s. Here’s what we did.
How we did the marking
The 5 coaches got together at the end of every session to share their notes – what we had seen, how the teams had behaved, what points we thought they should have. If we hadn’t seen anything particular, we gave them a 2 – ordinary human beings.
Whenever a team exhibited particular antipatterns (1) or particularly excellent behaviour (3-4), we gave them feedback as to why. We also only ever marked whole teams. If a particular member of the team was showing anti-patterns, it was the whole team’s responsibility to help them adopt a better culture.
We also held a clinic in which team members could ask for clarification, or advice about how to improve their score the next week.
An example of marking
On the first day, one team named themselves “Team Buttplug”. The coaches had spent a while putting the game together – coding a UI for the teams to use, setting up version control, etc. – and we felt that this wasn’t very respectful of our efforts. So we gave the team a 1.
The next week, the team renamed themselves “Team Redemption”, and scored a 3. We appreciated their turnaround!
The stories
After the first week, we added more stories, which made the software progressively more complex. The testers started having plenty to do!
The stories we added were:
- The grid can now switch from bounded (no cells outside it) to infinite (gliders run off the edge).
- The grid can switch from any other to wrapped (gliders return on the other side).
- The cells change colour depending on how old they are.
- The cells change size depending on how many neighbours they have.
- The rules can change from Conway’s rules to High Life (cells are also born when they have 6 neighbours).
- Users can step backwards.
- Users can scroll around infinite or wrapped grids using a joystick.
Gaming the culture
The teams quickly worked out that behaving according to the culture was an easier way to get points than developing the increasingly complex software.
“What will you do if we just pretend to be courageous?” one developer asked.
“How will you do that?”
“Well, we’ll just pick up things we’ve never done before. Or we could pretend to communicate; just get a whiteboard and talk about what we’re doing and draw on it.”
“Sure, we’ll give you the points if we can’t tell the difference…”
Of course, these cultural values are really hard to game without actually adopting them. Teams pretending to communicate better actually were communicating better. Teams exhibiting respect engendered respect around them. The culture of all the teams gradually improved. People started to be more forgiving; to provide feedback to us as well as to each other; to treat each other with respect and collaborate more and more effectively.
The end-game
On the last afternoon, two teams from the 8 we had were almost neck and neck. There was 1 point in it. One of them had developed more of the software – they had a particularly heroic developer who did much of the work.
The other team had started off poorly. They weren’t the best at development. However, they were using their tester very effectively, talking to us and clarifying the requirements, discussing their design on the whiteboard… and slowly overtaking the first team.
They won by 1 point. Thoroughly deserved.
All the teams who participated were amazing, but most of all I remember the head of IT who let us run the game in the first place. That commitment to learning really helped the teams understand the importance of what they were doing.
Swanky prizes helped, of course!
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…”
Pat Kua’s running a Dreyfus modelling session at Agile 2009 that you should attend if you’re there and remotely interested in how people learn.
Contrary to what it says in the printed program, I won’t be helping to run it. I would have loved to, and unfortunately managed to overcommit some time between the decision to add me to the program and asking if I was available. I think we’ll try that the other way round next time…
So, apologies if you were hoping to go to that session to hear me speak. Go anyway. Pat’s coach-coaching has made a significant difference to my skills, he’s a clear and imaginative speaker, and the outline looks like educational fun, as do the results of the last time he ran this.
I’ve just been reading Alan Skorkin’s and Mark Needham’s posts on the Dreyfus Model.
It’s curious to me that Alan says, “it does nothing to help us build experts from the more junior people on the team!” and Mark says “There seems to be potentially some conflict here with Marcus Buckingham’s idea of focusing on your strengths if our strengths aren’t aligned with the most important skills for software development.”
I’ve not grown experts – yet – but I believe I’ve managed to set people firmly on that path, and used the Dreyfus model to do it. Certainly, I’ve changed teams from novice and beginner up through to knowledgeable and competent, using the models as a roadmap. If it’s useful, I’d like to share some of the ways in which I apply the model which may be different to Alan and Mark’s techniques.
Junior people aren’t novices, and senior people aren’t competent.
Certainly not in everything, anyway. A junior person who’s joined a team as a software developer has probably got a great deal of knowledge about some facet of software development. Their best skill may not be in a technical practice! They may be fantastic facilitators, speed readers, domain experts, etc.
Equally, a senior developer requires different skills to a junior developer – and most of those extra skills aren’t technical. They need patience, the ability to pass on their knowledge, communication skills to find out about the big picture, time management skills, skills in giving feedback constructively (and receiving it!), and even a few skills which sit under my “coaching” models. A senior developer who’s technically brilliant may still be lousy at bringing that brilliance to a team. Mark pointed out, “It’s ok to be a novice at some things”. I’d go further, and say that this is the norm. One of my big weaknesses is estimation – I hate doing it, and am usually an outlier with no real reason – but at least I know, and can defer to my more skilled team-mates.
If we find the practices in which people are already competent we can add them to the model, giving them at least one point which allows them to say, “In this, I am successful.”
I’ve never coached anyone who didn’t turn out to be successful in at least one practice, so I haven’t needed to do this yet. People who aren’t successful in some respect tend not to get hired for that role.
Model with examples.
Think of the ways in which novices learn. Driving a car is a good example (of examples) for this. I am a novice; I use the gear, use the brake, use the steering wheel. I am taught the steps of moving off, parallel parking, emergency braking. I need more practice before I can even be a beginner.
As a beginner, I’ll be able to park without hitting the kerb, slow down gently at junctions, steer intuitively, drive at (legal) speed, etc. – but I won’t be able to do all of these, and only some of them will be intuitive.
As a competent driver, experts will agree that I am safe to drive independently.
As a knowledgeable driver, I will be able to have a new car. I will be less likely to have accidents. I will slow down near schools – not because I know I should, but because I instinctively recognise it as a dangerous area to be driving fast in. I will spot the idiot undertaking me on the motorway, and let him go past before pulling in. I will be at one with my car.
As an expert I will perform stunts, drive into the skid, evaluate different cars, judge others on their driving (impartially and accurately!), and do crazy things that most people don’t get to do, even if they are competent (and most people think they’re above average, even when they’ve forgotten most of the practices that allowed the expert to judge them as being successful – this is largely true of all skills, not just driving).
I can’t drive – I really am a novice. I can only model the skill of driving because I know a lot of drivers. See the stuff about GROW further down for how I’d go about coaching someone to learn to drive.
Play on people’s strengths.
There’s a reason you can’t grow a novice into an expert using the Dreyfus model. By the time we hit our professional environment, we’ve usually become at least competent in the practices in which we have the greatest interest – even if that’s nothing more than “I really like solving problems” or “I get computers”. I’ve just finished Malcolm Gladwell’s “Outliers” and found out about the 10,000 hour rule. I’m pretty sure I had 10,000 hours of problem solving under my belt by the time I graduated. Most developers are expert problem solvers (as long as the problems remain logical). Most of us are also competent programmers for small programs.
If you can find the skills in which people are already successful, you can use those to identify, and grow, related skills.
Someone who has taken up a practice but shown no real interest in progressing to the point of being independently successful is probably never going to be an expert. However, they may well become independently successful. Aim realistically.
After that, play on people’s strengths. I give numbers to the Dreyfus models, and let people sit halfway between them, so for me the most interesting numbers are 2.5 and 3.5 – beginning to experiencing some level of success, or successful and wanting more. These are the quick wins; the places in which people can grow swiftly from beginner to competent to knowledgeable practitioner.
I can tell .5s because they’re doing some of the things I see at the next level, but not all of them; usually in one context but not another. So, for instance, I met a manager today who’s great at motivating his people to deliver, but has never thought of motivating them to learn and improve themselves. I have no doubt that now he’s aware it’s important in a Lean environment, he’ll go ahead and make the right space and noise for them to do it, and get better at it over the next few months.
The numbers I love most to see are 4s – the knowledgeable practitioner. These are the people I use to spread expertise in the team. I know they’re not experts, but by the time they’ve spent a few years indulging in conversations and answering the questions for themselves as well as other people, they might well be.
Avoid the word “competent”.
You and I know what that word means, because we’re familiar with the Dreyfus model, and probably the model of conscious competence too. However, to someone who’s not into learning models, the word “competent” together with any insinuation of “you’re not” correlates with the words “incompetent” and “fired”. Making people scared tends to stop them from admitting to weaknesses and mistakes, which tends to stop them learning, and the word “competent” is scary.
I’ve replaced the word “competent” with “practitioner” in my models, and I tend to talk about being “independently successful”. That is, even as a novice or a beginner, you can be successful on a team where someone is around to catch your occasional mistakes or give you guidance to avoid them.
This helps coachees get away from worrying about addressing their weaknesses – which will develop with practice anyway, and with help from the rest of the team – and towards acknowledging their strengths.
Equally, concentrate on the people in the team who are ready to grow. They’ll help the others.
GROW them.
GROW stands for Goal, Reality, Options, Way Forward. I get the coachee to pick a couple of skills in which they want to improve (they’re rarely novice skills, which is fine by me). The conversations usually go something like this:
“So, you’re a 2.5 and you’d like to be a 3 – independently successful. Can you see yourself doing the things written here? Which ones do you think you might have problems with? Is it a matter of not knowing, or not understanding? Would you simply like to be more confident? Would you like to know which books cover this subject? Can you think of anyone else who’s better at this than you, who you could talk to and find out how they do it? Do you think it just needs more practice?”
We establish a goal, which means that the coachee visualises what it would be like if they were at the next level in that practice – how they might behave differently, or how they’ve seen other people behave that they’d like to emulate (look at NLP’s “well-formed outcomes” for really great ways of knowing whether you’ve achieved this). We then look at different options and resources for getting from the level they’re at, to the level at which they want to be. Then we agree to try something out, and revisit it a week or two later to see how it went.
Interestingly, the act of visualising the next level sometimes causes people to take on the different behaviour, which helps coachees to learn what happens when they try the new practices. If maintained for long enough it becomes a conscious habit; otherwise you’ll see that person revert under pressure. The behaviour of a manager under pressure tells me a lot about more about their ability to motivate people and provide realistic targets than their behaviour when things are going well! I also discuss with the coachees whether they’d revert or not; so far they’ve been honest enough to admit it if it’s true, and then we can find more appropriate options.
Look for years, not months.
Expertise does not happen overnight. There is no quick way to grow a novice into an expert (and you probably want to concentrate on a different, non-novice practice anyway). The 10,000 hour rule still applies – but we’re talking about experts, not practitioners. It’s perfectly OK for someone to be a well-rounded individual! On my own measurements of a Dreyfus Developer, the only skill I’m an expert in is BDD (and therefore its subset of TDD) – and only because I’ve spent just about every lunchtime, weekend and hour in the bar talking about it, practicing and teaching others for the last five years.
And I’m still learning about the practices which play into BDD, and how much fun you can have with it, and how it’s done in Ruby, and how it’s still evolving. Even expert skills can be broadened.
Applying the Dreyfus model is a skill.
Here are the “Applying Learning Models” models from my “Coaching Competencies”. They’re probably not accurate above the practitioner level, because I don’t really have access to any experts in this. I’m not an expert myself – just successful (and re-reading this post back to myself tells me I’ve learnt more since writing them; maybe I’m more than just successful now).
If you know better, please help me become an expert!
- Novice:
- Knows what a successful user of a skill looks like
- Encourages individuals to become practitioners
- Experienced Beginner:
- Can articulate the difference between someone following novice steps and a successful practitioner
- Has an awareness of the kind of practices which might lie beyond practitioner level
- Understands that it is not always necessary to address a weakness in a skill or practice
- Encourages individuals to identify and play on their strengths
- Practitioner:
- Can look at a practitioner in a skill and identify steps which are suitable for novices
- Can draw out past difficulties from practitioners and identify for novices who are gaining skill
- Can draw out current issues from practitioners and identify knowledgeable and expert practices which address those issues
- Can help individuals to measure their progress accurately by providing observed examples of their practices or antipatterns
- Targets the expertise of an audience appropriately
- Knowledgeable:
- Can examine an individual’s skill level and help him identify paths forward to the next level of skill
- Fluidly tailors presentations or workshops to the expertise of the audience
- In an audience of mixed expertise, calls out the level of expertise being addressed at any time
- Can articulate the dangers of targeting novice practices as indicators of performance
- Expert:
- In an audience of mixed expertise, provides a route map that celebrates the ongoing journeys of novices and beginners whilst providing practitioners and above with a route forward
- Can map different learning models to each other.
Grow expertise using experts.
I’ve never taken anyone from novice to expert, but I’ve certainly coached them from experienced beginners to knowledgeable practitioners, and from competent practitioners to expert. I’m particularly proud of Andy and Antony’s expertise in BDD, Szczepan’s creation of Mockito, and certain team-leaders and technical experts who’ve gained coaching skills.
The thing is, I didn’t do all the work – they did it themselves. All I did was make a couple of remarks, point them at some resources, and allow others to do the same. And they weren’t exactly novices to start with. So, if you want to grow expertise in a team – use other people too. Be a coach, not a trainer.
(Thanks to Andy and Antony for teaching me the power of collaboration, Szczepan for prompting me to rewrite JBehave, and the team-leaders and technical experts for passing on leadership and technical expertise…. amongst other things. I’ve come to realise that successful coaching is rarely a one-way transaction, and often just a straight swap.)
I’ve put up a page on lunivore.com which describes how I use the Dreyfus Model in coaching. This model was the one we adapted to mark the XP values in the Game of Life workshop at Screwfix, and I’ve also found it powerful when used in one-on-one coaching in combination with GROW and well-formed outcomes.
It’s taken me a fair bit of practice to get good at building Dreyfus models, using them appropriately and adapting them for different organisations; however, I’ve not encountered much downside to using them. If anything, the act of creating them has taught me a great deal (Dan North reckons there’s a Dreyfus Model for Dreyfus Modelling.)
lunivore.com has changed hugely since this post was written. For more about the Dreyfus model, see here.
What’s a Cargo Cult?
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:
- Novice: still shows anti-patterns, behaviours which are not aligned with the values
- Beginner: behaves like a normal human being, and would be pleasant to work with
- Practitioner / Competent: is a model for these values, has few “off-days” and is forgiving of others on theirs
- 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
- 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.
Spurred by Dave Anderson’s blog pointing at Tobias Meyer’s blog…
I once told this story to a group of people I was training as coaches.
The problem with Waterfall
Once upon a time some people noticed that their software projects were failing to deliver what the business needed. “We should be clearer about what we need,” someone said, “and check that those needs are interpreted correctly all the way down until we reach the code.”
And when things still went occasionally awry, they said, “You’re not doing it hard enough! Get more detailed requirements before you start work! Spend more time getting the design right! Don’t start coding until you’re sure!”
And when things still went awry, they said, “Do it even more!”
And that’s how we got Waterfall.
The problem with Scrum
Once upon a time some people noticed that their software projects were failing to deliver what the business needed. “We should assign someone to be the product owner, who can express what’s needed,” someone said. “We should have a stand up every day, a planning meeting at the beginning of each sprint and a retrospective at the end. And burndown charts.”
And when things still went occasionally awry, they said, “We should put someone into the teams who knows how to do this better, and who can make sure that everyone is following the rules properly. And we should give them certificates!”
And when things still went awry, they said, “Do it even more!”
And that’s how we got Scrum.
The problem with XP
Once upon a time some people noticed that their software projects were failing to deliver what the business needed. “We should assume that we’re wrong to start with,” someone said. “We should keep the cost of change low. We should do acceptance and unit testing, integrate continuously, maintain collaborative ownership of the code, and be courageous, respectful and communicative, keep things simple and get regular feedback about how wrong we are.”
And when things still went occasionally awry, they said, “We should automate more acceptance tests, and reduce build times, and automate deployment, and if anyone doesn’t like it we’ll make them pair program! Turn the dials up to 10!”
And when things still went awry, they said, “Do it even more!”
And that’s how we got XP.
Some good things about Scrum, XP and other Agile methodologies
According to the Dreyfus Model, novices – those learning practices for the first time – really value a step-by-step approach. They don’t necessarily know which steps are important. Patricia Benner, in her book “From Novice to Expert”, describes how novice nurses will follow every item on their checklist, for each item.
This is a great way to start learning. However, with experience and practice comes an intuitive knowledge of what’s important, what’s not, and what you can do to get a similar value from your practices. For instance, a competent nurse will spend her first ten minutes on the ward checking that nobody’s dying, before worrying about the bedpans.
Once we become experienced in a methodology, we start to put the focus on the things we find important, and find alternatives for things which are hard. I’ve worked on XP projects which had no automated acceptance tests, but great QAs. I’ve seen people refuse to pair-program, but happy to review each others’ code. Things do sometimes fall over in these projects – that’s just life! It isn’t necessarily because the practices aren’t being followed. Sometimes it’s part of a learning experience, and something to be celebrated, because it means people are trying things out and willing to be surprised.
The problem comes when we see things fall over, and try to prevent them by adhering rigidly to our steps, no matter what. They’re there for novices. They’re not intended to work for everyone all of the time, or even for most people, most of the time. They’re just a good starting point. As soon as we depart from those steps we’re in uncharted territory, and should expect to find things out. In my experience some of these findings are painful; most of them are delightful.
So, next time you find yourself arguing about what makes a good methodology, and which methodology is best, you could try asking, “Who for?” It might get rid of some of those arguments.
Why Lean is different, and the same
Lean’s a meta-methodology. It’s a methodology that you can apply to other methodologies after your step-by-step practices have become stifling. Techniques such as Value Stream Mapping, as well as principles like minimising waste and root cause analysis, can be applied to any project, no matter which methodology it started with.
I’ve done this, quite successfully and in combination with a bunch of other tools. I don’t have much experience with Lean, and was still quite surprised at how much I learnt just from reading some books and talking to some people who’ve worked in Lean manufacturing and Kanban software teams. I particularly liked the Poppendieck’s books. Scrum also has merits, and I understand the desire to keep the mailing list suitable for novices – maybe it’s time for another mailing list. XP is still the core methodology I prefer to start with – thanks Kent Beck. I also found sensible practices in common sense, patience and valuing other people’s opinions.
Lean is a step-by-step approach for me at the moment. I have no doubt that if I try to apply this blindly to every Agile coaching gig that comes my way, I’ll find the limits of Lean just as I’ve found the limits of Scrum and XP.
The problem with Waterfall, Scrum, XP and Lean?
Probably isn’t with Waterfall, Lean, Scrum or XP. Except for Waterfall.
It probably isn’t even with the people, either. We’re human, and we’re all at different levels and stages of learning. Different practices are appropriate for different people, in different situations. Why not try a few, and see which ones work best?
Then next time you hear someone evangelising some particular practice over another, you can smile, and nod, because you know where they are in their journey, and perhaps you even know where you are in yours.
Comments