Team using Waiting for Release column on their kanban board

Question

My team is using Kanban board but they seem to prefer to collate a couple of tickets then 'do a release' as appose to releasing each ticket. i.e. they move tickets through the workflow and then put them in a waiting column for days on end and then they do sporadic releases.

This obviously seems sub-optimal but then again its just another queue column so maybe its not the end of the world.

Does anyone have any suggestions about this and also any guidelines about the WIP of this queue column 'Waiting for release'

Answer 1

It is not clear if your team is doing production support or software/ app dev. Assuming it is app dev, there are a few questions to consider -

1. What is the customer's need for the releases your team is making? If there is no pressure from customer to do a release or if the pressure is sporadic or infrequent, then there is nothing much your team can do about it. However, over longer periods of time, across multiple customers, if your team is - or becomes - challenged with having to maintain multiple versions of your product, there is a cost to that. It is then up to them - or some business function like sales or support - to have the conversation with your customers that they need to accept new releases at a certain frequency or they may be at a risk of not getting the support they might need on an old version of the product.

2. Is there an internal stakeholder - such as Product Owner or Sales or Management - who anyway needs to see what work the team has competed - and done so satisfactorily - at least from a quality and market requirements perspective? If yes, it might be worthwhile for them to deploy new or updated code to an internal staging/ demo server so they can do demos to your stakeholders - or let them get their hands dirty and help validate the new/ updated features of the product.

If it is a production support environment, there may be some SLA (service level agreement) goals to be met (response time, resolution time, etc.) - which would again need some pre-defined frequency of releases in order to meet those SLAs. Again, without more information, it would appear your team is not facing SLA violation issues and unhappy customers.

Based on these, there certainly are guidelines for you to follow about how to model your Kanban board so it matches your current business processes - and helps you improve, as Daniel pointed out above.

1. WIP Limits are meant to encourage people to finish work at hand before taking up new stuff. If these are not implemented, you might have a situation where half-done tickets lie around in intermediate in-progress or done stages waiting for some external dependency (customer input, shared resources, etc.) and the team, instead of resolving them, takes up new tickets. Pretty soon, you can have a slow-moving Kanban board with low flow and throughput and high lead times.

2. Instead of calling the last column "waiting for release", it could simply be better named - either "Deployed to Staging" or just "Completed" - so it is clear to everyone concerned that no more work is pending other than putting it out in a release.

However, just to be clear - Kanban is not prescriptive in nature - and it simply asks you to start with what you have - and look for improvement opportunities. If your unpredictable release schedule is a (perceived) problem, it can be easily fixed by defining an explicit policy to do releases every 1, 2 or 4 or 6 weeks, whatever is acceptable in the business context. If it is not, and everyone knows what "Waiting for Release" means, there's no need to change anything!

I'd like to share the example of our own Dev team (we are a Kanban product developer - SwiftKanban), which has a somewhat similar situation. We have both SaaS and on-prem customers. We do SaaS releases every 4-6 weeks - that cadence is well established. But, our on-prem customers may take new releases as late as once in 3 months only - and we have little control over that - it is really based on their own cost of deploying a new release from a vendor.

So, we follow a process similar to what I described above - and this is what our Kanban board looks like -

As you might be able to tell, our internal staging server (just to the left of the green Production column) is Ganesha - and we deploy new features, bug-fixes and other enhancements on a fairly continuous basis. This server is used as an "internal production" server where we run our company operations - such as Marketing, HR, etc.

So, cards sitting in the Ganesha column are cards that are done and deployed. We have no WIP Limit here - but our policy is to deploy a new release to production when we have approximately 20 items completed. All other columns on the board have WIP limits as needed - based on the number of people working on each stage.

Like I said, we deploy to our SaaS production regularly every 4-6 weeks. Our customers can take up new releases every 1-3 months whenever they are ready. So you could easily set a WIP limit on a similar column and use that limit to ensure that the team deploys to production when the WIP Limit has been reached. It is really up to your team and your customers as to what makes sense!

Hope this helps.

Answer 2

First thing is first: Kanban has no queue columns. This is an anti-pattern.

To elaborate, a Kanban board is a visual representation of a workflow. In workflow mapping, we do not represent wait states as steps in a process, rather as notes in the transition from one step to another.

Further, this indicates work being pushed to the next step instead of being pulled (since no one can pull into a wait state). This also leads us to the solution. If you assume that someone doing the next step must pull the work from the previous column then we see that there should be a WIP limit on the last step (probably dev or test in most teams) and items only go into release when someone is releasing them.

Further, a team using Kanban should always be trying to reduce their cycle and lead time. That is usually the primary driver to break up those batches.

On Common Visualization of Queues

You may have seen something like this:

There is a common misconception about what this is showing. Here, both Dev and Ready for Test are the same column and have the same WIP. If the WIP is 4, there should be a max of 4 items in the whole column. The dotted line is just a visual indicator that items are ready to pull. It says the same as if you just had the dev column and put a green checkmark on cards that you finished writing code for.

Answer 3

I don't know anything about a Kanban board. But I do know software development having been a project manager for IBM on an outsourcing contract.

At the particular customer site there were really two types of development happening. Most of the teams were supporting legacy systems which need only sporadic changes made by a lone programmer. My team, with a dozen programmers, was the only one actively developing new features with multiple releases in the pipeline. We also did a major new release yearly.

"One size" did not fit both types of workflow. Putting a new release of software into production for us required coordination between the team of developers working on different parts of the application. There was testing for the release. We had to develop a checklist of how the various jobs were going to be run on the production server to implement the new release. Sometimes releases had database updates which would run longer than overnight so we had to coordinate downtime with the customer.

My biggest contribution by far was to stop the whack a fix by my team and to have formal release cycles. After starting to use formal release cycles we never put the wrong code into the production system. The releases were not always bug free, but we did know what code was in the production system for any given release.

The gist is that depending on the overall scope of the software development effort, a release per software change may not be practical.