Archive for June, 2010

Kanban – the book

16/06/2010

I have quite recently had the pleasure of reading David Anderson’s latest book on Kanban. I thought I had a pretty good understanding of Kanban before I started reading it. However, I still had some unanswered questions – some – which for a while might have reduced my confidence in persuading my peers to just try it. After reading the book I got most of my questions answered, and at the time of writing we are just starting to experiment with a little bit of Kanban on my current project. Happy days!

Whether you know nothing about Kanban or consider yourself fairly well educated on the topic I think the book is definitely worth reading. Instead of giving a full summary of the book, I thought I should give you some of the answers to the questions I got answered from reading the book (as I understood it, although I might also be a bit influenced by other sources):

  • How do you really get started? Take your current process, visualize it (on a board) and apply WIP limits. Try measuring lead time, and maybe create a cumulative flow diagram. For longer term success, you should get some buy-in / agreement from up- and downstream stakeholders though.
  • What is some of the major selling points? Create a predictable performing team. Reduce lead time. Optimize throughput. Expose bottlenecks.
  • How do you deal with blocked stories? Kanban should force the team to swarm on a blocked story, with the result of resolving it. It might need to be escalated, but then again a manager should see the importance of helping to resolve the issue.
  • When do you release, plan, ..? Kanban allows you to decouple input cycles from output cycles. That is, you could release every Monday if you want, but perhaps only have meetings to fill up the input queue every two weeks. You could have a retrospective every third Friday if you want. Or you could even trigger these events on an as needed basis.
  • How do you become predictable when stories might vary in size, priority ..? Classes of Service! For example: a ‘standard story’ will be finished in 14 days on average. ‘Expedite stories’ will be finished in 10 days on average, but you are only allowed to have one expedite story in play at any one time and so forth. David describes other interesting examples of Classes of Service as well, I highly recommend you to read this.

I think I should stop here and leave someting for you to read as well 😀

Advertisements

Pair Programming Workshop at Agile Spain 2010

14/06/2010

I had the pleasure of facilitating a workshop at Agile Spain last week. Apparently this was the first Agile Spain ever. I must say the people at the conference were very enthusiastic and eager to learn more about Agile. I met lots of interesting people, and really appreciated how welcoming everyone was. A special thanks to those who translated eager Spanish discussions for me.

My workshop consisted of two parts. First my initial presentation called Pair Programming Strategies. My proposal to the conference was intended as a workshop around what we tend to do when our ideal pairing situation comes under pressure from various disturbing forces. My understanding is that conference organizers will post the slides on Slideshare, meanwhile you can take a look at the PDF here: Pair Programming Strategies – Agile Spain 2010.

The second part was an Open Space discussion. It turned out that less than half of the participants had tried pair programming, and only a few were doing it on a daily basis. However, the Open Space format was very adaptive to the participants’ needs, and it seemed we ended up with a set of interesting topics. Here is a quick summary of the discussions, based on the notes I gathered from each group (thanks for writing this down!). (If you participated in the workshop and are reading this blog, please feel free to add some comments. I wish I had taped the summaries everyone gave at the end.)

How do you start (pair programming)

This group was curious about how you actually get started with pair programming. Here are some keywords from the discussion:

  • Physical setup: Big screen / 2 screens. Movable keyboard / 2 keyboards.
  • Write down what you are working on.
  • Driver / copilot / supervisor. Switch roles.
  • Responsibility – Collective code ownership
  • It could be exhausting
  • Good merge with TDD. One writes the test, the other writes the code to pass it (Ping, pong)

Performance impact

This group discussed whether pair programming is an effective way to work or not. Here are some keywords:

  • Just for core functionality or also easy tasks?
  • What about deadlocks?
  • More focus
  • Knowledge transfer
  • Share responsibilities
  • Less or more stressful?
  • Tight schedules

The study referred to in this Wikipedia article which observed “a 15% increase in time, but a 15% decrease in bugs”, was mentioned as an example of a quantitative measure on the effectiveness of pair programming.

Distributed Pairing

This group discussed how or whether it is possible to do distributed pair programming.

  • Network latency is a problem
  • Very high bandwidth required
  • Communication services, such as video/audio must be working all the time
  • Desktop sharing tools
  • Different timezones
  • Is it possible to reproduce benefits of pairing remotely?
  • Try it first with people you have paired with co-located earlier
  • Multiple monitors

If I remember correctly, the group concluded that you needed to create an environment that was as close to a co-located one as possible. Then you would hopefully achieve a flow that was approximately the same as in a co-located setting.

Disagreement

Eventually someone formed this last group, discussing disagreement. They discussed what to do with a deadlock. And suggested one should involve a third person.

I asked everyone to give me a quick feedback on their way out, the result was 17 “+”, 7 “+/-” and 0 “-“. Among suggestions for improvements was to find a room without tables, as well as make it more dynamic. I am quite pleased with the feedback, but will do my best to improve. If you have more feedback, please leave a comment or send me an email (erlingwl (at) gmail (dot) com).

A big thanks to everyone who participated. I had a great time in Madrid 🙂