Tyburn 1.1 released

Tyburn, the little GUI harness for helping you Swing more easily, has had a few changes:

  • Slow mode now added, so you can use it to show your scenarios being run (great for BDD presentations or working out what’s actually causing that bug)
  • The Ascii Grid DSL converter which I’ve used for Tetris and the Game of Life for years has been added
  • You can now specify the timeout for finding an open window
  • You can ask the control if it’s got the window open (makes it easier to close all windows in a tear-down).
If you’re just using the WindowControl, nothing should break when you update (this includes all those of you who’ve participated in one of the many Game of Life workshops).
If you’ve done strange things like overridden classes or methods, something might not compile when you update – but the fix should be small and obvious.
Enjoy!
Posted in open source | Leave a comment

Pixie Driven Development

While I’m coding, I usually have a bunch of very helpful pixies hanging around my desk. (They’re Dan’s pixies really, since he thought of them first; I’m just borrowing them.)

The pixies are bored, and just waiting for a job to do. So, when I’m coding a class, they look out for opportunities to help out that class. When I’m coding the Game of Life, for instance, I write a Gui class that lets me toggle the cells on the grid. Then I have to work out what happens when I toggle the cells.

I could do it in the same class – in the gui – but fortunately the pixies step in to prevent me making these poor design decisions. “Oh, I’ll do that for you!” one of the pixies calls out. (They usually start with this phrase, and they’re all called Thistle.)

“Thanks, Thistle! Do you know what you’re doing?”

“Um, not really. What’s toggling a cell? Why’s that valuable? What is it you want me to do for you again?”

“I need you to handle the cell living and dying when I toggle it.”

“Oh, okay!” Thistle says. “I don’t like the ‘and’ word so much, though. It makes me feel like I’m doing two things at once. What do you call that? The living and dying thing?”

“Hm.” I think about it while the pixie taps his foot impatiently. “I’d call it a lifespan, maybe. Can you handle the cell lifespan for me? Just let me toggle the cells. I also need you to tell any observers that there have been some changes to the cells, and give them a way of finding out where those changes are. I think they’ve already got an idea of what they want there.”

“Really? Both things?”

“Well, there’s no point doing one if you don’t do the other. It’s all part of the same role.”

“If that’s what’s valuable to you then I’ll do it,” he says. “Just pretend I’m there for the moment; I’ll be back when you need me.”

“Fine,” I say. So I use a mock pixie in place of the real one. I create an interface which does what the pixie’s going to do: IHandleCellLifespans.

(See, it’s an interface that starts with “I”, and it represents a role that the pixie is playing for me. This is a role-based, anthropomorphized interface.)

So, now we have code which compiles. Of course, the real code in the Gui is null, or maybe a null object pattern – I might create something like IHandleCellLifespans.KILLING_THEM_ALL if I’m feeling particularly mean. But that’s all right, because Thistle the pixie will step in when it’s time.

So, I run the code. I’ve usually written an automated scenario. It doesn’t matter whether I run the scenario or step through the game manually; both result in the same thing happening, or not happening – no matter where I click the mouse, no cells appear. Pixies are notoriously unreliable.

Since I can’t rely on the pixies, I inject a new class to handle the dependency instead. I decide to call it the Engine, for the moment, and I write an example of how to use it and what it should do for me.

The next step is the Next button. I think about how this would work in the Engine, and start writing some code to show how the Engine needs to behave. I’ll need to calculate the number of neighbours, and apply the rules accordingly.

One of the pixies pipes up, “Oh, I’ll do the neighbours!” and another one says, “Oh, I’ll handle the rules!”

“Fantastic!” I’m so trusting; I always forget what these pixies are really like when it comes to getting the work done.

“If I’m going to count the neighbours,” Thistle says, “I’ll need some information about where I’m counting from, and what’s around me.”

“Ah, I can get the information from the cell itself,” I say.

“No, don’t do that. It’s fine where it is; I’ll just sit inside the cell and do it from there. Can you give me something that lets me know where the other cells around me are? Then I can do the work for you.”

