Here’s is another question that I recently answered on a discussion forum –
“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 it’s 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’?”
To Release or Not to Release… When, is the Question!
Clearly, this person was looking at Kanban as a continuous delivery tool or method and felt that not doing so was being sub-optimal. Their Kanban board might look like this –
But, the reality is that the Kanban Method by itself does not make any prescriptions of when and how often to make a product release. It merely facilitates continuous delivery and deployment. However, the actual ability of the customer – or your own Ops team to make “production” deployments depends on the “transaction & coordination costs of deployment plus costs & tolerance of customer to take delivery”, as described in David Anderson’s KMP class material. (In this context, Kanban actually facilitates a “2-phase Commit” process about which more at the end of this post.)
This merely reflects the realities of business of different organizations or teams – and their customers, both internal and external. Most corporate IT organizations, for example, cannot and do not accept product update releases from vendors more than once in 3 months or often even less frequently. Their need to ensure security and performance, besides other considerations, means that they need to put in a lot of effort to test each new release they accept in their environment. On the other hand, most SaaS/ Cloud vendors have the capability to deploy much faster, even daily.
So, it really depends on the business context rather than the development and delivery method being followed.
What is the business context? Support, SLAs, Meeting Market Requirements
From the questioner’s post, it is not clear if their 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 completed – 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. These SLAs – and the release urgency/ frequency – would also depend on the criticality of the issues being worked on. Urgent/ critical defect fixes require faster release deployments while low criticality defects or new features – no so much. In this case, based on the information in the question, it appeared that their team was 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.
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.
As mentioned earlier – Kanban is not prescriptive in nature – it simply asks you to start with what you have (your current process) – and look for improvement opportunities (process improvements). 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, or every time 2 or 3 or some acceptable number of tickets is completed, whatever is acceptable in the business context. If the current release schedule is not a problem, and everyone knows what “Waiting for Release” means, there’s no need to change anything!
Supporting SaaS and On-Prem Customers
I’d like to share the example of our own Dev team, which has a somewhat similar situation. We have both SaaS and on-premise (on-prem) customers, and in fact our ability to support both types of customers for all our products is a key differentiator for us. So our ability to support this is a business requirement for us.
We do product releases every 4-6 weeks, and these get deployed to our SaaS servers – 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 vendors.
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 on this server. This server is used as an “internal production” server where we run our company operations – such as Marketing, HR, etc. This way, we have the whole company testing any new features and bug fixes!
Cards sitting in the Ganesha column represent work that is completed and deployed on Staging. We have no WIP Limit here – but our policy is to deploy a new release to production when we have approximately 20 items completed or every 4-6 weeks. (Some other factors affect this, especially key marketing events such as a conference or a customer meet, etc. for which we might either speed up or delay a release to accommodate the needs of that event). All other columns on the board have WIP limits as needed – based on the number of people working on each stage.
Like I mentioned earlier, we deploy to our SaaS production server regularly every 4-6 weeks. On the other hand, our on-prem customers can take up new releases every 1-3 months, whenever they are ready. When they do so, they will need to take 2 or more of our releases (so they become current with our latest version) and apply them to their staging or test environment, test them fully and then apply them to their production environment.
In your case, the “Waiting for Release” column works like your staging server. If you think it is needed, you could easily set an explicit policy or a WIP limit on the column and use that to ensure that the team deploys to production or delivers a customer release as per the policy. Since your team is already behaving in that manner, this might just help formalize it so everyone is on the same page about it.
It is really up to your team and your customers as to what makes sense! Hope this helps.
Kanban and the 2-Phase Commit
Kanban has a really simple, yet critical feature, which, in my opinion, provides the most elegant solution to a problem that has forever dogged most software teams and their customers!
Committing to doing Work
Software teams have suffered forever from unmet customer expectations. On the one hand, there is the problem of high or unpredictable incoming demand on a software team from their customers. As soon as a customer communicates these requirements to the team, the team is deemed to have agreed to work on them and deliver to them on a “timely basis”, whether the team is in a position to accept more work or not. Not only is the work assumed to be accepted, the team is also assumed to be already working on them – so the clock starts ticking on these new requirements as well. This has an adverse impact on the lead time performance of the team – and to a perceived poor performance in the eyes of the customer.
At the same time, very often, after a team starts to work on some new requirements, customers often step in and make changes to the requirements. Or, worse, discard (cancel) them altogether, because for whatever business reasons, they no longer need those requirements. This means that whatever effort the team may have spent working on these requirements is deemed to have been wasted. This is a (financial) loss to the company.
Kanban solves this problem beautifully with its 2-phase commit feature! It provides for an initial commit point – where the delivery team specifically commits to taking up new work and working on it; and the customer specifically commits that work that has been taken up will typically not be discarded.
The board captures this agreement visually and elegantly. Accordingly, the ‘lead-time clock’ also starts ticking only after the team commits to doing the specific work.
Committing to a Delivery Date
At the other end as well, there can be two issues. On the one hand, the delivery team is not able to precisely estimate when it can deliver a release. All too often, they make an optimistic forecast and then fail to deliver it on the committed date. When the team does complete work, the customer may not be in a position to accept the work due to their “internal IT issues”!
So, instead of being under pressure to committing early, a delivery team can delay the commitment for delivery (a Release) till it is confident of what it can deliver, and also the customer is ready to accept the delivery.
In the board shown above, the delivery team can deliver work into the UAT column at a frequency it is capable of and comfortable with. The customer can take these deliveries for UAT and deployment at a frequency and size that they are comfortable with. Thus, with an agreement between the two sides, the delivery team and the customer can wok in a somewhat loosely coupled manner where each side is able to work smoothly to deliver working software to their end-users.
This aspect of Kanban, in my opinion, can go a long way in smoothing issues in fixed cost, fixed date projects and make for trusting, transparent relationships between the customer and supplier. Of course, this requires a great deal of maturity and understanding on both sides, something that is not easy, especially at the start of a new service relationship. Yet, using a Kanban system to facilitate this process can help establish it far sooner than otherwise.
It helps the delivery team optimize its throughput while minimizing waste (discarded work). It also helps them make commitments they can keep and thus enhance their SLA performance.
On the other hand, it helps customers by giving them maximum time to change their mind about requirements (till the first commit point), thus helping them deal with changing business/ market conditions. At the same time, it helps them prepare for supplier delivery at a pace and cost that is acceptable to the organization.
Using this feature of Kanban can lead to a great deal of reduction of friction between the two sides and make for truly collaborative and mature customer-supplier or business-IT relationships!
Mahesh Singh
Co-founder, Accredited Kanban Trainer/ Coach
