Elizabeth Keogh

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.

Originally published at Liz Keogh's blog. Please leave any comments there.

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.

Originally published at Liz Keogh's blog. Please leave any comments there.

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.

Originally published at Liz Keogh's blog. Please leave any comments there.

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.

Wikimedia Commons, CC Attributions ShareAlike 3.0

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.

Originally published at Liz Keogh's blog. Please leave any comments there.

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.

Originally published at Liz Keogh's blog. Please leave any comments there.

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.

Originally published at Liz Keogh's blog. Please leave any comments there.

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.

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

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.

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

I’ve been invited to submit a talk to the Lean and Kanban conference in Atlanta, on how Lean principles have changed the way in which I approach TDD (which of course is BDD for me).

For those of you on this side of the pond, I’ll be rehearsing this talk on November 9th at Skills Matter. This is a free evening, and there won’t be any podcasts or slides released - so it’ll be your only chance to see it this side of April!

Book here if you want to attend.

Please remember that if you’ve booked and can’t come, someone else may be waiting for your place - so send Skills Matter an email to let them know, and they’ll get in touch with the waiting list.

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

The paradox of mocking

When we code from the outside-in in BDD, we start with the layer we know - the UI, often graphical - establish collaborators for the UI, establish collaborators for those classes, and work our way inwards until we run out of collaborators we haven’t coded.

We write examples (tests) for each unit of code, all the way down, and we usually express the collaborations with mocks.

The trouble is, we don’t really know how the class we’re about to code is going to use its collaborators. We can only guess. When I actually come to code the class, I often find that I want to use the collaborator in a different way to the way I expected. When I come to code the collaborator, I might find that it needs more information than its consuming class is giving it to do its job properly.

In this case, I have to back up and change the way that I’m expressing the collaboration in the examples. I change method names and signatures for my collaborator according to the things I’ve learnt from actually using it.

I’d rather do this - work out how I actually want to use a class, then change the descriptions - than be forced to conform to the guesswork that I made.

Multi-pair stories

Yesterday, one of the development team said, “If you’re doing XP, you only have one pair on each story, so if you have four developers, you’ll have two stories in play. It doesn’t make any sense to try to limit it to one.”

I’ve heard some of the Kanban community talk about “swarming” a feature; getting a whole team of, say, 8 developers to take it on and complete it in a short time. I’ve also found that some of them prefer not to split up the features as finely as I do, into very thin vertical slices; instead, the teams work on something marketable.

This makes sense, if you’re going to parcel out chunks of code. The idea of slicing things horizontally goes against most of what I teach about how to write stories - and yet, it does allow a larger team to get something valuable out the door more quickly than BDD’s pure outside-in.

It turns out that guessing what might need to happen further down a stack isn’t much different to guessing what happens with a collaborator, before the class is actually written. Realising this has made me revisit my assumptions about the need to do pure outside-in work. So how can we do this and still call it BDD? How can we gain confidence that we’re writing software that really matters, and doing so efficiently?

I can remember occasions at Thoughtworks where we did this - particularly, finishing off features to hit deadlines at the Guardian. Some of the developers at my current client are also working this way, as are others in the industry. So, here are my suggestions for making this work.

BDD for swarms

• Use scenarios. Having a clear understanding of the feature and a set of scenarios to which the team can work to helps keep everyone focused on the actual behaviour needed. This means it’s less likely that pairs and individuals will write code “just in case”. If in doubt, YAGNI. The scenarios will tell you if you missed something, once all the chunks are integrated.
• Get something working. Start with the happy path or simplest scenario, and integrate this as soon as you can. This will provide a “backbone” for the rest of the scenarios. It also lets the team play through the different scenarios to test their work.
• Mock out collaborators. If you need other classes for end-to-end testing, knock up something really simple or use a mock to allow you to get some feedback. For instance, I make a smiley face appear on my Game of Life exercise when I click the button, just so that I can see that the GUI events are wired up. It takes about 5 minutes to do something like this. Name your simple classes in a way which makes it obvious, so that they don’t get mixed up with the production code and can be safely deleted later.
• Talk to the team. Conversation around what you’re doing will be crucial! If an interface has been defined at the boundary of the code, and you need to change it, go tell the other teams. They’ll be able to adapt to, or at least be aware of, the changes.
• The rest of the team is your customer. When it comes to the name of a method or the value that’s wanted from that method, the “upstream” team - closer to the outside - trump the downstream team. When it comes to the information that’s required to do the job, the downstream team win.
  

  
  List<Pet> pets = petStore.getPets(String name);
  

  
  The upstream team can ask to change the List to a Set, or the name of the method to getPetsByName. The downstream team can say, “Hey, we need the type of pet too; we’ve got a hamster, a rabbit and a kitten all called Snowy.”
