Liz Keogh's blog

I’ve been invited to speak at the Lean Software and Systems Conference in Atlanta, April 21st to 23rd 2010.

---

BDD, often described as “TDD done well”, is strongly aligned with Lean
principles. It’s a pull-based approach to delivering software that
matters through the whole software lifecycle, from vision to code. It
minimises rework and over-delivery, bakes quality in, and is founded
on respect for people in their various roles and the language that we
use to collaborate and communicate. BDD has its origins in NLP and the
Sapir-Whorf hypothesis: the idea that the words we use affect the
cognitive model of our work. It decouples the learning associated with
TDD and Acceptance Testing from the word “test”, using the more
natural vocabulary of examples and behaviour to elicit requirements
and create a shared understanding of the domain.

In this talk Liz will introduce BDD, show how to model it using PDCA,
and talk about how its practices can provide quicker feedback and help
us to turn a vision into reality faster.

---

I’ve been working on this talk for a few months, and hope you enjoy it.

This has been a very special year for me. I’ve been fascinated by Lean principles for a while, but only recently had the opportunity to do some serious study into them and try out the related practices and tools. It’s also taken me some time to work out how strongly aligned Lean Thinking and BDD are. The community around the Lean and Kanban movement has been very welcoming and respectful this year, and I’d urge anyone who is interested to make their way over to the Limited WIP Society, where some excellent blogs, articles and examples of Kanban boards etc. have been collected for your accelerated learning.

We held a bag-stuffing event at Agile 2009, and used it as an exercise in applying Lean techniques. (Hugo Corbucci and Hamlet D’Arcy both posted excellent write-ups of this). One of my proudest moments this year was when some of the Limited WIP and Kanban community asked me to stand up afterwards as someone who could be approached with questions about Lean and Kanban. I’m an effective Agile coach, but my knowledge of Lean still felt new to me at that point. To have this kind of validation meant a lot to me.

I appreciate those of you who have helped me in this journey for your extraordinary patience in teaching me and providing feedback on my understanding. You know who you are.

You’ve got a problem.

You want to measure, and improve, something about your project or people. You’ve got a good idea about how to do this. Perhaps the metric you want to use is already widely measured. Perhaps it’s been in the industry for a while. It might be a KPI, related to a management incentive or perhaps you simply want to replace your existing metrics with something better.

Before you put that measurement in place, borrow my Evil Hat.

The Seventh Hat

Edward de Bono identified six different ways in which people prefer to think, and created the six famous thinking hats.

Unfortunately for humanity, there’s a seventh way in which we think. It comes unconsciously from our innate desire for an easy life, our craving for approval, and mechanisms of feedback which tell us whether we’re doing the right or the wrong thing. It comes more consciously from our desire to be paid more, keep or improve our jobs, and make our bosses happy. If we’re determined to be evil, we can think of it as a way of manipulating the system for our personal gain.

The problem is, even if we aren’t evil, we do start responding subconsciously to the feedback provided by our measurements and responses to them. Like an electrical current, we tend to take the path of least resistance. If we’re seeing problems as a result of the metrics, we’ll address the problems – and if we’re doing it subconsciously, we may not actually analyze the cause of those problems, or the effect of our changes outside of the system. We’ll respond to praise for achieving the targets, and to criticism for missing them – even if the targets and the praise are implicit.

By putting on the Evil Hat, we can move those subconscious reactions into the conscious realm. Pretend, for a moment, that you have no care whatsoever for the success of your project, your team or the bigger picture. You are merely interested in your own personal gain. You are not interested in making life better for anyone else but yourself. This is what your brain is already doing, before the altruism in your conscious mind or subconscious habit kicks in (and there are plenty of arguments to suggest that altruism itself is merely done for psychologically selfish reasons).

Congratulations. The Evil Hat has just turned you into a sociopath.

Sociopaths can destroy your company or project

When a sociopath wants something, they can resort to any means necessary to get it. This article, Sociopaths in High Places, illustrates some of the behaviour we can expect from sociopaths, including bullying, cruelty, manipulation and outright fraud.

This only happens because sociopaths don’t care about other people. Of course, most of us are born with empathy. We feel other people’s pain. Don’t we?

When we’re stressed, our adrenaline levels rise. We are primed for fight or flight. Our instincts are turned inwards, to our own survival. We are more likely to act in our own interests, and less likely to worry about those around us. This rather lovely article talks about the circular nature of stress and concentration, relating the feeling of compassion to the state of relaxation. The opposite is also true.

