Does Agile work for a website redesign?
On Tuesday 15th March, we launched a redesigned cityam.com. I’ll cover the various parts of the redesign in a future post. Right now, I want to talk about our use of Agile.
Since I joined City A.M. in June 2014, we’ve built and released lots of new features, changes, and fixes. Incremental updates, as opposed to waterfall development, has been the order of the day. And it’s worked well.
In the first week of 2016, we started planning the next stage. We wanted to totally redesign the website, add some new pages, redo the information architecture, and improve the behaviour on mobile and tablet.
Having the opportunity to do a full redesign is an incredible privilege. It’s also very exciting. However, it’s not something that can be released in small chunks. Nor can you begin the core part of the project until you have some direction as to how it’s going to look.
The first challenge we faced was that we couldn’t test anything early on. With the goal of the project being to implement a new design, the bulk of the work was visual. While we could look for things like dead links, missing pages, incorrect metadata or broken share buttons, it wouldn’t have been the best use of QA time. The developers weren’t keen for us to test until the design was fully in place, or we’d just waste time reporting things that were unfinished or had known issues.
The next challenge is that in a fairly small team, a couple of staff have multiple roles. I took the role of project manager; with no formal QA staff, I shared the QA role with the designer. Early on, we needed to get designs completed and approved so we could get them to the development team. But as the project progressed, the developers started to catch up with us while we were still creating designs and specs. In a few cases, we had to rapidly complete designs and specs to enable the developers to continue with the build.
We minimised issues with careful planning, the daily standup meetings, and allocating tasks to individual people for each day. The estimates allowed us to quickly see how long tasks should take to complete and if they overran. We ordered the tasks as some needed to be done before others could begin. We also aligned staff with specific deliverables, and ensured nobody was overbooked on a given day.
Agile mostly worked for us, but a lot of things couldn’t be done in parallel due to the type of work we were doing. We couldn’t QA most of the project until the design was mostly ready. The small team size meant some people had multiple roles, which worked fairly well until we needed to perform QA while also creating designs and specs. However, we managed fairly well in the end.
Originally published at benbarden.wordpress.com on March 20, 2016.