• Prefer code that’s easy to use over code that’s easy to write. If you’re upstream, trust that the rest of your team will be able to solve the problem you’re about to set for them. Keep pushing the complexity down, and remember: Tell, don’t ask.
• Use examples to drive your code. When you code a module further down the stack without looking to see what’s going to use it, you’re indulging in guesswork. Write some examples of how you expect the consuming class to be using yours, then revisit them when you have more information.
• Write examples to help other people code. Ideally, the upstream team will provide examples of how they want the collaborator to behave to the downstream team. These examples can be built incrementally, as the upstream team come up with features.
• Share code. If the teams check in before the code is finished, their scenarios will fail. If they check in examples which haven’t yet been coded, those examples will fail. This won’t be a problem if no one else is modifying the code base; however, if it’s a subset of a much larger team breaking the build can cause havoc, and the habit of keeping builds green is a good one. Try distributed version control, which will allow a team to check in on USB keys or a temporary space until the code works. (There are techniques for getting, say, Mercurial, to work alongside, say, Subversion - mostly by making each system ignore the other). You could also pass around patch files to keep the code in sync.
• Delete unused code. If at all possible, check the code as it’s being integrated and delete anything which isn’t actually being used or going to be used. This might include things like database columns, layers of abstraction which aren’t actually valuable, etc.
• Look for quick feedback. If you haven’t integrated your code within a few hours, it’s probably wrong. Making the assumption that it’s wrong should help you want to integrate it more frequently.
• The more, the merrier! Look over each other’s shoulders as you pass! There’s nothing wrong with tripling or quadrupling instead of pairing, if it means that a pair is more likely to write the right software later.

Edit:

Eric Willeke responded to my post with his own perspective on swarming. I very much like the idea of having the skeleton (the simplest scenario?) ready in time for the rest of the team to get on board.

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

The Lean and Kanban conference was hugely fun, with phenomenal speakers, passionate attendees and as many disparate topics as could possibly be imagined falling under the Lean umbrella.

I particularly liked John Seddon’s approach, which I’ll boil down to “Apply common sense before tools”, as well as his highly descriptive and colourful narrative style; Don Reinertsen’s challenge to understand and apply a science-based approach; and the stories from the many practitioners who shared their adoption techniques and learnings.

I also loved seeing 12 people there either employed by or working for my current client. They take the effort required to transform an organisation seriously, while making it as fun as it can possibly be. I’ve thoroughly enjoyed working here for the last couple of months. Their focus on learning, and the strongly aligned culture and values that people here display, have made my work both simple and fascinating.

I took away a few Big Things from the conference, some of which I’ll be doing more of, and some of which I’ll be changing. Here they are:

Visual Representations

Software is highly abstract. If we were actually building cars, we’d be able to see what’s going on. As it is, it’s electronic, and hidden. Making things visible (and tactile) provides a mechanism for seeing constraints, a physical central point around which people can congregate, and a more effective radiator for anyone outside the team who might be interested. I’ve realised how much I’ve been missing as a coach because I can’t see the flow of the projects, and am now fiercely encouraging the teams I’m involved with to move to cards / post-its, even if it’s a copy of the electronic system.

The Kanban boards we’re using don’t necessarily look exactly like the ones used in manufacturing. That’s OK. Alan Shalloway had some methods for knowing whether the right things were visible or not – anything which causes queues, impairs flow, allows us to discover waste. John Seddon made me realise that we need to know where the problem is before we apply the tools which make it visible, or else we risk optimizing in the wrong place. Just about everyone suggested learning from any mistakes we make in this area.

Product Development vs. Production Line

A lot of the techniques which are used in the production line are designed to minimise variability and achieve a smooth, even flow of similar components in a system. This doesn’t necessarily map to software very well. I’ve already talked quite a lot about this difference, and where the production line metaphors might be applicable. I also tend to emphasise the need to learn as part of continuous improvement. When we’re producing new software, the learning aspects are more important; we want to learn from variability rather than minimise it.

This was something that I felt very powerfully anyway. Hearing the same message from people who are well respected by the community improves my confidence.

A lot of the things we think are wasteful, aren’t

This came particularly from Don Reinertsen’s talk. He used the metaphor of TCP/IP to demonstrate that single-item flow may not be efficient in some situations, and that we have to consider the transaction cost; that even Toyota have some queues, and some batches. I’ve shuffled one of his earlier books, “Managing the Design Factory”, up to the top of my reading list (it’s already on my shelf!) Looking forward to reading about the maths, too.

I was pleased to hear Don mention Real Options. The idea of keeping options open, and particularly of paying to defer commitment, is becoming a huge enabler. I’d love to get this to the point where I can value options more accurately. It’s already helping teams defer decisions at my client, particularly around tool choices and architecture / design. I’d love to have better ways of measuring the cost of deferring against the value of the options it provides. This plays very well with Feature Injection – keeping our decisions around the analysis open for as long as possible, and minimising the analysis WIP – which also plays nicely into the Kanban pull system.