So, let’s imagine that we’ve been set some targets, and we’re not meeting them. Our boss (who has targets of his own) is putting the pressure on us. Now we’re starting to feel stressed, which makes us less empathic. Even if we’re not sociopaths ourselves, we’re capable of selfishness, and it’s starting to show.

Sociopaths are in charge

The targets in any company tend to filter down from the top. The shareholders want a profit. The CEOs, board members and upper management are in charge of delivering that profit. Their targets and metrics are clear. As Chris Matts has said when talking about Feature Injection, they need to “make money, save money or protect money”.

Two psychologists, Paul Babiak and Robert Hare, started applying a checklist for psychopaths to the boardroom members of corporations, and published some of their findings in a book, “Snakes in suits”. This transcript of a radio interview with the authors and other experts illustrates some of the behaviours they found.

It’s often easier for a psychopath to achieve their goals by destroying others. Certainly, they have no empathic reason to want to help others, and they will protect themselves and the power they amass quite jealously. There are some phrases that we can look for to see if we or our colleagues are becoming less empathic with stress:

“It’s not my fault.”

“X did it.”

This is us, protecting our power and our jobs at the expense of someone else. We’re not thinking about the impact on others when we say these things. We’re doing it to protect ourselves.

Of course, true sociopaths and psychopaths (Wikipedia defines the difference nicely) will protect themselves in advance, so rarely have to resort to passing the blame – it will already be obvious to all powerful onlookers that they are blameless. Or, worse, the powerful onlookers will themselves have sociopathic tendencies, and be in cahoots with their sociopathic comrades.

As the stress mounts, the more clever amongst us will start protecting ourselves. We keep those emails, do everything in writing, and insist that processes are followed, making sure that we cannot be blamed for anything more than being cogs in a giant machine. The more creative amongst us find ways of becoming more influential and indispensable – hoarding knowledge, hiding our lack of skill, making friends in high places, setting others up to take the fall. As the habits develop, we become more and more sociopathic ourselves. Anyone who finds themselves unable to dispense with morality leaves, and the company culture is now fully riddled with blame.

Sociopaths can save your company or project

As Robert Hare says in the radio interview:

Enlightened self-interest is not a bad idea for psychopaths, and try to indicate or convince them that there are ways in which they can get what they want and need without having to actually harm other people. “Enlightened self-interest is not a bad idea for psychopaths…” Now it’s easier said than done, because their behavioural patterns are fairly entrenched. But these are not stupid people, I mean the range of intelligence amongst psychopathic populations is the same as it is in the general population. These are people who know what’s going on.

So, what’s going on?

The word is spreading. Self-organising teams, in which the members are not merely cogs, are more performant. Employee empowerment and learning improves company morale, reduces expensive employee turnover and can help make money. Transparency in the workplace fosters productivity. Incremental delivery reduces risk, resulting in more successful projects and more fulfilled staff; even governments are listening.

It turns out that in most cases, doing the empathic thing – creating positive cultures and professional experiences for employees – is also the most profitable thing, helping those sociopathic CEOs. It’s the most productive thing, helping their cahooting managers. If it involves transparency, it’s hard for anyone else to manipulate, and because an enabled, positive, productive workforce creates options it reduces risk and provides the greatest possible control in the event of uncertainty.

The sociopaths of the world – CEOs, managers, and democratic governments – are also starting to listen. If you know yourself to be a sociopath or a psychopath, you’re in a position of power, and you’re not paying attention, then you’re losing this race.

If, however, you are already cynically manipulating your company culture to be better, faster, more productive, empowered, self-organising, transparent, learning, improving, Lean, Agile, incremental, feedback-driven, forward-thinking, creative, optimistic and prepared, then congratulations. You are about to rule your slice of the world. Just what you always wanted.

Put on the Evil Hat

By pretending to a certain amount of sociopathy before we start introducing metrics and targets, we can ask ourselves, “How will we respond to these targets?” Will we game the system, manipulating these in a way which serves our purposes, but not the whole? Are they perverse incentives in disguise? Will we see anti-patterns emerge as a result?

We can also use the Evil Hat to turn this around. What metrics and targets could we put in place that would lead to even more productive behaviours? That would lead to success, and therefore maximise our personal gain? How can we make sure that the things we’re measuring are the things we most want?

