Traversing the Ocean of Knowledge

Pixie Driven Development

Wed, 01 Jul 2009 10:22:19 GMT

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.

Originally published at lizkeogh.com. Please leave any comments there.

Business Velocity

Tue, 16 Jun 2009 08:55:13 GMT

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"</a>? 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.

Originally published at lizkeogh.com. Please leave any comments there.

Doing the simplest thing and YAGNI

Tue, 02 Jun 2009 15:52:58 GMT

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.

Originally published at lizkeogh.com. Please leave any comments there.

Dreyfus Modelling

Tue, 02 Jun 2009 15:50:58 GMT

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

Originally published at lizkeogh.com. Please leave any comments there.

Pulling Power and Kanban experiences

Fri, 29 May 2009 10:07:19 GMT

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!

Originally published at lizkeogh.com. Please leave any comments there.

Feedback sandwiches and Real Options

Thu, 28 May 2009 10:53:43 GMT

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!

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.”</p>

“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?

Originally published at lizkeogh.com. Please leave any comments there.

ACG mind maps

Mon, 25 May 2009 12:23:26 GMT

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.

Originally published at lizkeogh.com. Please leave any comments there.

Ups and downs

Sun, 24 May 2009 08:02:11 GMT

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.

Originally published at lizkeogh.com. Please leave any comments there.

Cargo Cults and Agile Values

Fri, 22 May 2009 11:47:57 GMT

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.

Originally published at lizkeogh.com. Please leave any comments there.

I am not a Pr0n Star: avoiding unavoidable associations

Wed, 29 Apr 2009 10:44:57 GMT

I just read Matt Amionetti’s thoughtfully worded response to the reaction he’s got from his presentation, “CouchDB: Perform like a Pr0n star”.

Indeed, reading the response, it seems almost inconceivable that anyone could possibly be offended by his presentation. Matt warned people beforehand that there would be potentially offensive images, I believe in his stated intentions, and I heed his call that we should be contributing something useful to the discussion.

So, I’d like to give you, the reader, a little bit of insight into the human brain, how it makes connections and comparisons, and help you to understand your power over other people and their perceptions.

I’d like to start by telling you another story.

The Tale of the T-Shirt

On one dress-down Friday, a colleague came in wearing a beach T-shirt, featuring a topless woman coming out of the surf. It was just a black and white image, and the focus was on the scene as a whole, but nonetheless some of us felt that it was inappropriate. So I asked him not to wear it again.

“Why?” our colleague said. “I didn’t think it would offend anyone.”

“It’s not really that it’s offensive,” I said, “but think about this. I’m pair-programming with you, sitting next to you at a table. Someone else comes along to talk to both of us. They see your T-shirt, with that image, and then they scan across from that image to me. Can you see the comparison they’re making in their mind? Even subconsciously? That’s why I would prefer you not to wear that T-shirt - so that people don’t think about topless women while they’re talking to me, and while I’m trying to work. At worst, the comparison is offensive. At best, the t-shirt is distracting.”

Our colleague took the feedback very well, and agreed not to wear the t-shirt again.

How the brain makes associations

The human brain consists of a bunch of neurons, between which connections and pathways are built. Those pathways form associations. There are associations of which we’re conscious, associations of which we’re not conscious, and a blurred space in between.

Here’s a conscious association. If I want to remind myself to pick up my dry-cleaning after work, I can hide my handbag. Sound strange? Well, as soon as I go to pick up my handbag, and it’s not where I left it, I’ll remember why I hid it. I’ve built myself a conscious association between the absence of the handbag, and the task I had to remember.

For a subconscious association, watch yourself thinking of all the things you remember about Germany, when I say the word “Germany”, or “Elephant”. The vast majority of our associations are not in, and often not available to, our conscious mind. They add to our personality, drive the learning we get from our experiences, and there are simply too many of them for us to be aware of them all.

For an example of the blurred space between, I offer my fiancé’s habit of driving directly home from the station, even though we agreed we’d stop at the Chinese takeaway on the way home. He associates the act of driving down a particular road with a particular route, and consciously manipulates the car to follow his subconscious association.

