Kanban Archives - Vertical Software

Kanban board columns

Below is a pretty much “default” Kanban board & the relevant columns. We still use CFD’s to analyse & hopefully improve flow through our system. So what I’ve been pondering is whether the below is right for us.

We have 2 main queues that I want to talk about today. The Dev Done & the Ready for Release. I’m going to focus on the right side of the board to start with as this is the most valuable side…

What we tend to see over our sprints is a build up towards the end of the sprint. I’m now pondering the benefit of the Ready for Release column. Over time stories/work builds up here and is not release. Part of my limited WIP side comes in to play as well, as soon as I see more than 3/4 cards in play. I’m probably thinking a little bit about the size of the release and the riskiness of the release too.

So this is starting to make me question:

Is this really a good column to have?
Why are we completing stuff in test then not releasing it straight away? Maybe the transaction cost to live is too much, if this is the case then this is the problem that needs to be highlighted and gone after.
Are the stories not valuable to be released independently and maybe the relative value of them is not important?

I’m also questioning the benefit of any queues in the system – like the one between Dev Done & Test. It seems as though this is a smell rather than a solution to flowing work through the system. Queues are just a way to buffer another piece of the system from inconsistent flow of work, most of the work on the board can be controlled by the team. We have cross functional dedicated teams, therefore they should be able to “dev & test” in a single flow.

Some may say that the start of the system is a queue, but in fact this is simply an input buffer to the system/team. This helps to prevent variance within the system so that there is always enough work for the team to work on. Therefore, my opinion is that this is “required”.

Has anybody been able to eradicate these columns?

Maybe all I’m thinking about is Single Piece Flow really…

XPMan Introduction to Kanban

Tonight I facilitated an intro to Kanban at XPMan. This was to run through what Kanban is, and introduce the 5 core properties of Kanban.

The slides for the presentation/discussion points contained the following:

Visualising workflow
Limit WIP
Measure & Manage Flow
Make Process Policies Explicit
Use Models to Evaluate Improvement Opportunities

We didn’t cover everything in Kanban, but hopefully people got an idea of what it is and how they can start using it.

I’d like to re-emphasis that you should apply it to your current process – it doesn’t replace what you do currently it just overlays it. Look at the stats that you get out of it, and let them drive your incremental change

Links:
Kanban Dev mailing group
Limited WIP Society, Manchester
Kanban 101
Limited WIP society

Books:
Kanban – written by David Anderson the “creator” of Kanban for software development.
Personal Kanban – how to apply Kanban to yourself!
Scrumban – applying Kanban with SCRUM
The Goal – need I say anything?

XPManchester:
XPManchester blog
XPManchester group

Thanks to everyone who turned up and joined in. Hopefully provoked some interesting conversations and more importantly gave you some ideas to take away.

Limited WIP Society – Open Space

I attended the second Limited WIP Society group @ LateRooms.com – this was in the format of an Open Space – essentially this is a conference style half hour time slots on things about Kanban and other systems thinking stuff… The tracks that I attended are below – I’ve tried to remember as much as possible!!

MMF’s (Minimum Marketable Feature)

This was interesting discussion – the main point was the importance of understanding what value. The definition of value must be shared between the business and development…

Other interesting points:

Capability in order to be able to deliver a MMF – so in essence there has to be the technical ability to deliver something within a day. I.e. can you write code, test it and deploy it easily enough in a day. If you can’t then your transaction cost is too much and you are not going to get the benefit from a MMF. The other interesting discussion was about business capability – the business needs to be in a position where it can receive MMF’s and understand the impact on them.
MMF’s are all about reducing risk, delivering value, and having a constant feedback cycle.
Someone mentioned a graph in order to decide on whether an item is an MMF – I can’t find it at the moment.
Alkthough it’s important to say “No” – some times its better to give people options to the business users.
I’ve also heard of people using the following to decide on an MMF or to clear a backlog:

Somewhat unrelated but still important:

Kanban doesn’t work with multiple delivery teams. If the team does not deliver the same thing then Kanban can’t work.

Daily Stand-Ups & Retrospectives

The focus of the meeting should be unblocking the blocked issues – everything else is unimportant.
Important that at the stand-up the team is protected. You need to reduce the external pressure.
Managers have a changed role within Kanban – they have to prioritise and help to unblock issues – rather than manage people.
The granularity of tasks is important – if the tasks are too big and nothing moves then something is probably wrong.
The issues within the stand-up are important but the detail of the issue is not important.
Some retrospectives should focus on analysing data others should be in the normal retrospective style – i.e. what went well, what went not too well, and what can we do better next time. It’s important that during a retrospective that everyone has done the best that they can do.

Coaching

