This is part 4 of the DevOps with VSTS series
The First Way is all about improving work going from left to right, eg. from concept to customer.
As part of this it is important to make work visible, reduce batch size and limit work in progress.
In VSTS the Kanban board can help tremendously to achieve this.
Obviously the communication and collaboration of team members is a very important aspect in DevOps and having the Kanban board visible for everyone can help to open up lines of communication and interdepartmental collaboration.
This post will be shown a potential set up for a Kanban board that has been working very good for me in several DevOps projects.
In this setup the typical flow for a story will be Product Backlog => Sprint Backlog => Active => Deploying => Done done
After the Kanban board has been set up, parts of the Kanban flow can be automated. This is show under Automated Kanban
First browse to the Stories Kanban board and select the gear-icon to make some changes.
In the settings select the Board Columns options and in these options first rename the first column to Product Backlog.
As the name suggests, this column in the Kanban board will contain the entire Product backlog for the team.
Now add a new column next to the Product backlog column and name it Sprint Backlog.
This column will be used for stories that are planned to be picked up in the next sprint.
These sprints are not used like a scrum-like sprint where you have a demo of a Minimum Viable Product.
The concept of a sprint in this Kanban board is to have a rough indiciation for stakeholders what is being worked on in the next couple of weeks and using the historical data to see how much work can typically be done in that timeframe.
Some stakeholders like to have these kind of overviews. Obviously depending on the way the team is working, this column can be added or not.
The next step is to modify the Active column.
The only thing that needs to be modified for this column is enabling Split column into doing and done.
In the Active column the WIP limit is set to 5. VSTS will indicate, by making the column header red, when the WIP for this column exceeds this value.
By monitoring for this indication the team can make sure they don't have too much WIP.
A story will be moved into this column as soon as a developer starts working on it.
The goal of splitting this column into doing and done is so the developer can indicate when the actual coding part, including unit test etc, is done.
After creating a Pull Request for the work and having a successful Gated Build the story can be moved from Active doing into Active done.
Rename the next available column Resolved to Deploying and split this one up into doing and done as well.
After the PR has been completed and the work has been merged into the master branch, the CI Build will trigger the Continuous Delivery.
The goal of the Deploying column is to keep track of this delivery.
The developer can move the story into Deploying doing as soon as the CI build triggers the release.
When the release is completed in all environments, the developer can move the story into Deploying done.
For the last column only change the name to Done done.
Usually during a daily standup meeting the developer moves stories to the Done done column.
By doing this during the standup it's a great motivation for the team to see what work has been released to the customer the previous day.
The reason for this column to be named Done done instead of the usual Done is to make absolutely clear for the team that work should be really done when moved into this column.
So that includes any documentation, training or other tasks.
As shown in all the different steps in the flow, developers need to keep track of their stories and this is a manual process.
In a good DevOps mindset, the more manual steps can be automated, the better it is for overall visibility and lead time.
By using the WorkItem Updater VSTS Extensions, these steps can easily be automated.
When the automated Kanban has been set up, the flow of completing work is partially automated and will look like this:
First update the Gated Build and add a "WorkItem Updater" task as the last build step.
Next add a "WorkItem Updater" task as the last step in the CI build.
And finally, add a "WorkItem Updater" task as the last step of the last environment in the Release template.
With the Kanban board also completely set up, the next thing is to have a look at The Second Way.
What VSTS has to offer to support The Second Way is shown in the next post The Principles of Feedback