Taking an agile approach



How we deliver

In this post I’m going to outline the way in which we, as a team, have delivered this project to date as well as highlight some of the processes and tools we’ve utilised and hopefully give a bit more perspective on the scale of some of the tasks this project is trying to overcome.

TfL is a pretty large beast as far as organisations go. So you can imagine, 15 months ago, I was a little apprehensive as to how projects would be run and as to how much desire for change there would be. I was pleasantly surprised to find that TfL Online were leading the rest of the organisation by being the early adopters of modern delivery approaches such as Agile/Scrum, and moving away from delivery approaches such as Waterfall: great!.

In practice, however, being the early adopters of anything is always a testing time. But as the team were up for the challenge and given the responsibility to mould the process to fit the demands of the project, we chose to head down the Agile/Scrum route. Given the desire within the team to not just to deliver a new look and feel but actually tackle the outstanding technical debt we really couldn’t see how we could deliver the project with a Waterfall approach: too many scope items were likely to change and a large proportion of deliver components had not been attempted before.

The new website (currently in Beta) is very much a Greenfield project both in terms of the front end deliverables you see and the back office systems. The frontend stack has changed to utilise modern approaches such as MVC; we have upgraded our CMS; have built an entirely new RESTful API which we live and breath by; and have entirely rewritten the content, delivering all of this on a new cloud-based infrastructure. In the back office this has ultimately meant changing the way the department work in terms of supporting the site: not just in our own first line support but also in our customer contact centres. Many of these topics will be covered in detail by the respective work stream leads later on this blog, so keep an eye out for them.

So the challenge was: how do we deliver these multiple work streams in an Agile approach?

Requirements Gathering / Scope

Capturing requirements for both the consumer and business was a lengthy process, involving internal business workshops, analyzing customer research documentation and carrying out face to face customer interviews with our set of personas.

Ultimately we ended up with a rather lengthy requirements backlog! Prioritising and gaining agreement on phased scope deliverables was then the next challenge, but we got to a point where we were able to split the project into distinct phases.

Our Business Analyst (Leo Kearse – Chelmsford comedian of the year!) then took these and transformed them into top level Epic themes and User Stories. Given that we were using Agile, not Waterfall, we would not be detailing the acceptance criteria for every Epic or Story at this stage, but used the approach to gather acceptance criteria for the stories directly in front of us, always aiming to be at least a few sprints ahead.


Delivery across multiple workstreams

For most of the project the delivery has been stack-related: that’s to say we split the teams to deliver front-end (Design, Web Development, CMS and Content) and back-end (API, Infrastructure). In fact, each of these components has had, for the majority of the project, their own work stream and delivery manager.

Until we launched Beta we utilised this approach as opposed to a product-based one. Having to build the underlying core of the site meant that silo’ing these workstreams to deliver their component enabled us to get to the finishing post faster.  We’ve now moved to a product-based delivery approach with multiple workstreams working in tandem in smaller multidisciplinary teams. To give you an insight into what this means: a typical product will include front-end developers, a designer, tester, usually a couple of developers from the API and a content editor. It seems to be working well, and I think ours is a good example of trying to keep to Agile principles, even changing the delivery approach to better suit the end product. Each product team carries out a morning scrum, updating their relative board on a daily basis.


As a project team we got going straight away with Jira for project delivery. From the get-go, the use of Jira has worked well for us as it’s enabled us to quickly trace back any issues or give clarity to the many stakeholders we have. Also, in terms of a delivery mechanism, it’s allowed us to keep a close eye on the project’s progress: testing both status and workload.

Recently we’ve added in the Greenhopper feature, allowing the product-based teams to have their own delivery boards and for the likes of myself to be able to quickly create sprint progress and burndown reports for management and board reporting.

Within the API workstream, the team have also utilised TFS for detailed task planning (they will be writing about that in another post in more detail). Finally, the tools that often get forgotten: the whiteboard and trusty post-its! Without them I don’t think you’d be reading this blog post right now. We use them mainly to represent tasks and items done in typical scrum boards.

How we can continue to adapt

By its very nature Agile principles dictate change and agility, so for us it works well. Many advocates of Agile reading this will, most likely, state that we’re not using it to its absolute core principles. We know that, but for us it’s still a working process which improves with every sprint. Recently we have moved from two to three weekly sprints and carry out project-wide retrospectives. We perform show-and-tells at the end of each sprint, moving across the department floor in a large posse from team to team. It seems to work well and gives the team members a good opportunity to demo their work.

(This is part 1 of a 2 part post, focusing on how we deliver improvements and the processes we have used. My second post details the other part of delivery: good food and good coffee. So I’ll be highlighting some of our recommendations around central London along with tips on the best coffee plungers (we’ve been through a bunch!))


  1. Hi James

    I read your post with interest. This is not so much a comment as making contact…

    I’m currently working in an agile coaching role at nhs.uk – it sounds like we’re on a very similar journey to yourselves. We’re currently working on a new beta of nhs.uk – transitioning from a ‘traditional’ waterfall way of working to an approach that combines elements of various agile and lean methodologies.

    The similarities don’t end there… we’re also starting to make more extensive use of prototyping and user testing, we’re hosting it all on cloud-based infrastructure, and we’re also building our new service on top of an API that will be made open to the public.

    It’s all very exciting – it looks as though you guys are about six months ahead of us, with your beta already available to the public.

    I’d be really interested in meeting up with you to discuss some of the challenges you’ve faced and the different approaches you’ve taken at TFL – hopefully we can learn some useful stuff from each other. I’m normally based in Leeds but travel regularly to our office in London – if you’d be interested in a meet-up do let me know.

    All the best, and good luck with the beta

    Joe McGrath

  2. Hi James,

    The post is almost a similar reflection of what we have been doing.

    Do we have the part 2 – more interested to know about the improvements and processes used


  3. FAO your webmaster – I’m getting messages from both Firefox and Safari that you have a bad security Certificate. I can’t connect without making a security exception for this URL which might be TFL or someone pretending to be TFL !
    Pasting example below.
    Regards, TB


    This Connection is Untrusted
    You have asked Firefox to connect securely to blog.tfl.gov.uk, but we can’t confirm that your connection is secure.
    Normally, when you try to connect securely, sites will present trusted identification to prove that you are going to the right place. However, this site’s identity can’t be verified.
    What Should I Do?
    If you usually connect to this site without problems, this error could mean that someone is trying to impersonate the site, and you shouldn’t continue.
    blog.tfl.gov.uk uses an invalid security certificate.
    The certificate is only valid for the following names:
    *.wordpress.com, wordpress.com
    (Error code: ssl_error_bad_cert_domain)

    If you understand what’s going on, you can tell Firefox to start trusting this site’s identification. Even if you trust the site, this error could mean that someone is tampering with your connection.

    Don’t add an exception unless you know there’s a good reason why this site doesn’t use trusted identification.

Leave a Reply

Your email address will not be published. Required fields are marked *