Recently, in one of our projects for the State Department, we released a very important feature to support the review process of projects they develop around the world with embassies and local institutions.
We were using Scrum and it was working great. As you may know, in Scrum, the user stories are locked within the sprint, and it allows you to focus on those activities without interruptions, and perform regular releases, when the product owner approves them.
However, once we released that new feature, our sprints were often interrupted by stakeholders with new critical requests to improve the work we just had released and make it more efficient for those embassies around the world. This became a huge impediment to make progress on other features of the same project that were also being expected by other stakeholders.
In one of our retrospectives, somebody suggested to change our Agile methodology because Scrum was not obviously working. Then we decided to try Kanban, which is a very old methodology developed by Toyota in the late 1940’s to optimize its engineering processes, and it was designed to deliver materials (or software features) according to the demand of their factory floor (or stakeholders).
Kanban, as opposed to Scrum, is not based on regular fixed length sprints but a continuous flow. You focus on one (or few) user stories at a time and you release them when they are done and approved by the product owner. Priorities evolve very quickly, and you may end switching to an unexpected critical priority, getting it done, and keeping making progress on the other priorities in your list.
A great advantage of Kanban is that it promotes swarming . When your entire team is focused on one thing at a time you tend to make progress faster. Swarming is specially effective for critical issues, those that are very hard to replicate, because you have your entire team analyzing the problem, talking about the possible root cause and defining a strategy to solve it.
Kanban relies on a board (the Kanban board) to communicate capacity, priorities and progress, which ensures transparency throughout the development cycle.
After adopting this methodology, we were able to make progress on new features and also attend the unexpected requests from our client. Since we were using a Kanban board for our sprints, the transition to this methodology was not radical, but it demanded some changes in the way we were doing things:
- Be more disciplined and update the Kanban board in real time to update everybody with progress and priorities.
- Be more disciplined with priorities – focus on what is more important first, don’t get distracted with lower priorities.
- Look ahead and plan ad hoc meetings with the product owner and stakeholders to define new user stories and demonstrate new features ready to be shipped.
- Be more efficient with communications.
- Plan releases more carefully and avoid collisions with release tags.
- Plan deployments to staging environments to be able to test and validate work in progress efficiently (at some point we had a queue of release candidate and hot fix branches awaiting to be tested in the staging environment).
- Groom the backlog more frequently.
- Groom the Kanban more frequently, keep it clean, with fewer cards, and add cards as requirements get done.
- Swarm and peer program more often.
In conclusion, Kanban is allowing us to work more efficiently while the requests of our stakeholders is unpredictable. We are not interrupted anymore because the methodology was specially designed to attend the demands of your clients. However, once we have satisfied all the unexpected requirements and the project is more stable in terms of requests, we will surely switch back to Scrum and so go back to our regular development and releases schedule.
