Liz Keogh's blog

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.

Scrum: Hm, you’re rather small. Are you sure you want to do this?

Kanban: Bring it.

Scrum: Right. I represent a fundamental mindshift in the way that people do projects.

Kanban: So do I. My mindshift is different to yours; it feels subtler.

Scrum: I doubt that. I help teams collaborate and deliver working software iteratively.

Kanban: As do I. Unlike you, I don’t tie people down to fixed iterations; I let them find their own cadence.

Scrum: You say that like it’s a good thing! What if people aren’t even used to delivering iteratively? How can you possibly stop novices from taking weeks over their increments of code?

Kanban: Well, maybe I don’t work so well with novice teams. A high-discipline team, though, who can keep their flow consistent, will find themselves more responsive with me than they will with you.

Scrum: I help new teams get started. I give them easy, simple approaches that they can follow. You’re all about the maths.

Kanban: Actually, I’m all about the theory of constraints. By limiting work in progress, I make the bottlenecks obvious.

Scrum: I do that by focusing on getting the work through to production. What’s more, I was designed for software. You’re just the bastard offspring of manufacturing; you have no relevance!

Kanban: If I have no relevance, then why do so many people believe that I’m valuable, and fight to defend me?

Scrum: They’re in it for the money…

Kanban: Says the world’s fastest-growing pyramid scheme…

Scrum: I resent that! There are plenty of successful Scrum projects out there. We’re good people; we just want to change the world.

Kanban: I’ll settle for continuous improvement, thanks.

Scrum: We’ve got that too, except we call them Retrospectives.

Kanban: You don’t need to batch up your improvements if everyone is focused on it.

Scrum: There’s nothing to prevent us from continually improving.

Kanban: There’s nothing to prevent us from having retrospectives, if we need them, or in fact from taking on any of your valuable practices. I’m just like you, except that I have sensible limits.

Scrum: You’re not just like me. You don’t even worry about estimates half the time.

Kanban: We estimate in time to deliver, not story points. The business understand this.

Scrum: The business don’t trust my teams; they haven’t delivered successfully for a while. My planning enables them to regain that trust. You can’t even work without it.

Kanban: That’s true. Once we have the trust, though, we don’t need to waste as much time on planning and estimating as you do.

Scrum: How can you call a practice that establishes trust wasteful?

Kanban: You’re right. We value people too, you know – we work well with the Lean principles, and “Respect for People” is one of the pillars.

Scrum: Well, that’s good to know. People are the most important part of the process.

Kanban: We seem to have quite a lot in common. Thinking about it, you’d probably make quite a good stepping-stone for people learning to deliver software iteratively for the first time. I guess they could turn to me later, once the discipline is there.

Scrum: That might work. I know some people have used you in odd ways, and found value. Maybe we should just be friends?

Kanban: Let’s call it a draw.

XP: Let’s not. You may have the planning and estimation sewn up; you may be shifting your constraints and delivering responsively. Neither of you can survive without my technical practices. Get over here!

FATALITY!

Winner: XP

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 found a few places recently where the word “Test” has been used in combination with the words “Behaviour Driven” (with or without the “u”). Normally this makes me wince; the whole origin of BDD was intended to separate the act of describing behaviour through examples from the act of testing! Part of my self-appointed role in the BDD community is to be the anchor at the far end of that scale – you’ll hear me say “It’s not about testing!” a lot, especially if I’m answering a question about how to use JBehave to produce some particularly complex set of tests.

This post by Elizabeth Hendrickson describes her use of a BDD framework for genuine testing. Here, Elizabeth is acting in the role of a tester, and using RSpec imaginatively to support her work. Testing is a very different discipline to the act of describing what a system should do, or what a class should and should not be responsible for, and I think this example illustrates that point nicely.

