When you work on a big CMS based project, it’s not always possible to figure all the details and everything you need to know upfront. In most projects you have a design and you have either a price or a deadline.
This is where we hit the classic argument I stumble into in a lot of companies I’ve worked with. Should you use ‘agile’ and design and plan as you go along, or, use a waterfall approach and figure everything out upfront, so, in theory, you can come up with a better plan and more realistic estimates.
It can be a tough choice to know what’s best at times, there is no definitive road map of how to get from the start line of your project to the end, every project is different, teams change, personalities prefer different approaches, company ethos vary, time, money, quality all rear their ugly heads at times.
Before I get your hopes up by the title of the article, there is no one shop map that I can write down for you now that will make your project succeed.
At the start of any project I think the important thing is to not get to put off by the scale and amount of shit that needs to be done, sometimes projects are BIG. Without a challenge our jobs would be boring – right?
I’ve been in this situation a lot. You sit down at the beginning of a project, maybe you’ve had a few meetings and the sheer quantity of technical talk, services, in-house domain terminology can be very overwhelming. After this, it’s up to you to figure out how it’s going to get done, you have no idea how you’ll do it, but you know it will get done. It takes confidence and a willingness to always keep a project moving forward. Don’t get bogged down in finding a perfect process, there is no right answer.
When you use agile for example, you don’t waste time potentially spec’ing something up that changes or worse yet, never gets used, but if you have a design that defines everything that needs to be done and you have a deadline, not spending a lot of time upfront fully understanding things, means your estimation and project plans may suffer. The principle about estimation is pretty easy.. the more you know, the more accurate you’ll be. If you have huge sub-systems or services that you put in a backlog to worry about in a later sprint, it’s very hard at that point in time to come with an accurate estimate
Your process needs to be open to change; I like a mix and match approach, experiment, don’t be scared to admit something isn’t working, be willing to change. How can you know at the beginning everything you need to do? No one can, if anyone could then your job wouldn’t be as valuable as it is, as everyone would be able to do it. Figuring out unique problems is tough, but why do something that’s easy, pushing the boundaries is where you’ll do your best work. So expect a level of stress.
I personally hate the word ‘agile’ as it seems to mean different things to different people, everyone seems to have their own definition of what ‘agile’ means.
I think the key difference between a lot of projects and a CMS project is that you always have a design and a deadline, so your project can never be fully agile, give up pretending it can be. Every time I’ve followed agile process by the book, the tea velocity has always been slower than when we mixed it up and found what worked best for us as individuals.
This is a controversial statement and I know some people will not agree with it, that’s life. I’m not saying for a second I don’t like agile. I think it works great when you don’t have a clear idea of what you are building up front. Trying to argue that an agile process would never work on a CMS project would be ridiculous.
Stand-ups, sprints, retrospectives, user stories that’s all good shit. If you don’t spend time upfront and define everything though, how can you know when your project has a reasonable chance of being completed? Without shipping you’ve failed.
When you have a paying client.. and let’s be honest that’s most CMS projects, poking, experimenting and using a/b testing to drive the project forward, doesn’t cut it for the people with the cash. They want to know what they are getting for their money. Which is fair. After the main delivery, then analytics’s and pivoting and poking is the best way to make something that resonates with your audience.. but you also need a base line product to start off with.
When you approach a new project, instead of worrying too much about following something to the letter, focus more on finding what works for your team. The best way of doing this is measuring your velocity on estimate, experiment, review, get feedback see how it affects your velocity and then stay on course or change. Don’t stick your head in the sand and carry on regardless just because some book said that’s what you should do.
No author has or will build your project so you need to find your own rules for you to make it.