The import•io dev team is now on the third major iteration since our first launch event. Over these iterations we have been gradually improving our process, our tools, and how we effectively work together to “get stuff done”.
As part of this, for our new release, we have given Jira a bit of an overhaul, and produced a new Kanban board that works better with the process we use.
Import•io is not a simple piece of software (in fact, it is comprised of many complex components which must be fitted together as one for a fully working system), and previous Kanban boards we have used were simply inadequate to capture the process our technical complexity necessitates. Additionally, our development process includes a strong review component. All code changes and features are put through several rigorous investigations by various team members before they are deemed ready to release. Thus we have expanded our Kanban horizontally to take account of these reviews, and to help us manage getting reviews done quickly and effectively.
Our first review phase is a developer review: once work has been completed on an issue (be it a story, bug or other task) it is sent to another member of the dev team for review. The dev review has a list of guidelines that should be checked – is it adequately tested, are there regressions in the existing tests, is it documented in code and if necessary on the wiki, are any changes affecting production systems noted on the release notes and so on. (These all arise from our dev mantra, “Testing, documentation and migration are part of development” – we keep adding things to it).
The second phase of review is QA. Our QA and Data team is responsible for checking that all of the features and fixes work correctly once it has been deployed to our QA environment.
The third phase of review is at two points in the process – sysadmins can reject tickets prior to either QA or production deployment if the release notes or update scripts are missing or do not work.
Any of these three review phases can reject tickets to be sent back to the developer who worked on them for modifications.
Our previous 4-column Kanban, one you would find more traditionally in development teams, successfully captured most of the development stages, but was utterly inadequate for capturing these complex review stages and deployments. By the end of the last release we had some very crazy Jira issue filters running just so review could happen a little bit efficiently. Problems we had included QA not knowing whether an issue was deployed to QA for them to start testing or whether it was committed and merged but not yet deployed; developers could not prioritise issues for review or issues which were reviewed but need more work over new issues; tracking time accurately was virtually impossible; and production deployments weren’t captured at all.
Thus we have expanded our Kanban to 9 columns, which encapsulate every stage of an issue’s life in our process, from creation to deployment. The columns are:
-Sprint Issues – a backlog of issues that are in this sprint / release, but have not yet been marked ready for work
-For Work – issues that are ready to start work and have been assigned to a developer
-Reviewed – issues that have been reviewed and rejected
-In Progress – what developers are currently working on
-For Review – issues that have been completed and ready for developer review
-Ready for QA Release – issues that have had developer review, been accepted, and are now ready to be pushed to the QA environment
-Ready for QA – issues that have been deployed to the QA environment and are now ready for QA
-Ready for Release – issues that QA have assessed and deem ready to release
-Released / Closed – issues that have been deployed to production, or issues that have been closed earlier in the process
The 9/5/5/3-column Kanban
Of course, 9 columns is a huge and completely unnecessary number of states for a developer, QA or sysadmin to be expected to deal with. Thus we have 4 boards running at any one time. These only show select columns, giving an appropriate view for one type of team member.
For example, the dev board shows the For Work, Reviewed, In Progress, For Review, and Ready for QA Release columns. These take account of all the steps a developer needs to worry about – nothing prior (managers assigning them tickets) and nothing after (when it has been handed over to QA). Additionally, once the issue has been taken out of the Ready for QA Release column (the last one the developer sees) they should never have to worry about it again unless it is rejected at a later review stage, at which point it will turn up in their Reviewed column.
The Sysadmin board shows the Reviewed, Ready for QA Release, Ready for QA, Ready for Release and Released columns. This allows the sysadmin to do Ready for QA Release to Ready for QA transitions (once a deployment has been made to QA), and Ready for Release to Released transitions (once a deployment has been made to production). The presence of the Reviewed column allows the sysadmin to reject issues back to the developer who worked on them at any point.
Finally the QA board has the Ready for QA, Reviewed and Ready for Release columns. This means that QA team members can simply drag from the Ready for QA column to either Reviewed, to reject a ticket and send it back to the owner, or Ready for Release, which accepts it for the next production deployment.
We are yet to run our 9-column Kanban in anger during a release, however we have put a lot of hard work into making sure that the tools finally fit the process that we are working with.
by Chris Alexander, Developer