“Sure,” I say, “the Engine knows where the life is. I’ll just give you access to the Engine and let it play that role for you.”

“Can’t I do it instead? I’m bored,” one of the other pixies asks. “Just give me the information from the engine, and let him talk to me instead.”

“Um, Okay.”

Of course, when I try to run it then I find out that all the pixies have mysteriously vanished, and I end up assigning the role to the Engine anyway, or one of its anonymous inner classes. Having it defined as a different role means that it’s easy to move this responsibility around. Maybe I’ll create a World to look after the cells, and let that do the job instead; the pixies certainly aren’t very helpful.

“What do you mean, we’re not very helpful?” Thistle says. “Look at your code. You haven’t written anything that isn’t needed by something else, so there’s less code to maintain. Because we jump in all the time to try and do jobs for you, every time you can assign a new responsibility to something else, you do – that’s the single responsibility principle in action; none of your classes are doing too much. And you can replace us with something else that does the job at any time – that’s the Liskov Substitution principle. The roles we perform are clearly named. It’s been easy to describe the behaviour of each class using mocks to stand in when we’re not there, and the examples are very readable. You can also use them to work out whether your code still works or not, by running them as tests.”

“Okay. I can’t see myself relying on you guys for bigger, enterprise stuff, though.”

“What do you mean?” Thistle looks offended. Oops.

“Well, let’s say that I’ve got a shop, and I need the tills to talk to stock control.”

“Controlling stock? Oh, I’ll do that!” one of the pixies announces excitedly.

“What, all on your own?”

“Well, I’ll probably delegate it to a team, but that’s my responsibility – you don’t need to worry about it. I’ll be there when you need me. Just pretend I’m there for now. How would you like to find me? What kind of stuff are you going to send to me, and what do I need to do with it? What would you like back?”

So I start with something simple – a URL that I’ll use to find Thistle the pixie, some domain objects that I want to send him, and some objects that I’d like back in return. We talk about how to get the information across, whether some of the tills might provide different stock information, how to talk to the claims department about the quality of the goods we’re selling, and whether I’ll be okay if the claims he gives me have more information than I need.

“Hold on,” I say. “You’ve got me playing this game now. I’m not a Claims Department. I’m not going to do the job myself. I’ve got a home to go to!”

“Meh, never mind,” Thistle replies. “I’ll be sitting with this team over here, coding the stock control. We’ll just pretend you’re doing the job; we’ll mock you out for now.”

“How will I know that I’m doing the job correctly?”

“We’ll have to talk to each other occasionally. Is that going to be hard? We’ll write some scenarios over in our team that describe how we’re going to use you.”

“What if I make a mistake?”

“Do you know what mistakes you’re going to make already?”

“No,” I confess. “I’m sure there will be some, though.”

“When you make a mistake, we’ll deal with it at that point. Sound good?”

I think about it. I reckon I could write some code that pretends to be doing the job of the Claims Department and responds correctly to the way they’ve described how they’re going to use me – just for those examples – then I could go home and Thistle would never know. I knock up a quick stub and slip it into the stock control team’s scenarios, then I disappear too, just like the pixies. I figure I’ll start coding a real Claims Department that does a more robust job tomorrow.

When I get back the next morning, all the pixies performing the role of Stock Control have been replaced with code too. The Stock Control team claim that they’ve never even seen them.

I corner Thistle again. “You’re really not very helpful, are you?”

Thistle looks sulky. “Of course we are! Look at your architecture. You’ve got simple messages going back and forth. Your code is very tolerant of extra information, as is the code on this side. You’ve got lovely RESTful URLs, because you were thinking about how you’d like to find us, instead of us providing you with some weird mechanism that doesn’t match exactly what you wanted. We’ve got clean interfaces and APIs. There are no extra columns in your database, because you only replaced exactly what we said we’d do in the first place. You’ve got scenarios to describe how we work together, and at a unit level examples to describe how you’re delegating responsibility to the other pixies. It’s a lovely, maintainable system with a fairly flat cost of change. Isn’t that what you wanted?”

