Showing posts with label Kanban. Show all posts
Showing posts with label Kanban. Show all posts

Friday, 30 September 2011

Two years on kanban

Having used kanban as a catalyst for continual improvement I feel more capable, confident and way more productive than I have ever been in my life.  Starting with a simple plan-doing-done approach to my kanban boards, I quickly evolved them to meet the needs of particular situations.

I have created many kanban style boards for managing specific areas of my life, such as my own career and skills development, moving house, preparing for 400km cycle rides and starting my own company.  Kanban really helped me pull in and evaluate other ideas to build on how I work and help me become more effective.

Kanban is not a solution or silver bullet in itself, but this simple to use techniques allow you to develop an effective way to manage, to help you get things done!

Lean practices, system thinking and theory of constraints all kick-started a big change and kanban was the technique that made it all come together.  By encouraging me to look at what I was doing and how I was doing it, I had an every growing focus on how to deliver value to myself and to others.  I could no longer hide so easily from the truth and tell myself little white lies about a situation, the information on the kanban board kept me honest and encouraged me to evaluate my actions.

Awareness
Just being aware of your circumstances is a major advancement for most individuals and organisations.  It is all to easy for us to get too wrapped up in today's deadline without thinking of other concerns (such as if todays deadline is actually of value and if you are doing the right thing to maximise that value).

Managing myself
It is often so much easier managing and advising other people than it is to manage yourself.  This is perhaps in part why CxO roles have personal assistance - a service that we could all use to help us focus.  As a consultant I feel that psychologically it is much easier to work with a customer to help them improve than it is to help myself improve.  Part of that ease is the excitement of learning something new and part is that I am working with someone else.

Through personal kanban and associated lean techniques I have found my own way to manage myself effectively without adding any sense of burdon.  Psychologically, I now rarely find it a chore to manage myself as I can easily balance the time I spend being creative with the time I need to focus and deliver value.  I can make lots of small decisions throughout the day as to what I need to do to meet my goals, giving a great deal of flexibility.

I can also quickly see what I have achieve and this gives a great boost as when we are busy we often forget the great things we have achieved that day.


Managing others
No one likes to be micro-managed and all good managers dont actually like to micro-manage people.  So kanban can be used to focus groups of people (eg. project teams if you use them) towards a particular goal or business vision.  Kanban allows the group to not only be a part of the decision process of how to achieve these goals, but also visualise how effective those decisions are with respect to those goals.

At any time, if there is a valuable reason the decisions taken previously could be changes or adapted to move with wider changes in the organisation.

I feel that kanban can be used to help drive progress towards goals very effectively, leading to real management by everyone, or as I like to call it - leadership.


Getting people to help - collaborative delegation
Kanban is a technique that shows real strength when it encourages people to collaborate and I have experience of kanban being a trigger to help cultural change.  By encouraging people to get involved, to use the knowledge and experiences to the full, to challenge them and make them much more responsible for the work they do really drives a sense of meaning within them.

There is no need for motivational posters when people love the work they do, the way they work and know that the are delivering real value to the organisation every day.  People like to feel part of something bigger and get a kick from helping other

In Summary
Kanban is a great technique once you understand its context, and used with lean and kaizen ideas it is one of those things that really reflects what you put into it.  Like any good relationship, if you care about your kanban board it will care for you in return.


Saturday, 19 March 2011

Smallest Responsible Change (was Minimal responsible feature)

Whilst discussing the merits of Behaviour Driven Development at one of the XTC gatherings, I started using the term minimal responsible feature as a way to express how to decide what piece of work to tackle next.  I promised Liz Keogh many moons ago that I would write a blog post about it.

In the time it has taken me to write this post (its been kicking around in my backlog for a while) I have evolved my thinking on the term and now prefer to use smallest responsible change (SRC).

The smallest responsible name was triggered by looking at the term minimal marketable feature (MMF), considering what that term expressed and the values that I associated with it.  I still like the MMF term as a more specific way of expressing a similar concept.  With the smallest responsible change I have a term that I am happy to use in a wide range of contexts which helps promote discussion on how to be effective and make value flow.