It’s Good to be Evil

I was in a meeting when someone suggested introducing a KPI for measuring team leaders. “One of their jobs is to remove obstacles from the path of the team,” a manager suggested. “We should measure how many obstacles they remove.”

“Excuse me a moment,” I grinned. “That sounds like fun. Just let me put on my Evil Hat, and I’ll tell you what I’m going to do in response…”

I just read Michael Dubakov’s excellent post on Kanban psychology, and the shift in thinking from the habits we’re taught to a more rational behaviour.

This post made me remember what it was like, being a developer who’s discouraged from sitting and reading blog posts, or books, or learning more about the job, but who can’t find much meaningful work to do, so starts on the next most valuable non-valuable thing. The feeling was very similar to the way I feel when I can’t work out what to do, but it’s lunchtime soon, I know I’m not completely stuffed, there’s a snack machine down the corridor, and I’ve got into the habit of kinesthetically nibbling on things when I have nothing else occupying my attention.

I can say “no”. Here’s to better dietary habits, for both me and my projects. Long may they last.

I am a member of a community of thinkers.

I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.

I challenge each community in the software industry to:

• reflect and honor the practitioners who make its existence possible;
• provide an excellent experience for its members;
• support the excellent experience its members provide for their clients and colleagues in all aspects of their professional interactions;
• exemplify, as a body, the professional and humane behavior of its members;
• engage and collaborate within and across communities through respectful exploration of diverse and divergent insights;
• embrace newcomers to the community openly and to celebrate ongoing journeys; and
• thrive on the sustained health of the community and its members through continual reflection and improvement.

I believe that leaders in each community have a responsibility to exhibit these behaviors, and that people who exhibit these behaviors will become leaders.

I am a member of a community of thinkers. If I should happen to be a catalyst more than others, I consider that a tribute to those who have inspired me.

”A Community of Thinkers” by Liz Keogh, Jean Tabaka and Eric Willeke is licensed under a Creative Commons Attribution-Share Alike 3.0 License. Please attribute to the distributor of your copy or derivative.

---

Jean, Eric and I got together in Denver last week. We didn’t start with any particular goal in mind – I was excited to be there because I knew I’d learn something, regardless of what we did. Jean has strong skills in facilitation and collaboration, and Eric’s heavily involved in Lean and Kanban, both of which are currently areas in which I’m focused and learning.

I’ve already seen a small slice of Rally’s culture at their Chiswick offices in London. Jean was kind enough to show us around the Boulder headquarters, where we were warmly welcomed. The layout of the Rally offices is the most effective I’ve seen – large, partitioned project areas with sliding doors, allowing collaboration while avoiding the problem of noise common to open-plan spaces. Jean managed to book us an entire room for the day, complete with a huge jug of coffee.

We started with the idea that we’d produce something for the Lean and Kanban community. Particularly, we expressed a desire to see the LSSC learn from some of the trials that other communities and community-leading organisations have undergone. Ryan Martens, the CTO and a founder of Rally, also provided extensive input. We talked about what communities meant to us, how leaders and leadership manifest within them, and the influence of factors like money, certification, vendor sponsorship, etc. on the community landscape. At the same time I learnt more about facilitation, appreciative enquiry, group psychology, constructive language, the power of well-formed outcomes and the history of the Lean and Kanban movements in and outside of software.

As we talked, we became less convinced that the LSSC actually needed to be challenged, and more concerned with software communities generally. We started writing phrases that we felt represented our views on post-its, and constructed the above challenge by piecing them together. For me, this is a personal statement and commitment – if it’s exactly the same as the copies on Eric or Jean’s sites, it’s only because their arguments were sound and convincing. We were heavily influenced by conversations with Chris Matts and his call for “fewer leaders, more leadership”.

Because of that personal nature, we wanted to avoid putting this up as some kind of centralised manifesto that people can sign. If you feel strongly enough about it that you want to sign up, copy it. Post it on your own site. Attribute it to wherever you got your copy from – the act of sharing is more important to us than the act of creation – and feel free to change it so that it reflects your own values. I don’t think that any statement like this can ever be perfect, nor will we perfectly live up to it.

I am a member of a community of thinkers. So are you.

I hereby release these blog posts under Creative Commons Attribution-Share Alike 3.0. If you want to do anything different to this, please ask.

