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!))