This was an interesting talk but unfortunately I didn’t take many notes. It mainly surrounded the fact that the change to Kanban is a cultural one which can be hard to invoke. Somehow we managed to start talking about The Choice by Goldratt! @wisemonkeyash talked about the glaze of resistance/layers of resistance and has posted this awesome link about why change is difficult. We started to talk about mermaids, and crocodiles! However, the overaching thing for me was that everyone is open to change it is just the way in which you invoke the change that is important. It has certainly highlighted that I need to read “The Choice” and other books – i.e. Driving Technical Change.

Identify Bottlenecks

This was mostly inspired by the Theory of Constraints – why and how it is important to find a bottleneck. What to do with a bottleneck and other random thoughts about inventory in software development. I found this talk to be one of the most interesting because it’s a topic that I’m very interested in at the moment – for this reason I’m not going to excessively talk about it! This blog contains enough thoughts about this! It’s highlighted some interesting things about trying to elevate the bottleneck – something we are not doing at the moment.

An excellent night. I know I’ve probably missed some information!

Efficient Vs. Effective

I’ve been thinking about “The Goal” of Kanban in our organisation for some time.

I believe that there are numerous (side/non) goals – however, the one true goal is to deliver high quality, business value to the customer. However, to enable this to happen a Kaizen (continous improvement) environment is likely to aid & probably help you on this “path” to the goal (you might never get to the goal – it is after all a goal). You also have to accept that life/business/software dev/nothing is never static so you have to be able to adapt your process to ensure that you keep delivering value to your customer. This Kaizen environment helps people to eliminate waste, but also empower people to make changes to a process or system which isn’t helping to deliver value to the customer. Anything that doesn’t add value is essentially waste.

I think there is a lot of “Non-Value Added” time during software development. In fact maybe the only “Value Added” time is the point in which you push/pull it to live. Everything else might just be “Non-Value Added” time!

So what exactly is efficiency within Software Development – well to me now it’s clear – thanks to wikipedia & the above mind burb! Efficiency in software development is anything that is not “Value Adding” in your current value stream.

Now you might think – well if you’ve got Kaizen time (i.e. slack time to improve your process) how is this adding value to your current value stream. Well it might be something to help improve the flow within the value stream. This is as important because you are trying to optimise the current value stream – so essentially you are aiming to add value or remove waste from your value stream (agh confusing!). It’s important to accept that these might fail sometimes – but hey people make mistakes and learn from them.

I think Effectiveness & Efficiency get confused. I’m certainly confused this late at night! Let me give some arbitrary examples of measuring these two things…

Measuring Effectiveness might be measuring the number of LOC (Lines Of Code) a developer writes. However, this is irrelevant in line with the “Goal”.

Measuring Efficiency might be measuring the amount of Business Value a developer delivers to the business. This is more relevant to the “Goal”, and to some degree is measurable against the goal.

However, this will promote local optima – promoting selfishness, and definitely promoting a non-kaizen environment. This would lead to a process which is not optimised – you essentially get silos of optimised process, with other areas unoptimised. That’s why it is important to look at your full value stream when measuring Efficiency.

Before measuring Effectiveness think about the impact this might have on your overall “Goal”.

Thanks to the following for making me think about this stuff way too much:

Increased WIP = Increase in Lead Time

I’ve been viewing our Cumulative Flow Diagram and some interesting stats surrounding the work we are developing, our current flow rate and WIP. Today I was able to see how increasing our WIP directly affects our Lead Time.

Our big spike is due to all the items being placed on the backlog (TODO) – although some of these may never be implemented more on this in the future!

To summarize some of the information I can see (and you can’t!):

Average Lead Time for any sized item from inception to live:

35 days – 7 and 11 items in progress
21 days – 2 and 5 items in progress

There are a number of things to note:

Variability in size has an impact on lead time – large items increase lead time.
Increase in Work in Progress decreases lead time.

The above ties nicely in to Little’s Law.

Ye Olde Story

Back at the start of time, or rather the inception of the company there was a small IT department this had to work closely with the business in order to fulfill the ever changing requirements of the business. The IT department of two had to work this way to ensure that the newly found company always had the competitive advantage.

Unfortunately, as the company got bigger more things started to flow in to the system (IT team) and slowly the development team of two where overwhelmed with the requests being asked of them. They became the bottleneck in the system. In order to alleviate this bottleneck the company hired two more people, this had the desired affect and the IT team could develop some of the functionality that the business wanted. At the same time the company hired more people with more great ideas of how to improve the business.

As the business grew, the list of items for IT expanded exponentially until it became full of things which added little bits of business value but at high cost, the list of items was not prioritised.