Smallest responsible change is a nice general expression of how I like to tackle the work I do, so that the work flows more smoothly and I get more done.  Creating a very effective way of turning large body of work into a series of value deliveries.

Smallest
I try where ever to tackle a series of smaller tasks that one big task.  This approach tends to earlier feedback from the results of that work.

For example, when writing some new functionality, I will pick out a single piece of behaviour from the requirements (user story, use case) and express that behaviour in a scenario / example (a.k.a acceptance test / unit test).  Once the behaviour is defined and implemented by code, I am already getting feedback on the work I am doing.  Any feedback from running the behaviour scenarios (a.k.a tests) I receive shapes the next task.  If a failing test still fails, I know I need to work on the implementation code.  If a passing test now fails, I know I have to look at the code and design and maybe refactor.


Responsible
What does it mean to be responsible?  You ask ten people you will get 10 different answers.  This is not surprising as our experiences and feelings about a situation come from a unique history - our life to date.

The decision on what is a responsible action to take is therefore based on our current circumstances and our previous history, with hopefully a good dash of holistic thinking.

To be able to define and select the next most responsible action to take therefore requires you to think about your circumstances and base your actions on achieving value.

For example, if you a person next to you collapsed it may be the most responsible thing to try and give them immediate attention if you had basic first aid training.  If you had no first aid training, then a cry for help may be the most responsible thing.  If there is no one around, then a call to the emergency services may be the most responsible thing to do.

In software development, if you submit code that breaks the build and the build bunny shames you, it could be the most responsible thing to roll back you code.  It could equally be the most responsible thing to call over some of your team and ask them what is going on (someone may have forgotten to tell you about an API change).  It could also be possible that this issue is always happening with the team and you suggest the team get together and find the root cause to the problem.


Change
Change is happening all the time around us and we need to manage and filter all those changes so we can actually move forward (without a break down).

If you consider the way the brain works with the eye, the eye captures a constant stream of change so the brain has to filter out and focus on just what is important.  If it were not for this filtering effect our brain would be overwhelmed.

It is important to limit the amount of change we are dealing with at any moment in time, so the changes are experienced at the rate we can acceptance and deal with them.  It may be seen as heroic to work 12 hours a day and multi-task like crazy, but that is less likely to deliver significant value to your company than if you work at a pace you can sustain.  If we can find a way to filter out changes (tasks) that are of no value at this time, then we can really focus on those few changes that have real value.


Example from a personal development context
If I want to read a book, what is the smallest responsible change I can do.  Well, I often define a card on my kanban board to define the value I believe I will get from reading the book and some idea of how to attain and check that I gained that value (or perhaps see if there was anything else I gained).  This is the smallest thing I can do and it is probably the most responsible thing to do as well.

Part of this first smallest responsible change may be to decide how to read the book and I have a common approach of reading chapter by chapter and also treating the book as if I were reviewing it for others.  So the next smallest responsible change would be to read the first chapter and start to write down my impression of the book and anything important I had learnt.

The feedback from reading the first chapter may be that I think the book has mislead me about the value I would gain and I would therefore abandon reading any further.  This feedback would then save me much time in the future, as not only would I skip read the rest of the book but I would have a reason as to why I dont want to try read the book at a later date.

If I tried to do this with several books at the same time, increasing the amount of change I was dealing with, there would be a lot of context switching between the information in each book, even more so if the books were on different topics.  I would have to unload and reload different ideas from each book as I switched over.  It would be very easy to mix my impressions and feedback from one book with another and hence make an incorrect value judgement.

Friday, 4 March 2011

Kanban games night

Karl Scotland and I will be running a free games night at Skills Matter on the evening of 7th March at SkilsMatter - London, UK.

Karl has kindly volunteered to run the games night before his talk at QCon later in the week. Karl will be running the ball flow game to help us learn and experience kanban and system thinking concepts in a collaborative way. It will also be a lot of fun, as fun is an effective way to learn.

You should get a lot out of this evening whether your experienced practitioner or you are completely new to kanban, lean, system thinking and theory of constraints. The evening will be a welcoming and safe environment to everyone.

Rough plan for the evening:
6.00 pm An opportunity to networking, chat to people
6.30 pm Start to the evening proper: Introduction and games
8.00 pm Retire to the Hat and Feathers for further discussions (optional)

