As I previously wrote Metro decided to use the WordPress VIP platform for their CMS and front end, this post will detail how we set about the initial part of the project to give it the best chance of success. Initially it was pretty daunting looking forwards 12 months with the sheer scale of the project and diverse set of stakeholders that would judge its success. During this time the development team would also be switching from Java to PHP, have to learn a new platform and completely change the user interface for all of the people who manage and interact with Metro.co.uk on a daily basis. We had a few whiteboard sessions to try and scope out the high level requirements and each time we “peeled the onion” the board filled up till our brains hurt.
Minimum Learning Product
However the great thing about WordPress is that you can run and install it yourself just as easily as use their on-line offerings. I realised that the biggest knowledge gap that we had was WordPress itself both how to develop themes to how to use it to publish articles. We then made one of the best decisions in my opinion of the whole project and decided that we would use an Amazon AWS instance to self-host WordPress and create blogs.metro.co.uk. This would be a place that we would release real code to throughout most of the project which was able to be used as a prototype that didn’t have the hangups of being the full site but would allow us to learn alongside the content team throughout the project. It took us two weeks to get our first release out and it was pretty damn basic, even with a large amount of on-line resources and a very talented team do not underestimate the complexities of learning a new system and programming language. We managed to get something out and get some really valuable early feedback from the business.
Planning For Success
It was also at this time that we started to think around how best to optimise the front end for the multitude of devices that were starting to grow into a sizeable part of our audience. Responsive design was starting to become a pattern for overcoming these problems and WordPress gave us the ability to focus more on the front end as the core CMS was already built for us. Again we had to learn a completely new way of approaching the front end so we did a phase of development on blogs where we could start to learn by building product. We now needed to move on to the initial planning phase. I think the key learning from this part of the project is to not plan too little and not plan too much. There were some set milestones and we kept it very high level but the visibility that it gave us was very useful especially where external vendors timelines could impact our project. The biggest question was how long the development would take and to be honest we just chose a date so it would be delivered before the end of the calendar year that would give us 14 two week sprints. I think this approach is as good as any at this stage of the project as no matter how much thought and effort you will put into it you will be wildly wrong. All this time I had kept a single dedicated resource on the blogs project who was working on automating the deployment and tweaks based on feedback. The more time that your developers can be writing code during the project the better and automation is the right way to approach this.
100+ Item Detailed Backlogs Are Unmanageable
Now comes for what I perceived to be the biggest waste in the project. We spent a couple of weeks trying to map out all of the requirements in multiple day long meetings and then put everything in a massive backlog. We even did our best to provide story point estimates. However we knew so little about the how and WordPress provided so much functionality out of the box that it was just confusing. Having a backlog with over 100 items on it is unmanageable and as we were going through a steep learning curve requirements quickly became out of date but no one wanted to delete them. The struggle was the business wanting to know exactly what they would get in 10 months time. This fear of letting go of that knowledge is the biggest step in the transition to an agile mindset. By focusing on the high level problems you will solve rather than specific details you can start to bridge this gap. You can understand their fear in the context of multiple late previous development projects deployed by the previous team. Doing it all again I would only focus on details for the next 2-4 weeks with high levels goal for everything beyond that. Prioritise the bits to break down by amount of learning and risk to the project and get on with it.
Don’t Forget Retrospectives
During this part of the process we decided to go with SCRUM as our project management methodology as its iterative approach fits well with traditional project plans. We tweaked our process at the end of almost every iteration until we got it to cause the least amount of pain. Our main learnings were around confusion born out of initially splitting stories into tasks for multiple people that had lack of a clear owner. We solved this by just having story tickets that one person would own at a time. We also struggled with the translation of business requirements through a Business Analyst (BA) to the backlog. The BA was an acting Product Owner and one that lacked the domain knowledge which made his a hard job. If your developers aren’t talking to the business or a domain based Product Owner then they aren’t learning and this lack of knowledge can create confusion. Confusion is a major waste of time in the early stages of a project. It also inhibits learning that is essential to gain momentum through the later stages of the project. This enables developers to make better decisions that can shorten feedback loops which leads to faster development speeds and less waste. This agility come from a common understanding of clear goals alongside validated learning. I now needed to hire some new people and build a team to get through the bulk of this project which I will cover later.
Crossing The Chasm
Gradually as we went through the project the business got more comfortable with reporting based on ability to hit the initially outlined goals and a clear view of where we were within the project plan. Planning for success helped us deliver this project on time and under budget.
Music
Finished off this post listening to the below and free form Jazz and Project Management seemed to flow together.