Dan North’s talk on “the Fallacy of Effectiveness” prompts me to put down the many estimation anti-patterns I’ve encountered. It also reminds me of his blog post on the Perils of Estimation.

Here they are, in alphabetical order, because none is any better than any other:

Budget-driven Estimation

Whatever estimate you come up with will be enlarged by the customer so that he can spend the rest of this year’s budget, otherwise he won’t get it again next year.

Catch-up Estimation

Scrum Master: We have 30 points of work still to do, and only 2 more sprints to do it in. How many points can we manage in a sprint?
Team: 15!
Scrum Master: But we only managed 5 last week! How many do you really think we can manage?
Team: 15!
Scrum Master: (facepalm)

Comedy-driven Estimation

As told to me by Dan from a talk he saw – if you know who it was please let me know so I can credit:

Presenter: How tall am I?
Crowd:5′8″! 5′9″! 2 metres!
Presenter: Go on, you can manage more than that. How tall am I?
Crowd: 6′2″?
Presenter: Come on! You can do better than that! HOW TALL AM I?
Crowd: (Giggles nervously.)
Presenter: Just because a project manager tells you you can do more, it doesn’t make it true.

Done-driven Estimation

A symptom of a pressured team, this method of estimating allows a pair of developers to get the story out of their stream as quickly as possible by eliminating time spent on tedious things like refactoring to make the code maintainable, deployment, manual testing, etc. Symptoms include the oft-quoted “Works on my machine.”

Done-done-driven Estimation

A good team knows, of course, that the code counts for nothing until it’s out there in production, doing the thing it was built to do. Estimates are given with this in mind, but without the help of anyone involved in production deployment, systems integration, performance testing, UAT, etc., because they’re in different teams.

Fractal Estimation

After the scope of the project has been constructed, some stories may be considered too large to fit into an iteration, so the team decide to split them into the smallest possible deliverable slices, re-estimating each slice. Of course, this is a bit like measuring the coast of Britain. The epic which was 13 points at project inception becomes 16 points of features, and 23 points of stories by the time it’s done in the sprints. Analysts wonder where this extra scope came from, while advocates of burn-down charts tuck the growing scope away somewhere where it won’t be noticed.

Goat Estimation

Asking a goat can help when you know it doesn’t really matter what you say, you’ll probably end up doing target-driven estimation anyway.

Job-driven Estimation

As practiced by residential consultancies on Time and Expenses, contract Project Managers and anyone else with an interest in seeing the project go on as long as possible.

M25 driven Estimation

“Yes, I know it took me 3 hours to get around London yesterday, but that was because there was a traffic jam on the M25. Today will be much quicker.”

Pareto Estimation

Often used by teams which have work still left over at the end of an iteration and desperately want to include the incomplete work in their velocity. Unfortunately the Pareto principle, applied to tasks, suggests that 20% of any task will take 80% of the time. Let’s hope the 20%’s not the bit that got left till last.

Post-mortem Estimation

The team chooses estimates that will allow them to avoid the post-mortem inflicted by the project manager when they missed the deadlines last time.

Promise-driven Estimation

Developer: “These estimates… they’re just estimates, right?”
PM: “Don’t let the business hear you say that!”

Like Scrum’s sprint commitments, but used for release or project planning, this estimation method often leads to three-week long project planning meetings before the project starts. Frequently occurs as a result of fixed-price contracts with first-time suppliers. Also the second time. And the third.

Star-Trek Estimation

Geordi La Forge: I told the captain I’d have this analysis done in an hour.
Scotty: How long would it really take?
Geordi La Forge: An hour!
Scotty: Oh. You didn’t tell him how long it would REALLY take, did you?
Geordi La Forge: Of course I did.
Scotty: Oh, laddie. You’ve got a lot to learn if you want people to think of you as a miracle worker.

Student Estimation

If an estimate is chosen wisely, 50% of measurements will fall under the estimate, and 50% will fall over the estimates. Strangely, nothing ever gets handed in early, no matter how inflated the estimate is.

Target Estimation

PM: How many story points can you manage this week?
Team: 10.
PM: That’s not good enough. I need you to do 12. How many can you manage this week?
Team: 12.

Velocity-driven Estimation

Once a target velocity has been established – sometimes by the team itself – the team members will find a reason as to why the work they’re capable of doing does actually add up to 12 story points. Often applied in conjunction with Fractal Estimation.

Zero-outlier Estimation