So what does this have to do with pr0n stars?

Human beings learn associations by - amongst other things - proximity; either in time, or in place. That is; they will build associations more easily if two or more things are experienced close together.

If you’ve watched Matt’s slideshow, and you find yourself using CouchDB on a project in the future, will you be thinking of his slideshow? It was very memorable. I think I will find it hard in the future to disassociate that slideshow from the featured product. That’s a conscious association I’ve built. I’m aware of it.

There’s a subconscious association going on in that show, too; another proximity which is harder to spot. We’ve just experienced words of technology - key phrases like scalability, REST, public interfaces - with images of women whom we’re told are available for visual sexual gratification. There are a few men in some of the images; they appear to me to be in positions of power and influence. The images of women, on the other hand, tend to be submissive. So we’re learning, subconsciously, that women associated with technology are also associated with sexual gratification and submissiveness. (The only strong women in the slideshow are associated with conflict, which we try to avoid.)

If you doubt this is true, look through the presentation (and bear in mind that it might be considered Not Safe For Work). At some point, Matt introduces a picture of a typical development team. To which team member are your eyes drawn, and why?

At the very least, we start making comparisons. No wonder she doesn’t look happy.

The power of people with influence

Earlier this year, I finished reading Robert Cialdini’s “Influence”. It’s a very readable, memorable book. It explains some of the ways in which associations are made. In particular, he describes these mechanisms for influencing other people (his titles, my poor definitions):

Social proof - if other people do it, we should do it too
Authority - if someone in a leadership position tells us to do it, we should do it

Examples which Cialdini uses to demonstrate these concepts include the mass suicide at Jonestown, and the Milgram experiment.

So, if a community is building associations, or you’re recognised as or portraying yourself as an authority telling people to build associations, those associations will be stronger than normal. People will be more likely to act on those associations. In the same way that my fiancé takes the turning for home, “routes” will be set which the brain naturally follows, and acts upon. And it will seem perfectly reasonable, or justifiable, to do so - at the time.

So what can you do now?

If you were sitting in Matt’s presentation, or have experienced similar presentations or associations in the past:

you might consciously choose to wear a topless women on your t-shirt, because your brain subconsciously confirms that it’s acceptable.
You might expect women to be more submissive; to accept delegated tasks more easily, or question process less, or accept lower pay.
You might find it uncomfortable to have a female manager or team lead.
You might cause the women around you start dressing in less feminine ways, to distance themselves from any association.
You might erroneously think you have a chance of scoring with your female colleague (notwithstanding cases of genuine mutual attraction).
You might not expect the woman on your team to be able to teach you anything new.

And, if you’re Matt, or one of the many commenters whose opinions I’ve read, you might not completely understand the backlash. Hopefully this post helps.

If you’re not suffering these or similar biases, trust my experience that others are, or have done, and start thinking about how you might have been influenced. The associations aren’t helpful for me, and I doubt they’re helpful for the people who have them. Recognising the influence of others will help you to consciously choose different paths.

Hopefully if you’ve found the presentation through this blog, you’ve now read through this post and are now better guarded against these associations. (That’s why I didn’t put the link at the top).

You can also strengthen more useful associations. Go find the women in your team and talk to them about their technical abilities; the things that brought them to IT; times when they’ve felt empowered and assertive. Find strong female role-models - I recommend Esther Derby, Desi McAdam, Sarah Taraporewalla, Johanna Rothman, Cyndi Mitchell, Rachel Davies, Angela Martin, and many others too numerous to list here. If you’re looking for something more entertaining to get into your subconscious, try Ellen Ripley, Buffy Summers, Alan Moore’s “Promethea” or Manda Scott’s “Boudica” series.

And, if you’re thinking of presenting something similar in the future, be aware of the power that you have.

On engendering subconscious reactions