At this time the IT department decided that it needed to help manage this list of items because the development team couldn’t complete all the work. The company decided on introducing contracts and processes so that when those pesky users could only put something on the list if it was fully thought of – or at least had enough detail to work on. The customer started to gold plate features/products just to ensure they get there idea got through; this meant that the bottleneck which was the development team started to do work on items which added very little value to the business.

Parts of the process was deemed to work well for a period of time, but alas no-one recorded the before and after to see whether the new found processes improved the flow through the system. Even more importantly, no-one measured whether the development team delivered value to the customer.

The IT department started to monitor work it realised that it was slow to deliver change to the business. The processes that had been put in place to manage the work were not delivering value to the customer as quickly as the IT department had envisioned.

The solution to delivering value was simple but hard to implement. The IT department needed to realise the following:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

The “pesky end users” where in fact the customers and needed help to get rid of items which didn’t add value or not have a good ROI – this needed to be done through improved communication – rather than more processes and barriers.

Fortunately, the IT department realised that it needed to evolve from its current state in to a new state, where it delivered high value software to its customer. This was only going to happen through hard work, and through frank conversations within the team, and by evolving there processes to match their customers’ needs.

Delayed Value

Having my last look at the board today, I found it interesting that we have work items sat in the “Ready For Production” column. The total items in this has grown over the last couple of weeks – we now have 7 items ready for “Production”.

These items all have a varying level of “Business Value” (value) associated with them – but are sat in the system. They are all blocked by the same thing – the legacy system has a quarterly release cycle.

This poses a couple of questions:

Is there a threshold before the amount of value being delivered outweighs the cost of putting that value live?
Should every single piece of item developed be pushed live as soon as it is ready – therefore giving you an instance ROI?
Are the items of high enough value to the customer if they can just sit in the “Done” column for a couple of weeks?
Do the customers have visibility of what is “Done”?

My gut feel is that the first question is a cop out – the cost of pushing things in to a live environment should be minimal because you should really have seemless CI. It should be of no extra cost to put code in to a live environment. If it costs – you need to spend time & money on improving this build & deploy system. This is an Internal Quality as Martin Fowler puts it.

If you push every single piece of work live you need to have customers who can accept a constantly changing system. This maybe difficult but I think it depends on what you are delivering – i.e. defect fixes, and minor enhancements could be dropped in at any point. With large changes in functionality – it depends on how involved the customer has been with the development. Here we probably can’t do it, because the customer is not overly involved.

The above statement probably answers the last two questions as well. It’s all about the customer deciding on what to develop – this way they can decide upon the items with the highest value. They also know when items are complete.

This is one of the 4 principles in the Agile Manifesto – “Customer Collaboration”.

Kanban – Retrospective – Categories for Improvement

We keep having weekly retrospectives about the Kanban board.

Last week’s retrospective probably went a tad off target, or maybe it produced ideas which don’t improve the process of our team, rather than general ideas about the board. Note: no idea is wrong or right during these retrospectives – it’s just the focus might have been lost on the purpose of Kanban.

Last week we looked at things that “went well”, things that “went wrong” and things that we wanted to “improve”. We then voted on which improvement ideas we wanted to implement. You can see what we implemented in my last blog post.
This week we invited Andy (our very own Lean/Agile samurai) to the retrospective, partly to see how we should run a retrospective, and partly to get some focus back on Kanban.

The following was the rough structure of the retrospective. The first was a discussion between pairs about “Why we wanted to do Kanban?” and also “What we wanted to change?” These where put on post it’s and stuck to the wall randomly.

We silently organised as a team the post-it’s into groups. I found it especially interesting the commonality between the post-it’s that each of the pairs came up with – probably not very interesting since we all share the same goals & grievances!

The team then came up with the following list of categories for each of the groups of the post-its (in no particular order – I just wrote them down this way!!):

Teamwork
Customer Satisfaction
Problem Identification
Prioritisation
Predictability
Speed
Transparency

The team scored each of these with either an “x” “–“ or “tick” depending on how we felt things were currently. We scored the majority with a “-“on some categorices and “x”’s on other categories – as you would expect. None we scored with a “tick” – we had some small ticks though!!!

We then paired again (with different pairs) and asked each other how we could improve the process targeting the above categories.

We fed this all back in to a whiteboard – and came up with a list of things to improve. We each had 3 votes again and got to vote on an idea we’d like to implement. The ideas we are going to implement are as follows:

Measure cycle time overall and between different work types & stages.
Limit number of items coming in to the start of the workflow & each stage.
Cut things down into smaller chunks of highest value.

We are going to try to implement these this coming week, to see if it improves parts of the process. The impact might not be immediate but Rome wasn’t built in a day (I’ve used that quote too often recently!).

An important thing for me is that we start to get some stats about the work we do in our “development system” – i.e. how long it takes for us to complete different work – what is the cycle time for a specific type of work?