If you find yourself struggling with BDD’s language, or wanting to know how to do something with BDD that only makes sense after the code’s already been written, separating the idea of testing from describing behaviour and responsibility may help you work out what it is you’re trying to achieve and express that to others. Testing is crucial to good software development; it may be that you’re doing something else.

Just talked to Olav Maasen who’s been running around all day, getting sound engineers and sponsors excited about Eric “Guitar” Davis and the Troublemakers.

Version One and Accelinova have proved themselves truly Agile companies by responding to change quickly enough to sponsor them, and Chris Matts is chipping in too. Thank you very much! This is going to make a wonderful banquet even more awesome.

The Agile 2009 conference has been an incredible experience. As with last year, I find myself overwhelmed by ideas and lacking in sleep.

The workshops have gone well – thanks for the kind and useful feedback! It was a pleasure to meet Pat Maddox and watch him work. Seeing what’s happening in the BDD space with JBehave and Cucumber is also rocking my world. The little bit of code I wrote back last year is now out there, being used successfully in enterprises across the world.

My favourite experience of the conference has been the Programming with the Stars. I’ve enjoyed judging it enormously, and the quality of the performances from the contestants has made me look at my own development habits in a different way. I’m not sure I could have pulled off the “one hand each, no mouse” kata that was sprung on them today!

I’ve actually got to see some of Chicago while I’m here, too! Some kind friends took me out to Chicago Blues last night. The band were awesome. So awesome, in fact, that there is now a movement afoot to get them playing at Agile – either tonight, or at Agile 2010 in Nashville. I’ll be watching this with interest; I’m curious to see if there are any obstacles, what they are, whether the Agile fans can make this happen.

(Just as I typed this, a friend came up and told me that it looks close for tonight! That’s astounding… given that some of the people involved in making it happen didn’t get to bed until 4am… Thanks to Chris, Bonnie et al for setting it up!)

Here’s the myspace site for the Troublemakers and their gravel-voiced, energetic singer, Eric “Guitar” Davis. I’ve got a lot of souvenirs from this conference; very happy that their CD is amongst them.

At Agile 2009, Pat Maddox of RSpec will be running a BDD Clinic with me. Between us we have experience with Java, .NET and Ruby code, and we’re willing to look at and learn from anything else. If you bring your work or ideas along, we will be able to give you feedback and maybe make some suggestions for writing more readable or maintainable scenarios, examples and code. I’m hoping that this will be a community event, since the room is quite large – if you fancy yourself as an expert and want other people’s opinions, come along! Feel free to drop in and out of the session at any time; it’s not a presentation or an ordered workshop, and we’re there to be disturbed (if we’re not disturbed enough already).

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

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

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

Andy, the release manager at my current client, asked, “How can I get the teams to follow a consistent process where readying the release for deployment is concerned? We have different version control systems, different build processes… how do I make them behave in the same way?”

Ask for consistent outputs, not consistent processes

In a waterfall-ish world, teams hand over the artifacts of their processes to other teams, who take them away and use them. Each team rarely has insight into what the other teams get up to with their artifacts. The team will produce the artifacts whether they’re needed or not, because they’re part of the process. Release management’s artifact has usually consisted of a document detailing the steps to check out, build and deploy an application, signed off by a gatekeeper who may or may not be familiar with the process itself.

In our lean world, the processes which the team goes through are defined by the team themselves; adapted and changed as the team continually improve. As part of that continual improvement the team may discover new and different ways to collaborate with their stakeholders, including the incidental stakeholders, who may not be paying for the project or using it, but who care nontheless.

Andy is one of these incidental stakeholders.

“If you’re a stakeholder,” I suggest, “you get to put your requirements to the team as well. Ask them for the thing you need. If you need consistency, tell them what consistency looks like. Get them to put the artifacts in a place where you can find them, together with a script that allows you to deploy. Your team are the ones with expertise in deployment, so they might usefully collaborate with the development teams to produce those scripts.” We talk a little about using the Feature Injection template for technical stories, continuous integration, and how the build might play into deployment. “Imagine if you could then just press a button and have those artifacts deploy themselves. How much would that benefit the QAs?”