I nod thoughtfully. “I think it would have been easier for me to just write the code instead of going through you all the time.”

“Ah,” says Thistle, “but then you’d have code that was easy to write, instead of code that’s easy to use.”

I think about how they made me fill in the role of the Claims Department. “You never did any of the work, though! I could have done that job myself; put myself in each of those roles and then replaced myself with real code. That would have let me create consumer-driven interfaces just as easily as using you.”

Thistle shrugs. “If that’s what works for you, sure.”

“Won’t people think I’m a bit mad? If I start talking about how I’m personally going to use a particular class, or how I’m offering to do a job for another?”

Thistle looks at me with raised eyebrows, then gestures at all the other pixies clustered around my desk.

“I think it’s a little late to be worrying about that now,” he says.

Posted in bdd | 12 Comments

Business Velocity

Pascal Van Cauwenberghe has written a great post on estimating business value, tying it into a feature-injection style template. I particularly like the idea of calculating business velocity, and showing value earned over cost on a visible chart.

Even though we know that cost accounting isn’t useful without looking at ROI, many companies still have this focus (how many people have had problems getting hold of sharpies because they’re "too expensive"? Coloured post-its? Free coffee?)

Perhaps by making the return on investment over time apparent to everyone, we can motivate the team, show the value we’re earning and gain the trust of the business at the same time.

As an aside, I remember one client where the deadline was very tight, but nobody wanted to work overtime or weekends. Our PM asked us if there was anything we’d like to have which would help us work more effectively. We asked for – and got – fresh fruit every day. The difference in our work – both the amount and quality – was noticeable! (We already felt very well respected, so I discount the placebo effect here).

It’s amazing how much difference a few pounds of expense can make.

Posted in business value, stories | Leave a comment

Doing the simplest thing and YAGNI

On an aside, some people have asked me why I’ve chosen to set up my services site as a hard-coded website with server-side includes, instead of using another WordPress blog or something similar. I did it because:

  • It was the quickest way I could think of to get a website out with a reasonable amount of content
  • I wanted to be able to get the style right (or at least usable) before I had to wrap it around WordPress
  • I had no idea what I was going to put in the website when I started.

Having said that, it’s now annoying me. There’s enough up there that the next stage is to, um, move it to a customised WordPress site (it should look exactly the same, but be easier for me to administer).

I did learn a lot about CSS, Mercurial over SSH from Windows, and Apache SSI configuration while I was playing with this. It will be much easier for me to set up the WordPress site, now I know what I don’t want on it and what I need for the styling to work. And I didn’t need a WordPress site when I started. YAGNI wins again.

Posted in breaking models | Leave a comment

Dreyfus Modelling

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.

Posted in learning models | 2 Comments

Pulling Power and Kanban experiences

My first ever article, “Pulling Power: a new Software Lifespan” is up on InfoQ. BDD, Feature Injection, Lean and Kanban playing nice together!

Big thanks to Dan North, Chris Matts, David Anderson, Amr Elssamadisy and the amalgam of developers who make up “Jerry”; also to the Thoughtworkers who reviewed my article and gave me advice, and the Kanbanjins like Eric Willeke who patiently talked me through Lean and Kanban. Several times. Anything I still haven’t understood is my error, not theirs.

I wish I could have put in everything I’ve learnt about Kanban, which is far larger than this article allows. It strikes me as a lovely, simple, high-discipline, least-wasteful way to deliver software, and it matches my feeling that you should fit your process to reality, not reality to your process.

My experiments with Kanban boards so far have been highly successful. Now I want to know about the problems, too. Have you tried Kanban? What happened? Did you try to introduce it? Did that work out? If not, why not? Did you think about introducing it, but decide not to? Tell me your stories!

Posted in bdd, jbehave, kanban, lean, stories, writing | Leave a comment

Feedback sandwiches and Real Options