Matt entitled his response, “On Engendering Strong Reactions“. I’m worried about the subconscious reactions; about the effect that it has on the people who see that presentation and the way in which they react to me, and to my other female colleagues, afterwards. Matt said, “I would have hoped that people who were likely to be offended would have simply chosen not to attend my talk or read my slides on the internet”. That doesn’t stop the associations being built, and I can’t necessarily avoid working with people who have built those associations.

So I’m not offended by the presentation - I can understand why some women might be - but I am concerned by it. Hopefully this provides some positive insight into why. Matt - I hope you find it useful and enlightening; please let me know.

Originally published at lizkeogh.com. Please leave any comments there.

Why you should write tests last

Tue, 28 Apr 2009 10:27:28 GMT

Prompted by Szczepan’s post.

I have written tests after code when

the code is already there, but I / others don’t know what it does or how to use it, and we need to
I wrote a spike which turned out to be pretty good code, and I wanted to describe what it does and how to use it
I realised I needed to add some simple yet important behaviour while making a different test pass, and forgetting to add the code would possibly introduce serious bugs, so I added it as I went along and now I’m going back to show what it does and how to use it
I was learning how to write the tests first, and wanted to know what they would look like.

Originally published at lizkeogh.com. Please leave any comments there.

Goodbye, ThoughtWorks - Hello, Worlds

Fri, 17 Apr 2009 10:15:47 GMT

Today is my last day with ThoughtWorks.

It feels strange to be leaving a job I love with the most amazing company in the world, at a time when I should rightly be thankful for having a job in the first place. So, let me explain why I’m going.

Remember this post, back in November? I decided to actually do some work on the novel which has been hanging around my head for some years. Remember all the follow-up posts in which I told you how I was getting on?

No, neither do I.

The truth is that my day-to-day work - coaching, development, and learning about how brilliant, technical people think - has been taking up huge amounts of my life, time and creativity. I have no regrets about the energy I’ve put into it; watching teams and individuals learn and grow, knowing that I’ve been part of that, gives me pride and hope for the world. Learning how to help them better, and having them teach me, is fun and uplifting. It’s also incredibly draining on my creative energy. Looking back, I’ve hardly written any haiku in the last six months, and I’ve had no poetry published in two years. Nor have I made much progress with the novel.

So I’m going to leave ThoughtWorks and strike out part-time as an independent consultant. (I’m ideally looking for about three days a week leading or helping with Agile transformations, and will be flexible.)

The rest of my time will be going into ongoing training and development - giving my brain the space it needs to learn properly, to create the workshops and training courses which will be most effective - and, of course, writing my book. Maybe more than one of them.

So, from one world to others. I’ll be spending the next month or so in the diverse company of Grey the cat, Susan, Susan’s chair-dragon, Pigeon, Koley, Aquila, the Lunivore and the dryad of Islington Green.

They’re wonderful to be with, but I’ll still miss you.

Originally published at lizkeogh.com. Please leave any comments there.

Given / When / Then granularity

Thu, 16 Apr 2009 17:24:19 GMT

When we first wrote JBehave 1.0 we quickly recognised that there was power in the scenarios; in the conversations that they could help to drive, and in the reusability of the steps.

I loved the ease with which you could combine smaller steps to make bigger ones, use scenarios as the contexts of further scenarios, and take the necessarily procedural automated tests and turn them into sets of reusable objects.

Now BDD is more widely used, and people out there are using JBehave 2 and RSpec, and I hear complaints. Amongst them, this is one of the more common:

“Every time I change this screen, I have to go through fifteen files and add another step.”

Since JBehave uses plain text scenarios you can’t rely on the common refactoring tools, and that can make it a bit more painful than just messing with code. So, I thought I’d have a go at explaining how I avoid this issue; by sharing some of the ways in which I divide or combine contexts, events and outcomes into reusable components that help me avoid duplication in my scenarios.

Given a context

A context is a state which was set up by irrelevant forces, and which is used within the scenario to alter the outcome resulting from the events.

If the manner or time in which the context was set up matters, then that, too, is part of the context; unless it’s part of the behaviour you’re looking for, in which case it’s an event. The only reason for separating the contexts in which a scenario occurs from the events which are performed in the scenario is because it doesn’t matter how they were created. This means that Givens have more flexibility in implementation than Whens.