If being wrong is uncomfortable, a team will wait for the most experienced developer to “throw” their estimate first before following suit. Planning poker fixes the symptoms, but not the problem.

I’ve finally got around to installing wordpress on my professional services site and upgrading to 2.8.3 on this blog.

Then, this morning, I noticed that a link from Wikipedia’s BDD page to one of my old posts was broken. Further investigation showed that several other posts were also missing.

Before I upgraded on my virtual Red Hat server, I dumped the database, imported it into my Windows MySql, and tried the upgrade there. The posts were still fine on the Windows version. I tried reimporting the dump, and ran into the same problem. I can see my missing posts in the SQL file, but they’re not being restored. Still haven’t quite worked out why this happened, or why the upgrade had the same effect as the dodgy restore. I’ll do some more investigation when I have more time.

To cut a long story short, I created a new database, dumped directly from my Windows database to the one on the linux server, then blatted the wordpress options with the ones from the old database so that I didn’t have to go through the hassle of setting up my theme again.

This seems to have worked. If you find any problems, please do let me know.

There’s been a bit of a twitter storm recently, prompted by Cashto’s blog, Uncle Bob’s response, and Justin’s excellent riposte.

So, here’s my response to Cashto’s post. I value unit-level BDD hugely, and it’s fairly intuitive for me. So I’m also going to try putting in some hints and tips about how to get this right, as well as some alternative opinions that I’ve come across recently which surprised me.

I’ll be mixing language here, so that I can respond to Cashto’s language without confusing matters. If you want to use the language of BDD, see my last post.

I’ve snipped bits of your blog, Cashto, because this is already going to be a very long post. Hope that’s OK. I’ve kept your sections in to make it easier for people to read.

(You can skip to the bit where I say it’s Okay not to write unit tests if you want.)

But Unit Tests Work For Me!

Mostly, yes. I don’t tend to mock out domain objects – I use a builder pattern instead. I’ve also written integration tests which talk to the database or file system.

I think of them as descriptions of behaviour, together with some examples which illustrate that behaviour. I’m less worried about whether they’re testing anything than I am about whether people can change the code safely and work out what went wrong, if and when it does go wrong.

If you can reuse units of code and and throw an exception when something is false, you’ve got a tool for the job. All the rest is just reporting, and making feedback faster.

When I learnt TDD, I was at that stage in my career where I didn’t quite get OO and good design. I was lucky enough to come across BDD fairly early in my TDD learning, and that really helped me realise that TDD isn’t about testing. Most of the confusion I can see in your post comes from that word, “test”. I value BDD because it makes me think about the responsibility of my classes, and where I can appropriately delegate other responsibility.

Unlearning is much harder than learning. Once a senior developer whom I respect hugely stormed out of the room because I found it so difficult to code without writing tests first, and it was slowing him down. Eventually we realised that I was using them to understand the context of what we were doing. After that I was able to contribute much more productively. If someone really likes their unit tests, they may be doing the same thing – just trying to understand your thoughts and write them down.

As I’ve become better at BDD, I’ve started becoming more pragmatic about where I write tests and where I don’t. On my toy projects, if a class can be tested by cursory inspection and it’s covered by something somewhere else – an acceptance test or scenario, maybe – then I might skip it. If in doubt, I tend to write the test. I’ll certainly write something if there’s someone else on the team who needs to understand why I wrote the code I’m about to write. I also use them to help me with the design.

Unit Tests Give Me Confidence When Refactoring!

Sometimes I find this is true. It’s not so painful, though, because the design that I’ve created through BDD is simple enough that my class is no bigger than my head, and has maybe four aspects of behaviour. It’s fairly easy to change that behaviour, and the full sentences that I use to describe what I’m testing makes it easy to see what old behaviour I should be changing.

I agree that any such test isn’t really useful. The only reason for having tests is to help you change the product – otherwise you might as well manually test it, treat it as fragile and never change it again. If tests aren’t helping make change easy, there’s something wrong.

Unit Tests Catch Bugs!

Oh, yes. Don’t do that, people. The rest of the team are bright, intelligent people; if you give them a chance to understand the code you just wrote, they’ll use it correctly. Writing tests to describe why your code is valuable and how to use it can really help here.

Try pair-programming, and getting one person to write the tests which the other person codes. I’ve certainly blinded myself to my own bugs on my toy projects before. Fortunately my automated scenarios or my manual testing tend to catch this.