Esther Derby writes great advice on giving feedback. I’m intrigued by her closing comment:

Praise sandwich tends to erode trust in the feedback givers intentions, and once that’s gone, there’s not much chance any useful information will get through.

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

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

“I learn a lot from pair-programming with you, but you sometimes take the keyboard from me when I’m trying to type. If you could please ask me before you do that, it would help me to learn and I’d feel less frustrated. I’d like to pair with you more often and I think it could be fun.”

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

I value this…

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

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

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

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

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

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

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

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

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

“I learn a lot when I’m pair-programming with you.”
“I love the solution you’ve come up with.”
“I really like the colour scheme and the icon.”

And…

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

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

See what I mean?

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

“I learn a lot when I’m pair-programming with you and I’d like to learn more.”
“I love the way you’ve solved this problem, and I’d like to build on that.”
“I love the colour scheme and the icon, and I think there may be some ways of making them stand out.”

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

“Thank you very much for letting us try out this Agile stuff! It’s great; I’m having fun. I really like the lightweight documentation, and I’d like to try and work out how to align that aspect of it with the reports you asked me for. Can you help me?”

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

…I want this.

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

“I learn a lot when I’m pair-programming with you and I’d like to learn more. Would it be OK if I typed sometimes? I think I learn faster when I’m actually doing the typing myself.”

“I love the colour scheme and the icon, and I think there may be some ways of making them stand out. Perhaps if we had something textured, or cut into a different shape, that would catch people’s attention.”

“I love the way you’ve solved this problem, and I’d like to build on that. Maybe we could assign responsibility for this bit of the code to another class. I think that would make this class simpler, and then we could write some tests to describe its behaviour so that other people could use it too.”

“Thank you very much for letting us try out this Agile stuff! It’s great; I’m having fun. I really like the lightweight documentation, and I’d like to try and work out how to align that aspect of it with the reports you asked me for. Can you help me? I’m looking for a way to try and use the data that’s up on the walls and the project board to make this easier.”

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

“I learn a lot when I’m pair-programming with you and I’d like to learn more. I’m finding it tricky because when I’m typing, you sometimes tell me what to type before I’ve had a chance to think through the problem myself. If I could have a bit more time to think things through I think I’d understand the domain more quickly, and if I’ve got it right then my code should make sense to you. Please let me know if it doesn’t.”

Even when it’s really unpalatable behaviour.

“I love that you have so much energy. It really comes out when I’m sitting next to you pair-programming, and you throw your arms in the air and wave them, and it makes me feel really energized too. Unfortunately when you do that, there’s an unpleasant smell… is there anything that can be done to change that? I really like some of the new Lynx fragrances, and my friend rates Right Guard; something like that would smell nice.”

Provide options

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

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

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

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

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

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

Why don’t you give it a try?

Posted in feedback, nlp | 4 Comments

ACG mind maps

I got a bit experimental with my mind maps at the Agile Coaches’ Gathering. I think it was a combination of the amazing and inspirational people, the fantastic choice of venue and the glorious weather that got me feeling so creative. Some people have asked me to put them up on the wiki, so here they are.

Posted in conference | Leave a comment

Ups and downs

This blog’s been up and down the last couple of days while we uploaded my new site, lunivore.com. It’s not finished yet – there are a couple of empty pages, the Game of Life implementation still has a couple of bugs, there’s still more material to go up and I’m not completely convinced that my CSS is the best. However, in the interests of Agility and getting it into production as soon as possible, it’s up there.

Lunivore Limited is the company through which I’m offering my services, and lunivore.com is the website which describes those services: software, coaching, training, writing.

Many thanks to Andy Palmer for his Apache expertise and struggling with cpanel’s weirdness! If either site goes down, it’s cpanel doing something strange that we haven’t pinned down yet; I’m home from the wonderful #acguk and will be on it.

Posted in life | Leave a comment

Cargo Cults and Agile Values

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:

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

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

Landing planes

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

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

Posted in breaking models, feedback, learning models, values | 1 Comment