Manufacturing techniques do not map exactly into the Software world

Alan Shalloway switched it round first – it’s not that Lean principles come from Toyota, as much as that Toyota comes from Lean principles. The actual practices we derive from those principles will therefore be different. He separates practices into three different areas – Lean Science (flow, cadence, pull, systems thinking, etc.), Lean Management (leadership, coaching, visual controls), and Lean Knowledge and Stwewardship (kaizen, people and process improvement).

I think the over-application of manufacturing practices – or the assumption from non-Kanbanites that this happens – has formed part of the difficult communication between the Scrum and Kanban communities lately. We’re still mostly about the people and empowerment, honest.

Automated tests are crucial

Or, as Alan said, “Don’t let anything into your stream until you know how to get it out of your stream.” He talks about exit criteria, rather than acceptance criteria. Other speakers also brought up the need for automated end-to-end testing. This focus makes me happy, since it’s very well aligned with BDD (Dan would say ‘essential’). Having seen testing become the constraint on almost every one of the projects here, I’m going back to those roots. We’ve got some work ahead of us to sort out appropriate environments, engage the infrastructure and maintenance teams effectively, and find tools and harnesses to help us.

The alternative is an escalating cost of change as testers struggle with growing code-bases, often generated by teams still learning to create high-quality, zero-defect code. I don’t buy the arguments about “just a three-month project” or “prototype”, since I’ve seen these turn into full-fledged enterprise applications more often than not.

People, people, people

I know that most of the Lean and Kanban community are also involved in Agile, and are highly respectful and people-oriented. I was initially surprised at the focus on tools and practices, maths, metaphor, terminology and process.

That was when I realised that this community – even more so than most of the Agile communities I’ve been involved with – are hugely respectful, communicative, collaborative and fun-loving. They don’t talk about people much because it’s all about the people.

What particularly struck me was the lack of discussion about failure, either at a team or a personal level. Sure, speakers talked about learning, but rarely about that team that could never have delivered because of their lack of skill or that manager that stopped us doing the right thing, both of which are story-patterns I’ve heard a lot in the Agile community. Beneath every speaker’s message seemed to be an assumption that any team can achieve amazing results; that people are capable of adapting to situations, learning new skills and chipping in; that innovation is not merely possible, but natural. I’m revisiting my earlier thoughts about teams needing to be disciplined to try Kanban out – the things I’m hearing suggest that’s my novice approach at fault, not the team’s.

Amongst the rarities is John Seddon, who uses some fairly colourful language to describe a number of systemic problems he’s seen. I couldn’t pin him down to criticism of a particular company, team or individual, though, apart from one: “The only reason you employ someone like me,” he says, “is so that you don’t make the same mistakes that I did 20 years ago.”

Originally published at Liz Keogh's blog. Please leave any comments there.

Sometimes people ask me, “When we’ve gone Agile… when we are fully Lean… what will it look like?”

The only answer I can come up with is this:

Things will be changing. You’ll be in a better place to respond to change. Your people will have a culture of courage and respect, and will seek continuous improvement, feedback and learning.

I don’t know what your process will look like. The Lean and Agile communities have some ideas you can use to start with. Not all of them will work. Your processes will change, and keep changing.

I have no idea what skills your people will need. The people you have are good people; start with them. The need for their skills will change, and keep changing.

I don’t know what language, tools or technologies you’ll be using. Start with something that’s easy to change. Technology will change, and keep changing.

I don’t know which projects will succeed. Start with the most important project, or the most risky, or the one which has the highest cost of delay. Your market, your business and your customers will change, and keep changing.

There is no end-state with Agile or Lean. You’ll be improving, and continue to improve, trying new things out and discarding the ones which don’t work.

If you do find yourself with an end-state, the chances are that you’ve documented your processes somewhere, and are now asking your teams to adhere to them. Either your process is perfect, or you haven’t reached the end-state yet. I’m guessing your process isn’t perfect. Change, and keep changing.

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

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

Kanban: Bring it.

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

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

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

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

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

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

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

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

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

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

Scrum: They’re in it for the money…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Kanban: Let’s call it a draw.

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

FATALITY!

Winner: XP

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

Chris McMahon mentioned my example of a coaching kanban board in the second of his series of posts against Kanban. That it comes across as simple and infantile in Chris’s example is my fault; I only really touched on the “signal” aspect of the kanban board in this conversation, and didn’t go into more detail. So, in this post, I hope to correct that.

Picture a scene. You’re one of five coaches, hired to help transform the IT department of Screwfix. As part of this effort, you’ve set up a lovely story board on which you put the things you’re working on. This is the kind of thing that we had on our boards (all stories in this post are just examples, I can’t remember the exact concerns):