A context should matter. If you can remove the context from the scenario without changing the outcomes, it isn’t part of the Givens.

A context should be independent of other contexts. So, I prefer Given a wet newspaper to Given a newspaper / Given that the newspaper is wet. The first is less likely to require refactoring than the second.

A context should create an abandonable artifact. By this I mean that the forces which created the artifact - data in the database, files on the disk, a particular page at a given URL - can safely forget about the context they’ve created. Given an article about Iraq is a good context. Given I am logged in is not so good, even though we frequently use it as an example. Sorry. If it helps, it’s a step that rarely needs maintenance. Given we’ve filled in the comment box and are ready to submit it is likely to cause issues, because of all the other tiny steps that you have to use to get there.

When an event happens

An event exercises the feature whose behaviour you’re interested in when describing or running the scenario.

If you don’t care whether it works as long as it leaves things in a clean state, it’s a context. If you don’t actually need to do anything to cause an outcome - you’re simply checking that given some state, some other state is also present - you don’t need to write an event; just skip straight from Given to Then.

An event should create a valuable outcome.The granularity of the ideal event is very similar to that of the ideal context. As a user, I don’t want to go to the screen with the book, click the purchase button, navigate to the basket, enter the credit card number and click “submit”. I just want to buy a book. By specifying the steps which a user purchases a book inside the granularity of this larger step, we capture the value of that step. Since people rarely do things that they (or their sponsor, paymaster, loved one, etc.) don’t find valuable, this can usually be reused as one large step.

An event may be dependent on context or on another event. So, when I buy a book, and when I cancel my order within 15 days, then I should not be charged for the book.

An event should cause or contribute to an outcome. The outcome is something measurable. It could be that the outcome you’re looking for is an absence of something, for instance if a user’s preferences have been changed, and you no longer want to see all those Facebook groups. If it doesn’t cause an outcome, it’s a fairly irrelevant event.

Then an outcome occurs

An outcome describes the benefit that your system or application provides when the events are performed in the given context.

An outcome should have teeth. If a particular error message doesn’t have the exact wording expected, the world will not come to an end. If my credit card gets billed for the books but I don’t get them when I expect, it might.

An Outcome should be Specific, Measurable, Achievable, Relevant and Timeboxed. Ask a QA if you don’t know what this means. QAs are wise and can break anything.

An Outcome should represent the valuable purpose of the events. Instead of checking that a series of menus exist when you navigate to a particular screen, write a scenario that uses those menus and check that the benefits they provide are accessible through them.

Stories and regression tests

It can take quite a while to run scenarios. I sometimes like to turn mine into regression tests by combining them. I like to add contexts, events and outcomes to existing scenarios to better describe the benefits of using any particular feature in any particular context. This may mean that scenarios are related to more than one story. This will help keep them maintainable, and isn’t a bad thing.

I have never found the need to add a context to a scenario half-way through that scenario, even if it’s been created from several others.

I do frequently use one scenario as the context for other scenarios.

Unteaching the business

Sometimes, we accidentally train our business to talk to us about the solutions they’d like, occasionally in the language of software development. In that case, they’ll quite happily discuss the particular steps they need to take in the GUI to achieve the desired outcome, and may even have an idea of the underlying database tables and discuss what ought to be in those tables after the events.

If this happens, try to draw the conversation back to how the data will be used; why it’s valuable to produce that artifact in the first place. You never know; you may find you need to do less work than you thought you did.

Originally published at lizkeogh.com. Please leave any comments there.

What does “Not Agile” look like?

Tue, 14 Apr 2009 08:54:27 GMT

Last week, the XtC London group met up with the SPA2009 attendees. Joseph Perline ran a panel session with Tim Mackinnon, Rachel Davies and others in which they discussed the weakening of the Agile brand.

One of the most interesting comments was Tim’s assertion that Agile “fails the purchase test”. That is; if someone won’t buy the opposite of what you’re selling, then the brand of what you’re selling has no value. In Agile terms, if no team will claim to be “not Agile” then the word “Agile” itself no longer has any value.