Event sign-up

The hat and feathers is on the corner of Clerkenwell and Goswell road. You are free to join us there if you cant make the event.

Thank you
John Stevenson | @JR0cket JR0cket.co.uk | JR0cket.com | LeanAgileMachine.com

Wednesday, 16 February 2011

Kanban elevator pitch

My elevator pitch for kanban would be along the following lines..

"Kanban is a way to incrementally and continually improve your approach to meeting your goals, by understanding the situation clearly, identifying the real challenges and testing out your chosen options for resolving those challenges."


As with everything Lean and Agile, this elevator pitch will most likely evolve and can be made more specific depending on different audiences, but I am fairly happy with this general pitch.

Thank you

Wednesday, 19 January 2011

Kanban clinic

At February's Limited WIP Society meeting we are having a Kanban Clinic where you have your chance to build your own personal or team kanban board from scratch. You can also work with others to help them build a board if you want to see a kanban board evolve.

If you have an existing board (kanban, scrum, or otherwise), please feel free to bring it along (the design not necessarily the board) and get feedback and advice on any aspects you want to improve on the board.

There is no formal presentation although ideas and examples will be shown and questions arising from the practical work will be discussed.

The slides and presentation video from the January Limited WIP socieity meeting are available on the SkillsMatter website.

Thank you

Saturday, 8 January 2011

TDD Kanban for Deliberate Practice

To help keep you in a good flow when you are learning or practising the TDD test first approach, it can be useful to use a simple kanban board to manage your flow.

The TDD kanban helps you to focus on each step, helping you to stick to test-code-refactor.

The TDD kanban board has three lanes as follows

Test - you are writing a single test
Code - you are writing code to pass a particular test that is failing
Refactor - you are changing the internal workings of your code

You only have one card on your kanban board (this is your work in progress limit), this reminds you which activity you should be working on and should help you get into the test-code-refactor routine.

The card itself is blank and does not refer to any required behaviour or example code.

Using the TDD Kanban board
To start, place your one and only card on the test lane of the kanban board.

Once you have written a failing test and run your tests, move the card on the kanban board to the code lane and write just enough code to make the test pass. 

Once you have written enough code to make the test pass (running all tests), move the card on the kanban board to the refactor lane.

When you have finished your refactor work and have run the tests, move the card back to the test lane and write another failing test.

Credits
The TDD Kanban concept is from the mini kanban display at Jon Jagger's cyberdojo (that's my hand) at the SkillsMatter Lean Agile exchange 2010.

Tuesday, 4 January 2011

Personal Kanban workshop - 13th January 2011 - Limited WIP Society

To kick off 2011 and to help keep on track with our new years resolutions and goals for the year, the Limited WIP Society are running a personal kanban workshop at SkillsMatter on the 13th January.

Sign up page!!

Personal kanban has been used to manage our busy lives very effectively by a growing number of people and I too have found it invaluable to get so much more out of 2010.

I would like to share the techniques I have been using with personal kanban, such as just-in-time planning, review techniques, managing events, keeping in line with personal goals, etc. The workshop is also an opportunity to show your techniques to manage your priorities.

The workshop will be a great opportunity to gather lots of ideas on how to make the most out of 2011.

I have written articles on personal kanban for personal development and just-in-time skills training.  You will also find the interesting material at the personal kanban 101 website.

Thank you

Tuesday, 14 December 2010

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


Thursday, 9 September 2010

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


Sunday, 21 February 2010

Getting started with BDD and Kanban

I am starting writing entry points for getting started with BDD and Kanban, now that Blogspot lets me have pages on this blog.

On the BDD page I have done a quick mind map using Freemind in preparation for the BDD immersion workshop with Liz Keogh on the 26th Feb.

On the Kanban page, there is a quick intro to KanBan and some pointers on how to build a KanBan board and the artefacts that you could add to make the board more expressive.

These pages will evolve as my understanding and experience grows.  Any comments or ideas for these pages are very welcome.

Saturday, 16 January 2010

Personal Kanban for Just-in-time skills development

It is not uncommon in IT projects that you are required to learn something on the fly or you see an opportunity to introduce a new technique or tool that would bring great benefits to a project.

