Agile Delivery in the Travel Beta; from Scrum to Kanban

Delivery Manager

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 Travel Beta 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 BBC Future Media. For the Travel Beta, 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 BBC Homepage, Search and Navigation team, whose portfolio includes BBC Travel News. I'm also the project manager for this year's refresh of the BBC Travel site, which has been a project full of firsts for BBC Future Media, in terms of technologies and continuous deployment. Travel is one of the very first BBC Online projects to employ a new platform that enables continuous delivery, employ Scala and Dynamo 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 Scrum to Kanban 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 BBC 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’d 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 BBC 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 BBC 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 ‘work 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 Homepage, Search, Navigation, Travel News and Location Services, News and Knowledge, BBC Future Media


This entry is now closed for comments.

  • Comment number 5. Posted by Open source scrum tool

    on 13 Sept 2013 10:23

    There are some Similarities between Kanban and Scrum
    1. Prioritization of the Goal: - In both methods Kanban and Scrum Process achieving goal is main Purpose of method .Both method give main Priority to make final product.
    2. Fast and Pure Development:- The Main purpose of both method Kanban and Scrum Methodology is make quick and pure development .Pure development means at deployment time no one change will come from client side.
    3. Transparency Between all team members:- Transparency means no one thing is hidden between all team members regarding development. All matter is display into Open Source Scrum tool like
    There are some Differences between Kanban and Scrum
    1. Kanban based on Process of Development as an ongoing flow while Scrum is based on iteration.
    2. In Scrum Team give commitment to how many work completed in this Sprint is called Scrum Sprint, in kanban not any commitment.
    3. Scrum decide estimation time, Kanban not decide any estimate time.
    4. Scrum required cross functionality of team, Kanban required time to market.

    • This entry is now closed for comments. Number of positive ratings for comment 5: 0
    • This entry is now closed for comments. Number of negative ratings for comment 5: 0
  • Comment number 4. Posted by Dave Hartley

    on 5 Sept 2013 15:49

    The release early, release often approach can be risky in terms of regression testing existing features. Are you leveraging automation at all, or is it all managable through manual regression testing?

    • This entry is now closed for comments. Number of positive ratings for comment 4: 1
    • This entry is now closed for comments. Number of negative ratings for comment 4: 0
  • Comment number 3. Posted by Amanda Dahl

    on 5 Sept 2013 10:09

    We try to take every opportunity to get feedback and use it to shape the product, sometimes this means having more formal audience sessions, and sometimes we just take a phone out to a shopping mall and ask people what they think.

    The Travel team definitely found audience feedback to be crucial to the project. We started getting feedback early in the project using a simple prototype built by the team (all the data was mocked), that allowed our UX and designers to incorporate audience feedback into the behaviour and designs of the site before coding started in earnest. Now that the beta is up and running, we get a steady flow of comments from our audience, which is used by product management to adjust the direction of the development team.

    • This entry is now closed for comments. Number of positive ratings for comment 3: 0
    • This entry is now closed for comments. Number of negative ratings for comment 3: 0
  • Comment number 2. Posted by geordief

    on 5 Sept 2013 08:55

    A bit off topic but what is going on with the BBC website over the past 3 or 4 days (are you at all responsible Amanda?).

    I mean there are a lot of redirects to the mobile website which seems a litttle like going back in time.
    The com site is a little better then the in this respect but quite often I am being served up a mobile site page with big blurry pictures (sport or actuality).

    I am based in (S) Ireland if that makes things any clearer.

    • This entry is now closed for comments. Number of positive ratings for comment 2: 0
    • This entry is now closed for comments. Number of negative ratings for comment 2: 0
  • Comment number 1. Posted by Shakalaka

    on 4 Sept 2013 18:43

    Thank you from the USA for your post! Your article provided a lot of insight into applying Kanban for a applications development team. I'm always looking to improve our agile practices here at my workplace, and we've considered Kanban over Scrum for certain practice groups.

    Receiving useful and frequent audience feedback was crucial to your Kanban process. How did your team facilitate that and other opportunities for user observations?

    • This entry is now closed for comments. Number of positive ratings for comment 1: 0
    • This entry is now closed for comments. Number of negative ratings for comment 1: 0

More Posts