Hey, agile developers: the CMS is a different product from the website

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.

Filed under: Development, agile, cms

Always wrong is doing it right

On an agile project—and is there another kind these days?—being wrong is no big deal. It’s usual, even. You might as well get used to it. You’re wrong because:

• You don’t have all the information to hand at the outset.
• You don’t have time to wait for all the information you need.
• If you waited, the requirements would change anyway.
• There’s usually more than one way to tackle a problem, and the best way often isn’t clear up front.
• You might know the right thing to do, but have to descope or hack it in order to hit a deadline.

That last one is after all a key aspect of agile: the trade-off you make to achieve hard deadlines is to jettison functionality. Leaving you wrong by design, as often as not.

So you’re wrong. Then you iterate, and with each iteration you’re less wrong. But you probably never eliminate all the wrongness. The requirements change again, or it’s simply not cost effective or a good use of your time to go back over something that’s wrong but good enough.

A great current example is the iPad. It’s so full of wrongness, missing so much functionality that you might naively think it couldn’t possibly go to market yet. Want to transfer a document from one app to another? Want to style some text in any app whatsoever apart from Pages? etc. It’s funny that Apple explicitly rule out “beta” apps appearing in their App Store; well, unless you consider all apps are always beta, because they’re always wrong. But actually the iPad has more awesomeness than wrongness, and the former more than makes up for the latter. They’ll sort the bad stuff out later, probably.

Which leaves this problem: it’s human nature to dislike being wrong. Even worse to be told so. We all know developers can be a, erm, stubborn bunch convinced of their own innate correctness, who find it harder than most. For sure I count myself in that camp.

I wonder whether this isn’t one of the harder virtues of the agile developer: to be able to live with being always wrong, and not mind having it pointed out where necessary.

PS. Yes, sure, you can also be wrong just because you’re, well, wrong. Because you’re a dumb-ass and clueless. otoh you might get lucky with your project and be 100% cast iron right from end to end. So I should really have titled this post “If you’re not always wrong you’re probably not doing it right”.

Filed under: Development, agile