“Right! And we’d get round the problem we have now, where we don’t deploy the services together with the applications until System Test, where of course they don’t work together.”

“They still won’t work together,” I reply. “All the mistakes in other processes also happen in Lean and Agile; the only difference is that we expect them. We don’t hope they won’t happen – instead, we know they will. We make it safe to fail, instead of fail-safe. This time, we’ll find out while the mistakes are still small, and after that every fix we need will also be small. We’ll also find the mistakes close to the place where they’re created, and the knowledge of how to fix them will be fresh.” We talk about Work In Progress as a liability, and move from there onto the similarities between Lean software development and Lean manufacturing.

Software development is not a production line

A large number of the metaphors of Lean manufacturing which we bring into software development have to do with the production line – that conveyor belt with the “stop the line” Jidoka handles on which the cars are built. Unfortunately, software development isn’t like building cars. If we find ourselves building the same software over and over again, perhaps configured slightly differently depending on the customer, then we’re not creating anything new and we should just use the same software we designed before, or buy something that someone else wrote.

Software development is about creating new things. It’s more like the product development shop; designing new cars, instead of building the same models over and over again. Ideally, it’s about trying out risky things – things which no one has done before. When we try new things, they sometimes don’t work.

“Yes,” Andy comments. “I’d love us to learn better from our mistakes.”

“They’re not really mistakes,” I hazard. “If we’re doing things that nobody has done before, then of course some of them won’t work. If someone is making mistakes it’s either because they’re human – and that isn’t going to change in a hurry – or because the system is set up in such a way that it was always going to happen. We can build safety in to catch the human mistakes. If we blame people for getting things wrong then they have a tendency to hide their mistakes. Instead, we want them to try things out. We want them to learn.”

“We should focus on the good side of making mistakes,” Andy muses.

“Even the act of making mistakes might be considered a good thing. We’re trying things out and learning from them; that’s innovation at work. If we change our language, people behave differently. We can focus on exploring ideas instead of avoiding risk.”

Integration and deployment is a production line

Once we’ve developed some software, we want to get it out into the world. This is where the metaphors of the Lean manufacturing production line come in – Jidoka, or the act of “stopping the line” to fix any problems with it; the button-click from a tester or release manager that signals the need for a fresh deployment, just like Kanban; delivery to the end-customer which provides the feedback to the team.

“Right now, we’ve started to introduce good practices into the team but we’re still not doing automated deployment,” I explain. “That’s like having a high-tech development shop designing the latest cars, then putting them together by hand, using techniques from 1900 – filing this screw here, hammering this panel to fit into place, every time a different set of problems to adapt to.”

“You’re right. I hadn’t thought of it like that,” Andy smiled. “This is going to make things a lot easier.”

Automation doesn’t make it easier

Automation introduces its own set of problems. In my opinion, these are much more interesting problems than, “How do we get our software to work in production?” Instead, we have, “How do we configure our webservers remotely? Do we want virtual servers? How big a sample of production data do we need for UAT? How can we get faster feedback from the build? Can we create a preview site?”

As well as freeing people up to answer these questions, automation allows the release team – rapidly becoming more of a community than a team, and sharing their expertise as they go – to collaborate with the developers, creating software that’s easier to build and deploy, or even coming up with new build tools. The ease of deployment may not increase, but the quality and consistency will.

There are plenty of different types of conveyor belt available – my favourite software conveyor belt right now is Hudson – and they can be configured to twist and turn the different artifacts in all the usual ways. Giving the developers a miniature version – maybe with a smaller data set, or enough to just build their engine or gearbox or whatever module they’re working on – can help to ensure that the software is buildable.

Expect, however, that if you’re doing tricky things with your software that require a unique approach to building it, you may have to spend time designing and building new production line tools.

That’s all right, because they’re just software too.

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.)