Each day, the coaching team met for a daily stand-up around this board. Our goal was to put our little avatars on the boards to show what we were working on, and move the stories (on post-its) to “done” when we had finished. After a couple of weeks, we realised - we weren’t actually using the board.

“The problem is,” Andy said, “half the things that we’re doing aren’t the kind of things we can move to ‘done’. They’re ongoing.”

“Right,” I agreed, “and half of them aren’t even on this board. There’s all kinds of things we’re doing with respect to the competition, coaching individuals, writing workshops, etc., and they’re not even up here. I wonder what we can do differently?”

At the time, I was hearing a lot of buzz around the word “Kanban”, and reading the Poppendieck’s “Lean Software Development”. It occurred to me that we might be able to use it to help us manage our coaching efforts.

So, I drew up a new board, and talked to our head coach, Chris, about it. “I’ve realised that I can cope with about three concerns at a time,” I said. “If you try to get me to worry about a fourth, I’ll promise to do it, and then something else will drop off the radar. It doesn’t matter how much I promise to do four things, realistically I’ll only get three done well at any time. So, I’m going to limit myself to 3.” I talked to the other coaches, and we found our own limits: 3 for each of the other coaches, and 1 for our part-time coach, Antony. So here’s what our new board looked like:

“Why, Helen!” I exclaimed, grinning. “You’ve got a space there.” I took a new post-it and wrote, “GIVE ME WORK!” on it, then stuck it in Helen’s space.

“What? No!” Helen exclaimed. “I can’t possibly take on any more work!”

“Well, either your limit is wrong - it’s OK to only manage two things - or there’s something you’re working on that’s not up there. Team C’s quite big; is that taking up about twice as much time as normal?”

“Not really,” Helen said thoughtfully. “There’s something else I’m working on. Let me think a moment… Ah! Of course, I’m also running the Agile induction course.” She wrote a post-it to replace mine.

“That’s great,” Chris said. “Now I can see what you’re working on, and also what you’re not working on.” We had a chat about some of the items in our backlog, and talked about when we might be able to bring them into play.

The board was much more effective, helping us juggle our workload appropriately, until it came close to the time for me to leave. Suddenly, I found I had more work than I could possibly manage.

So I cornered Chris. “You know how I said if I ended up doing four things, something would drop off the radar?” I asked.

“Yes…”

“Well, turns out it’s my lunch-hour. I’m exhausted; this isn’t sustainable. Can we sort something out?”

“Of course!” Chris said. So we got the coaches around the board to look at what we were all working on.

Chris looked at the various teams, competitions, workshops, technological strategies and other coaching concerns. “I don’t really care too much about these,” he said, removing about ten items from our (overly large) backlog. “And we don’t need to worry about Team B any more - I think they’ve got it. I’d really like you to run the other coaching workshops before you leave though, Liz.”

“Right,” I said, “then someone else needs to take over the TDD training.”

“I can’t,” Helen said, “I’m not technical. I’ve just finished the last Agile induction course, though, so I’ve got space to pick something else up. Andy’s been facilitating the retros; why don’t I take that instead, and then Andy could do the TDD training?”

“That works,” Andy replied. We swapped stories accordingly, moving them into their new places.

“Fantastic,” I smiled. “Anyone fancy some lunch?”

Having the visual aid helped us prioritise our efforts, as well as letting us share and organise our concerns. The most important aspect of this, for me, was the realistic recognition of our limits, which allowed Chris to direct our focus much more effectively. The Kanban board was just a tool for us, not a process or methodology in its own right. Nor did it replace conversation. It just facilitated it, and acted as a visual radiator. I found it useful, and I hope you enjoyed reading about it.

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

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

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

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

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

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

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

Originally published at Liz Keogh's blog. Please leave any comments there.

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

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

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

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

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

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

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

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

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

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

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

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

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

Ask for consistent outputs, not consistent processes

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

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

Andy is one of these incidental stakeholders.

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

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

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

Software development is not a production line

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

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

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

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

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

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

Integration and deployment is a production line

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

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

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

Automation doesn’t make it easier

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

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

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

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

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

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

Pat Kua’s running a Dreyfus modelling session at Agile 2009 that you should attend if you’re there and remotely interested in how people learn.

Contrary to what it says in the printed program, I won’t be helping to run it. I would have loved to, and unfortunately managed to overcommit some time between the decision to add me to the program and asking if I was available. I think we’ll try that the other way round next time…

So, apologies if you were hoping to go to that session to hear me speak. Go anyway. Pat’s coach-coaching has made a significant difference to my skills, he’s a clear and imaginative speaker, and the outline looks like educational fun, as do the results of the last time he ran this.

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