The ever-evolving Kanban workflow, with exit criteria at the top of each column
At the end of July 2013, the Travel team in Cardiff breathed a huge sigh of relief as the went live to our audiences and we could finally start to get some feedback on the thing we had been developing for so many months.
Although this felt like the end of a long road, it's actually just the beginning for the new Travel product, because we've taken a development approach that is fairly new to 主播大秀 Future Media. For the , we released a Minimum Viable Product as early as possible and are now iterating on the live site, responding to audience feedback, until we (and our audiences!) think we are ready to replace the current Travel site with our new version.
My name is Amanda Dahl and I'm the Delivery Manager for the 主播大秀 主播大秀page, Search and Navigation team, whose portfolio includes 主播大秀 Travel News. I'm also the project manager for this year's refresh of the 主播大秀 Travel site, which has been a project full of firsts for 主播大秀 Future Media, in terms of technologies and continuous deployment. Travel is one of the very first 主播大秀 Online projects to employ a new platform that enables , employ and DB, and it's also one of the first where we've been encouraged to make live deployments to our audiences little and often, starting far earlier in the project than we would normally. Hence, we have the Travel Beta, where we're experimenting with progressive enhancement to a live site instead of a big-bang launch. I'd like to tell you a bit about the Agile practices we used for the Travel build, especially our switch from to once the project was up and running, which helped us become more efficient and reactive to change.
The Travel product is built by the development team in Cardiff, which is a centre of excellence for all things related to location and maps for 主播大秀 Online. We've been聽using scrum for quite a while, and have refined our agile practices through continuous inspection and adapting. When the Travel project came along, we formed a new team so that we鈥檇 have all the right roles in place from the beginning.
As we were used to working in the confines of scrum, and had a lot of new people in the team, we began by developing the proof-of-concept using two week iterations, where each sprint had a goal, and was bounded by a demo, retrospective and planning session for the next sprint. This worked really well, and allowed the team to start to come together as a group and develop a velocity.
Visible goals make all the difference in maintaining focus
We finished the proof-of-concept in 4 sprints: one to tool up, setting up development practices and frameworks, and 3 sprints to code. The prototype was placed in front of audiences for user testing, and we were able to gather a lot of useful feedback, which was incorporated back into our plans for the MVP. It was around this time that we had a project retrospective for the build of the prototype. We began to understand that scrum had been a good tool for us when forming as a team, but the rigid structure of the iterations created a lot of waste, and the number of actual coding days in a sprint felt like it was dwindling because of all of the time spent planning (we generally took 3-4 hours sprint planning every other week).
Our ruthless MVP, with subsequent iterations all mapped out
We looked at why we were spending so much time in planning and came to a few conclusions.
1. Development planning was starting too early.
2. We were planning everything up front, rather than planning on-demand.
3. We would always plan in a little extra work.
With the sprint structure, there was a lot of pressure on the product owner to prepare stories for the team in advance of their sprint planning. This would often mean that not everything had been prepared by the time the stories went to the development team, and would lead to lengthy discussions during planning which could have been avoided if the stories were prepared in more depth in advance.
We decided it was time to give Kanban a try, as we had seen it work for a few other 主播大秀 teams. There were a number of advantages we could see with moving to Kanban, including:銆�
鈥� Moving from fortnightly all-day planning sessions to planning on-demand as work is pulled across into Development
鈥� Having a closer model of our end-to-end process would help us better to reflect the reality of our workflow from initial concept to live deployment
鈥� A continuous flow would mean an end to the lull that inevitably happens between code-cutoff and the beginning of the next sprint
Before we made the switch from Scrum to Kanban, we talked to a couple of other 主播大秀 teams about what they've learned from their transitions to Kanban. We also sat down as a team and listed out every possible step we go through to get from an idea to a fully-developed feature. We turned each step into a column on our new Kanban board, each marked with the exit criteria required for the column. We soon learned that some columns could be combined to be more efficient/less wasteful, and others needed to be split out to better reflect where queues were forming in our flow. We didn't impose Work in Progress limits at first, because we didn't know where to set them, but this has evolved over time, and now we have a few WIP limits in place where queues were forming.
Constraining our workflow to a single, well-defined Epic in order to keep focus
We've been running the Kanban boards for 7 months now, and just last week we added a new column and split out some swim lanes. It's an ever-adapting process of improving how we reflect our workflow on the board and trying to optimise flow.
Lessons learned
Many of the lessons we learned from the Travel project so far have been general ones related to developing good agile practices, but some are related to the switch from Scrum to Kanban:
1. Good goals are extremely important.
Just because you lose 2-week iterations, doesn't mean you should lose your clear goals.銆� One of the biggest advantages of scrum iterations was that the goal of the sprint was set every 2 weeks and evaluated for completion at the end of the iteration. It meant that everyone had a clear target to focus on, and would tend to pull together around it, where possible. But it also meant that we had to artificially fill a 2-week hole with work if the goal didn't require a whole team pushing towards it for the whole sprint. When we moved to Kanban, we no longer felt confined to the 2 week period, with all of the overhead of scrum rituals every other week, but at the same time we lost sight of the goals to some extent, and had to find other ways to gain a sense of urgency.
2. Make sure your Kanban board reflects the truth of how you work.
It will take a while to model your system 鈥� inspect and adapt your kanban workflow, adding columns and removing them until what you have on your wall board reflects your reality, as much as possible.銆�
3. WIP limits really do help maintain focus.
Throttle the number of epics you allow onto your board 鈥� keep the 鈥榳ork in progress鈥� limit low for the number of features or epics the team is working on at any given time, this will keep everyone focused on the goal at hand and stop them from context-switching. Notice where queues are forming and introduce WIP limits in the column before, to control the build up.
4. Shape and define the work well and half the battle is won.
Once we modelled the steps that a piece of work goes through before it even gets to development, we started to see the development team spending far less time debating during planning sessions, instead they were able to plan on-demand when pulling the next bit of work along the Kanban board. Clear, prioritised goals, with full definition of features and technical architecture will help work flow across the board.
5. Release early, release often - it's harder to do than you think.
Learn to understand when a feature is good enough to get out there for some feedback, and try to lose the fear of releasing -- it can often be more beneficial to get something out the door before you think it's entirely ready (just to get early feedback) than to hold onto it and wait for it to be polished because that feedback might be a major change to the feature anyway. Never underestimate the impact of adopting a new platform or technology on the ability to release production-ready code early in the project.
You need to allow for the uncertainty which comes along with early adoption of new technology, the learning curve it will bring, and factor this into your development approach, ideally coding for functionality before refining it for performance.
Amanda Dahl is a delivery manager in 主播大秀page, Search, Navigation, Travel News and Location Services, News and Knowledge, 主播大秀 Future Media