How many teams nowadays will actively claim to still be running Waterfall, for any flavour of Waterfall? Of course not. We’re all “Agile”, aren’t we?

At an Agile 2008 keynote, Uncle Bob asked everyone who was on an Agile project to raise their hands, then put them down if they failed any of certain criteria: no unit tests, no acceptance tests, iterations of more than two weeks, no showcases to the business, etc. By the end, hardly anyone had their hands up.

So, given that those of us who are on Agile projects are often less than perfectly Agile, how do you decide whether you’re actually in that space, or are merely one of the teams weakening the brand?

Do you know what “not Agile” looks like? And are you sure it doesn’t look a bit like you?

Originally published at lizkeogh.com. Please leave any comments there.

Oops!

Wed, 18 Mar 2009 07:23:57 GMT

I was warned that there would come a point when the few spam posts I was getting would suddenly multiply to the point where I couldn’t keep up with them, but I didn’t listen. That point just came today.

I’ve deleted over 100 spam posts this morning, and installed a filter. If you made a comment that hasn’t appeared, or has mysteriously disappeared, I apologise - please feel free to repost. It should hopefully make it through the noise this time!

Originally published at lizkeogh.com. Please leave any comments there.

You’ve heard of BDD, DDD and TDD

Fri, 20 Feb 2009 13:09:55 GMT

Damien Guard introduces the other *DDs..

I particularly like “Psychic Driven Development” and “Golf Driven Design”. Thanks, Damien.

Originally published at lizkeogh.com. Please leave any comments there.

The pair chair

Fri, 06 Feb 2009 16:29:57 GMT

Finally, an approach to pairing which maximises colocation. It’s guaranteed to bring people closer to my thoughts. I can’t wait for the new batch to arrive.

Originally published at lizkeogh.com. Please leave any comments there.

Empowerment

Tue, 27 Jan 2009 13:08:48 GMT

Simon Baker has written a superb post, capturing the elusive nature of empowerment.

He mentions “an environment that tolerates mistakes to cultivate learning”. For me, this is an essential part of innovation; of the Lean metaphor that suggests a Software Development team is more like a Product Development team (designing new cars) than a Production Line (churning out the same thing repeatedly).

In a Production Line, we try to minimise variance (think Jidoka and Continuous Integration and Deployment).

In a Product Development team, we try to maximise learning opportunities, which means experimenting (think risk, innovation and doing things no one’s done before).

“There is no such thing as a failed experiment, only experiments with unexpected outcomes.”
— Richard Buckminster Fuller

Are mistakes in Software Development really mistakes? Or just experiments from which we learn something new? And if they keep happening… what didn’t we learn?

Originally published at lizkeogh.com. Please leave any comments there.

Six thinking hats

Thu, 22 Jan 2009 20:27:12 GMT

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

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

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

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

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

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

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

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

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

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

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

Originally published at lizkeogh.com. Please leave any comments there.

Who’s the best person to fix this?

Fri, 16 Jan 2009 16:53:31 GMT

I hate blame cultures. If you hate them too, then you don’t need me to tell you why. If you don’t, you probably haven’t worked in one yet.

At one client, they have a strong dislike for blame cultures. Unfortunately, most of the development team have worked in one at some point or another, and it’s hard to get out of certain habits.

“Ah, it’s all right,” one developer said, looking at a bug. “It’s not our fault.”

“I’ve been learning a bit of NLP,” I said, “and it suggests that the words we use can sometimes affect the way we think. I know that you’re not really thinking about blame when you use those words. Even so, can we avoid them? Could you maybe ask the question, Who’s the best person to fix this? instead of Whose fault is it?”

“All right. I’m still not the best person to fix this, though.”

“Well, who is?”

“I think George broke the build. I mean, George is the best person to fix it.” The developer called across, “George, can you look at the build a sec and see if you could fix it, please?”

“Oops!” said George. “I’m on it.”

So he fixed the build, and the team started working. A while later, one of the QAs called me over. “Liz, I’m looking at this bug… did your team cause it?”