How do you manage the learning curve required for something new without major impact to the project?

After reading comments from my previous personal Kanban post by Jim Benson and Bruce, I thought I would expand on the Just-in-time aspect of Kanban.

I currently use my personal Kanban (LeanKitKanban) to drop small size cards into my backlog that are designed to tell me what I need to learn about a subject or tool quickly.  The cards have a set goal that should be manageable in a short time period.  Each card would have the relevant resources links to help me achieve that goal.

When I get a spare hour I can select one of these and have a focused, time-boxed cards and get up to speed quickly.  If I have met the goal and feel confident that what I have learnt was beneficial (either personally or for current work) then I mark that card as a success.  If I don't meet the goal, then I will mark the card as incomplete and review it in a mini retrospective.  The goal of the retrospective is to help me write better cards quickly, as well as check that the topics I am learning are coheirent.

An example would be good right now:

I was at the Agile Testing user group in December and there was some discussion on continuous integration.  I realised that this area has really flourished since I last set up Cruise Control, so I created a group of cards on my Kanban to look at what's new in continuous integration and to reaffirm that I was up to date with the latest practices.  In that same week as the meeting I had manage to review the theory (Google, Wikipedia) and learnt a new tool called Hudson (great tool, I recommend it, neatly integrated with Netbeans).  All this was pretty easy to fit into my busy schedule as I could easily visualise all my work on the Kanban and see what was important that week and what could wait.

I still have several continuous related cards in the backlog, but for now I have refreshed enough theory to work with Hudson effectively in my project work.  If I need to learn Team City or some other CI tool, then I have a model to quickly tackle that learning.

This approach works for me at present as I break down the task on the card to something managable.  I am curious to find out how well I can break a large subject area down with this process, for example learning the whole of Spring 3.

For now I will be using this JIT Kanban learning to review and extend my Behaviour Driven Development (BDD) skills as I have a BDD immersion workshop in February with Liz Keogh at SkillsMatter and want to make sure I get the most of the workshop.  It should be a great day of learning as Liz has done a great deal of work defining BDD and adding lean system thinking into the topics that will be covered.  There will be some homework to take away from the course, so I'll be using my personal Kanban to organise that work into my busy schedule.

Thursday, 14 January 2010

Personal Kanban to manage personal development

Having an inquisitive minds is a great thing but there can be a tenancy to be interested in too many things that you never learn something deeply enough. How do you stop the inquisitive monster in you mind and get on with just one thing?

I have been using a Kanban system to plan my study and added work in process (WIP) limits to manage the flow so my monster is tamed and I focus on one thing.  Any future interests are quickly dropped into my backlog so my monster is satisfied that there is lots more to learn.

I started with a basic design for my Kanban, with the lanes Review, Study and Blogging which nicely followed the plan-do-act design that is often used for visual boards.

After a week of this Kanban design, I felt that something was missing between review and study.  When I completed a study task there was not a clear set of tasks I could choose from which I new I wanted to study.  I would end up looking at review tasks that I had not finished (or started) meaning more time planning rather than studying.  As duplicating planning of study tasks is wasteful, I modified the board design to include a Ready to Study lane so I could quickly choose the next topic.

I renamed Study to Deep in Study to indicate that this was generally a bigger process and I would need to set aside more time.  I reinforced the idea that deep in study was a bigger task by limiting the WIP to 2 tasks (I am allowing 2 tasks as I am still detoxing from multi-tasking for far too long).

Once I had completed a study task, the plan was to blog about that topic to help retain the knowledge I had gained.  I found it useful to add yet another lane called Evaluating to help me review what I had learnt and had a better idea of what to blog about.

Using a Kanban approach has also helped me develop skills in a just-in-time approach.  By adding small tasks to my backlog to help me evaluate new areas of study or tools, I have a pool quick work that I can fit in when I need a break from deeper study.  Carrying out a brief review of something new allows me to work out what I need to learn, how much effort it would be to learn and most importantly if it is really worth learning yet.  From this quick analysis I can create a number of study and exercise tasks in my Kanban backlog that would help me learn efficiently, indicating effort and priority of each task.