Some thoughts on Limiting work in progress (WIP)

Limiting your work in progress (WIP) has several benefits I can think of in making individuals and teams more effective

Maintaining Focus
If you regularly have to switch between tasks to get something done, or worse still some outside force is causing you to constantly switch, it is much harder to focus on the individual pieces of work.

When there is a lack of focus, mistakes are more readily made or aspects missed from the work.

Reduction of work / thinking time duplication
When it comes to knowledge based tasks, switching between different tasks has a significant time cost associated with it.  If you start working on some task that is going to take a half day to complete, but after a couple of hours have to work on something different, a significant amount of time is required to get back to where you were with the original work.

Working on one task until it is ready to pass on to the next stage gives better feedback on how long that type of activity can take.  Better feedback helps you more accurately adjust any estimation you are required to provide.


Maintaining a good flow of work
Switching between tasks interferes with the flow of those tasks and can delay work being completed at the perceived time. Any planning and estimation done prior to the work may not be judged correctly if you do not include time wasted due to task switching.

If you minimise your work in progress and only work on one task at once it is easier to get accurate measurements of time required to complete each task, giving better feedback to your planning and estimation activities.


Avoid building a psychological mountain
If you have too much work or you see the work as to vast or complicated, there is a natural tendency to be overwhelmed or demotivated by the scale or complexity of the work.

Humans can process more work when it is viewed as small and not overly complex.


Technical Debt / Stale work
If you have a lot of work that is in progress, then the effort already invested into it has yet to deliver any value to the customer (in a personal Kanban, the customer may often be yourself).  The more work in progress you have therefore means more investment without return of value.

In manufacturing, if you have a high investment (inventory) without delivering any value (sold products) then your business is not being effective.

In software development, if you have a large number of requirements (stories, use cases, etc) in various stages of development, then that is a considerable investment made without that software realising those requirements in the hands of the paying customers.

If you minimise the overall work in progress you have less investment and less risk should there be a change to the project.

Summary
There may well be other benefits to limiting your work in progress, but this is all I can think of for a wet Sunday afternoon.  If you can suggest others, I would be most interested.

Thank you.

Reading list for learning Kanban and Lean

On my way to understanding lean concepts through the use of Kanban, I have found books by the following authors invaluable:

Eliyahu M. Goldratt
Reading The Goal was a fantastic journey into thinking about lean without getting bogged down in anything technical.  The Goal is a great novel and a long way from a dull technical book, it really gets you thinking about the core ideas behind Kanban.  Following with a more specific book on the Theory of Constraints defines the lessons learnt in The Goal and adds ideas on how to manage your own constraints in the system.

David J. Anderson
David J. Anderson is one of those leading a march towards Kanban and Lean adoption in software development and his Kanban book is a great guide to applying Kanban to your existing process and identifying opportunities to improve.

Alan Shalloway et al.
The Lean-Agile software development book includes the experiences of the authors extending agile practices into the wider organisation by adding lean techniques to the mix.

Douglas Adams

Douglas Adams had a fascinating way of looking at the world and always came up with brilliant ways of conveying that vision.  The way that Douglas would talk through Dirk Gently about the interconnectedness of all things really did grow my ability to engage in system thinking.  Reading the two Dirk Gently books: Dirk Gently's Holistic detective Agency and The Long dark tea time of the soul will help get you in a lean thinking way.

There are of course many other good books on Lean, but these are the ones that have suited me best so far (although there is still a lot to read).

Agile Fairytale - stories to express agile concepts

Agile fairytale is a neat way to express agile concepts in a way that is easily understood, using a context more likely to be meaningful or recognisable to a wide audience.


At the heart of Agile Fairytales are three fundamental concepts:

• Agile Values - Agile Fairytales extends the 5 Agile values of Communication, Simplicity, Courage, Feedback, Respect to include Trust and Transparency and applies them to real life
• People - Agile Fairytales is based on the belief that we can all change for the better
• Continuous Improvement - Agile Fairytales encourages us to improve one step at a time

A Creative Thinking Tool

Agile Fairytales uses simple narratives to structure the way we look at problems. Each fairytale is designed to give us insights into our experiences through a better understanding of ourselves.

When to Use Agile Fairytales

Agile Fairytales are useful in the following situations:

• As an icebreaker
• When creating a new team
• For improving the performance of team members
• As a game with friends and family

Interesting presentations from Agile2010

Here are some presentations I found from the Agile 2010 conference:

Business value modeling - agilecoach.com

QCon brainstorming night

Thanks to the hospitality of the QCon organisesrs, last nights QCon brainstorming session was a great event. As well as all the great discussions going on, there was a seriously generous helping of really nice food and what seemed a never ending supply of drinks.

QCon is a regular event aimed at those interested and engaged in enterprise software development.  The event aims to provide the highest quality presenters and most engaging topics each year.  Previously the QCon schedule has been organised from the input of those wishing to present, but for QCon 2011 the goal is to include ideas and recommendations from the community of people who pay to attend QCon when deciding on the schedule.

There was over 30 people that turned up and it was a great atmosphere. I turned up there early (no surprise) with a friend and we were greeted by our very friendly host, Jørn Larsen (on the far right of the picture).

The evening started with all of us grouped around a big table with lots of flipchart sheets and post-it notes.  As not everyone was lucky enough to make QCon 2010, we briefly discussed QCon and the different types of days and event that typically go.  Usually there are two days of tutorials before the main conference, with the conference itself having a large number of tracks each day (see QCon 2010 tracks).

For the brainstorming proper, we started creating lists of topics we thought would be good for the next qcon event and also identifying any speakers we thought were really good at presenting and generally entertaining the crowd.

I started the ball rolling by writing down some ideas, although half way through writing my first idea I had a feeling that everyone was watching me.  When I looked up everyone was watching me, but got on with adding my crazy ideas and this helped encourage everyone else to do the same.

Very quickly there was a wealth of ideas that came poring out and after I had run out of ideas myself I started writing down lots of ideas that people were discussing as them to make sure they were captured.

We also had a kind of retrospective sheet where we could put post-it notes on for things we wanted to see more of or less of, as well as things to start doing and stop doing.  The funniest comment I saw was to "Stop giving uncle bob martin a small room" - alluding to the fact that he is always a popular speaker and you cant always get in to see him.

All the flipchart sheets got stuck to the wall and we churned out dozens of sheets worth of ideas.  However, it all kind of got put on hold when the first wave of food turned up.  Yes, there was so much food that it did come in waves.  No one went home hungry and even I was too full by the end to want a doggy back to take home what was left.

There were lots of great discussions happening, its a shame we didn't record them for AppleTV!!  There was a continuing trickle of ideas added in between the food, drink and chat until the end of the evening.

Jen and his team now have a very busy few days going through all the weird and wonderful ideas that the group came up with, including all my Kanban, lean system thinking, rightshifting and continual improvements suggestions (I think there was a whole page just on those).  If even just a small part of the ideas we all came up with make it in then QCon 2011 should be a really great event.

If you want to know more about what may be appearing at QCon 2011, you can have a look at the tracks for QCon 2010. The most interesting ones for me were  Agile Evolution, Software Craftsmanship, Dev and Ops: A single team and Irresponsible Architectures & Unusual Architects