I shook my head. “It looks like the database might be down.”

“Oh,” the QA said sadly. “I can’t blame you, then.”

I winced. “Why do you need to know whose fault it was?” I asked.

“So I know who to assign it to.”

So I explained about the new words we were trying to use instead of “blame” and “fault”.

“Oh!” she brightened up. “Well, are you able to help me fix it, then?”

“Maybe one of my team can help. Hold on!” So I asked around. “Who’s the best person to kick Mary’s database? It looks as if it’s fallen over.”

“I can do that!” Fred announced.

It occurred to me at that point that, if we were still asking, “Whose fault is this?” then Fred would be reluctant to help out, because it would insinuate that it was somehow his fault. By avoiding the words and asking, “Who’s the best person to fix this?” anyone can volunteer.

Suddenly, by providing an alternative to “fault” and “blame”, we’ve made it OK for people to volunteer to contribute. That can only be a good thing.

Originally published at lizkeogh.com. Please leave any comments there.

Standing-up dragging on?

Wed, 14 Jan 2009 14:02:38 GMT

There’s a standard format for stand-ups that goes:

What did you do yesterday?
What are you going to do today?

As well as this, it helps to keep the focus on things that are interesting to the team.

Sometimes this can lead to stand-ups becoming little more than status meetings, or updates for a team leader’s benefit. So here’s something that I’ve been doing both for myself, and with teams, that seems to liven things up a bit.

What did you learn yesterday?
What do you hope to learn today?

Participants who’ve used this as well as or instead of the usual format have talked about contacts they’ve made in other teams, difficulties they’re having with particular technologies, puzzles they’re trying to solve, domain knowledge they’ve picked up or are looking for, etc.

Originally published at lizkeogh.com. Please leave any comments there.

Love for Pigs and Chickens

Mon, 12 Jan 2009 13:32:58 GMT

A phrase frequently used in the Scrum teams I’ve been involved in - as well as a few of the XP teams - is “Pigs and Chickens”.

Googling the origin, I found out where it came from. Like many terms and practices in Agile Software Development, it’s surrounded by controversy.

I have come to love the phrase, mostly because it causes people who are unfamiliar with Agile and Scrum practices to ask, “What are pigs and chickens?”

When the Agile team members smile and happily explain the joke, the people asking the questions often remember that they have other questions they wanted to ask, too. Then they find out that most Agile teams are full of real human beings who love to talk about what they’re doing and share good practices. This in turn invites more conversation, which spreads the goodness.

That leads to requests like, “Liz, I’d love to see what the team are doing with <xyz>. Can I turn up at your meeting, please, just as a chicken?”

Anything which facilitates better communication - even by being an obscure hook that invites curiosity - has got to be good.

Originally published at lizkeogh.com. Please leave any comments there.

C# mocks in action

Thu, 11 Dec 2008 00:28:17 GMT

Mike and Gabriel both posted comments to show how the Cowhand example in my last post might look and evolve with different mocking frameworks. They’ve used FluentSpec and Rhino Mocks respectively.

Thanks, Mike and Gabriel! It was a pleasure to find these snippets waiting.

Also, Olof suggested that I include something a little less farm-related, so I’ve added another example with Mockito*, too. Thanks, Olof!

*Mockito’s syntax is now even better than this, but this is the syntax I’m used to.

Originally published at lizkeogh.com. Please leave any comments there.

The problem with Scrum

Tue, 02 Dec 2008 15:37:15 GMT

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.

Originally published at lizkeogh.com. Please leave any comments there.

Dan and I talk about BDD at Oopsla 2007

Mon, 01 Dec 2008 16:25:58 GMT

Back last year, Vlad Gitlevich kindly made a video of Dan and I talking about BDD.

We concentrated almost exclusively on the principles rather than the technology, which means the video is still very relevant. Particularly we talked about how BDD plays with DDD, outside-in, stories and scenarios and using them in conversation with the business, and our own experiences.

See it here!

Thanks, Vlad!

Originally published at lizkeogh.com. Please leave any comments there.