So you’re working on a big new website development, overhauling all the functionality and delivering a better user experience to your site visitors. Naturally you’re using an agile development methodology. It’s going to rock.
In this scenario, it’s very easy to think of the CMS as merely a component of your solution. Probably there’s a little box for it on your high-level architecture diagram.
But really, the CMS is a distinct product (in the agile sense). It has a different set of customers, ie. the staff who will be updating the site content. They have different goals from your site visitors.
That means the CMS needs its own agile track in your development process. Most importantly, CMS development (or, more likely, customisation) must have its own customer representative, who represents the product stakeholders (the staff), and who drives development priorities.
If you treat it just as a component, then chances are your developers will implicitly be taking this role on themselves. They will be setting priorities and making decisions on behalf of stakeholders who they simply don’t represent and quite possibly haven’t even spoken to. This is a recipe for bad product.
How will you know if you’ve succeeded? Again, you should apply many of those same techniques that you’d use to optimise your site to ensuring that your CMS is also great. A/B testing might be tricky given the likely small size of the customer base. But you should definitely have a clear idea about success metrics and how to measure against them. Whatever methods you’re using to evaluate the site, it’s worth thinking about whether and how they can apply to the CMS.
It’s puzzling to me that there are some developers who seem to think that this is a waste of time. I bumped into one on Twitter recently. But over the last decade in particular, developers have benefited enormously from better tools and processes, making them way more productive and happier with their work [yeah, “citation needed”, but I believe it’s true]. Why would you expect that you can dump crappy tools on other staff and still expect them to do the best possible job?
This post based on a true story.