Absolutely, which is why experienced, professional testers are so valuable. They think of all the scenarios we missed. They behave like users determined to break your app. I love those sneaky buggers.

They do help me fix them more quickly.

Unit Tests Improve My Design!

I keep seeing this. I even saw someone do this in Programming with the Stars. Don’t do this! Write an example of how you’re going to use the code. It’s not about testing individual methods; it’s about the behaviour of an object as a whole. If you need more than one method for a class to be valuable, show how you’d use them in conjunction.

Of course, if you’re writing tests first, you’ve got the interfaces because you have no idea what’s going to implement them, so you’re completely independent of the implementation. Imagine it’s all done by pixies.

TDD as the Cujo of the Agile world…

I do sometimes find I have to revisit the way I’m using my collaborators, once I’ve actually tried to use them from the real code. This is the only time I’ve found that encapsulation breaks; I’m dependent, at least a little bit, on the implementation. I’ve not found this to be much of a problem, though. More modern, BDD-style mocking frameworks such as Mockito (Java) or Moq (.NET) also help to keep things easy to understand and change.

BDD, and the language of BDD, helped me to learn those practices. I also recommend Martin Fowler’s “Refactoring” and Eric Evans’ “Domain Driven Design”.

I hear this too. I’ve been trying to learn languages like Haskell. Maybe I should put more effort in here.

If You Can’t Test It, You Can’t Ship It!

For some people, in some contexts, it’s okay not to write unit tests. I’ve spoken to a few people who haven’t yet learned to write unit tests, but who are writing excellent code, usually with automated scenarios that test the whole system. This includes one better known member of the Kanban community, who’s been delivering code quickly and successfully for years. I certainly won’t sneer at any team or individual who can deliver working software while enabling change, however it’s done.

Rather than discouraging people from writing tests at all, I’d encourage them to look at how to get the first kind of tests instead of the second.

But It’s The Corporate Standard!

Or, they may recognise that people in their organisation are still learning, and are putting these standards in place to ensure that the team have the space, time and motivation to learn. They may also recognise the value of tests in documenting code, allowing them to move developers between teams more easily, bring in new people, etc.

Oh, yes. Don’t do that. Question everything, challenge everything – but try it out first.

So What Are You Saying, Man?

Possibly. Unit testing isn’t actually about testing, though. The word “test” is such a misleading term; it’s not just about finding bugs. It’s about preventing the bugs from happening in the first place.

The closer to production you get, the more important the feedback loops are. The most important feedback loop of all, of course, is putting the code into production and seeing if it’s as valuable as you think. (I’m learning about other important reasons for doing this too.)

Do try to make sure that the rest of your team can find value in your code, understand how to use it and change it safely.

It did. These are problems with TDD that I come across frequently. Pretending they’re not there isn’t as useful as addressing them, so I hope my response has helped too. Thanks, Cashto.

Prompted by the recent twitter storm, prompted by Uncle Bob, Justin Etheridge and Cashto, here’s some sample language that I use when I’m coaching or thinking about BDD, instead of TDD. I’ve found this language really helps people adopt TDD (for my flavour of it!)

More on this soon.

TDD	BDD
test	example
class under test	class we’re describing
method under test	valuable behaviour
what to test	why is this class valuable?
how to test	how do I want to use this class?
interface	role
mock	collaborator playing <this> role
design	responsibility
passing	working, providing value
failing	should it do what I’ve described?
verify that	ensure that
assert that	ensure that
returns true / false	tells me that…
returns <object>	gives me…
implements <interface>	provides <the benefit of the role>
pinning the code down so it won’t break	making the code easy to use, understand and change.
100% coverage	Please, come change my code. I believe I’ve given you enough information to do this safely.

Many people have difficulty when they first encounter haiku in crafting a poem that’s aesthetically pleasing, with as few syllables as a haiku permits. (In Japanese, the “5-7-5″ pattern is used, but in English some of us find that the haiku moment works best in about 12-13 syllables).

So, I thought I would give you some simple techniques for writing haiku, which should be well-aligned with your methodology of choice.

Scrum haiku

Start with a poem.
Remove the least important words, until the result appears pleasing. There is your haiku.

Kanban haiku

Start with nothing.
Add words carefully until the result is pleasing, then move on to the next haiku.

XP haiku

Start with a poem.
Halve it. Keep halving it until it is no longer pleasing. That was your haiku.