David Jensen

About six months ago I was sitting in a CTO meeting across DMGT and they were trying to come up with ways that we could improve collaboration across the group. After a few suggestions around wiki based API pages I came up with the idea to run a Hackathon. In my experience the best way to get geeks to know each other is let them build stuff together. This idea stuck and luckily Oliver Parke had sometime on his hands and got the job of organising it all. We were very fortunate to be able to get the Campus London Workspace to hold the event which is a hot bed of startups and geekery. The event was run on the 23rd and 24th of May and included technical people from businesses across DMGT including:

• Metro
• Mail Online
• Euromoney
• dmg::media Sprint Suite / Dev Lab
• Landmark
• Evenbase
• Broadbean
• Wowcher

I was fortunate enough to also be able to participate in Haribo fuelled hacking and below is an overview of what we built and how we approached the whole event.

Vrsus: The future of real time voting

Trying to find a group in the initial hustle of the team forming stage was easier than I thought. My initial idea was something based around real time analytics but this quickly morphed into a real time voting tool to decide which the best cats on the internet are. The great thing about the real time approach was a chance for us to use a load of new technologies. So the dream team that we ended up with consisted of the following:

• Mary Morgan (Euromoney Institutional Investor)
• Frédéric Occédat (Mail Online)
• Panagiotis Albanis (Metro)
• George Old (dmg::media)
• Me (Metro)

Once we had a general direction with regards to online voting we had an hour design session around our flip-board to try to conceptualise the flow through our app and what screens and actions would be necessary. This gave us a decent enough understanding of the requirements to put together a technology stack which consisted of the following tiers:

• Amazon EC2 Ubuntu Instance
• Twitter Bootstrap
• Angular.js
• Socket.io
• Express
• Node.js
• Redis

As we wanted to be real-time and socket based most of the stack chose itself and we thought that Redis would provide a simple way of storing the data and retrieving the post via score. At this stage we started to get down to the detail of building the initial flows around being able to submit images for voting on.

I also started work on setting up the EC2 instance so we could easily pull from GitHub and keep the server running. There were a few things that I need to do in order to get the ports forwarded to HTTP and the Node process running in the background for which I used the following:

• Forever - makes Node.js run as a background process
• Rinetd – allows port forwarding on Linux so Node can run on port 80 and sockets on 8080

Next steps were to get all the pages setup and the logo done which took the rest of the evening.

Coming in the next day first thing we sorted was our Kanban board to get everyone working on the different bits that were required. This worked well through out the day as we finished the following screens.

I also managed to procure the domain name vrsus.me and then added the subdomain you.vrsus.me to it to give it a bit of entertainment. The second day disappeared far to fast and I focused on stripping down the homepage to be nice and simple and also on the create page the ability to preview the image as soon as it has been added using sockets. We decided to against our idea of being able to enter any URL and for us to go and scrape the Open Graph or Twitter tags from it to get the images from the page to just entering a URL of an image.

This proved to be a good idea as it took us the rest of the day just to get the basic flow working, due to Redis not having any relational abilities there it took a bit of time to figure out how to store both the complex hash around the upload as well as the score after voting. The ability for the list to change order in real time also came right down to the wire and although there isn’t a fancy animation the list view is socket based and will change order when votes come in which I think adds a lot to the application.

It was then time to give a presentation of how we had approached everything and I had managed to knock up the below in Prezi.

We won the ‘Most Technically Impressive’ category overall.

Future Ideas

If we were to have some more time to develop this application into something more fully fledged I think these are the area’s that we would focus on.

• Ability to post any url and vote on it
• Social integrations
• Ability to put sponsored posts in it
• General responsive and cross browser performance
• Improvements to the animation
• Tracking

I think that Vrsus could be utilised across DMGT in many different ways apart from just showing the best cat beards on the internet. Having a real time voting system that people could submit content to that allowed the best to rise to the top based on user interaction would be a valuable asset in my opinion.

If you are interested in having a look at the code you can see it on GitHub and the url you.vrsus.me is still live and will be so for the next month or so.

Vrsus: “The future of real time voting” – DMGT Hackathon 2013 - Music To Write Code To - Writing code and listening to music go together like food and wine. I am sure I will also ramble about all sorts of other things.

I was very fortunate to attend the 2013 WordPress VIP Developer conference in Napa Valley this year. It was great to meet all of the people who use WordPress at scale across the media space and the lovely people behind it all at Automattic. Also crazy to see that the average development team size for someone on WordPress VIP is 2-3, considering many of these sites are serving millions of uniques a day that is incredibly lean.

I was asked to give a lightening talk (less than 5 minutes) on a subject and I decided I would give a quick overview of how we have approached building Swipe into metro.co.uk. This seemed to go down quite well though qz.com were on after me and what they have done with their front end is even more impressive. I thought it would be a nice idea to put my slide deck up somewhere for viewing.

One of the other talks the previous day was by Yuri Victor on why the Washington Post uses WordPress and if you haven’t already seem it then it is definitely worth the visit even for the typography alone.

Other great notes from the few days were to use the following for WordPress debugging.

• Debug Bar
• Debug Bar Console
• Debug Bar Cron

Also use Grunt to automate the use of these two libraries for image optimisation.

• jpegoptim
• optipng

Generating fonts to help reduce images/sprites can be a good idea or just use Genericons which have been done for you. Also I found out that script tags on a page are completely blocking.

Changing the Paradigm with Swipe - Music To Write Code To - Writing code and listening to music go together like food and wine. I am sure I will also ramble about all sorts of other things.

At Metro our development project has multiple product owners who each have their own backlog and want to prioritise them separately using Greenhopper’s drag and drop interface. We didn’t want to create multiple projects to enable this and Greenhopper’s multiple backlogs support for a single project is something that had previously eluded me. Ade Shokoya who was our business analyst came up with the idea of creating an additional Kanban rapid board with product owner based swimlanes to achieve this. We now have one Kanban rapid board to manage the product owner backlogs and one to manage development priorities. They share a column which allow tasks to flow easily from one to the other.

We use components within our Jira project to categorise tasks by the business area and product owner that they deliver value for. Each component allows you to setup a default owner and this ensures that they are notified when any tickets are added or amended. We created an additional Kanban rapid board specifically for backlog management and added “Backlog”, “To Do” and “Scheduled for Development” columns to this. We then enabled swimlanes based on components so each of the individual backlogs can be prioritised separately within these. We also utilise quick filters based on component to allow each product owner to only see their tickets on the rapid board. As the filters are URL based this allows each product owner to have a browser bookmark to take them straight to their backlog.

Setup Swimlanes per Component

Setup Quick Filter per Component

Greenhopper Multiple Backlogs Kanban Rapid Board with Swimlanes and Quick Filters

Getting the business engaged with development process and priorities in Jira is a long term project of mine (as otherwise I am the only person who manages the board). The best way that I have found to do this is hold specific product owner stand ups twice a week where we have a look at the work in progress and discuss what the priorities are for the items about to move into the development stream. We have this around the TV that has our development Kanban rapid board displayed on it and can quickly switch between that and the backlog view. This allows each of the product owners to get a good view of overall priorities and where their requests fit into that. They also see how the process works and have an opportunity to provide feedback. This is complimented by a meeting every other week where we look at how each idea is delivering value based on performance data and then decide whether we do more or less of this based on our overall strategy.

Having multiple Rapid Boards for a more complicated flow that keeps each of the boards simple is one of the best moves that we have made. We are also now using a separate board to tightly manage our testing and release process as we have multiple environments and stages that overcomplicate the main board. Greenhopper has been really good at adding new features and streamlining their existing ones to provide a great way of managing the different stages of the project in a single dashboard.

Metro.co.uk Greenhopper Kanban Rapid Board Dev Board

Background

I have been using the Atlassian stack including Jira and Greenhopper to manage multiple Agile projects using its Scrum templates over the last three years. The great thing about Jira (and at times the most frustrating thing) is that it is pretty much infinitely configurable and Greenhopper gives a great drag and drop interface for Scrum and Kanban setups. Personally I don’t have the time to manage both an online system and a paper based post it system so we moved everything into Jira and got a 42″ television which is used for displaying boards during standups and as an information radiator during the day.

During the minimum viable product (MVP) phase of the metro.co.uk CMS migration we had a nice simple setup of Greenhopper utilising its Scrum template with a dedicated Business Analyst (BA) who managed the backlog. However he was a project resource and his contract was about to come to an end, we had also shifted from using Scurm to using Kanban but were initially struggling with the flow from the large backlog left over from the project.

Music to write this Code to

Treasure Fingers once again giving away a sparkling mix that makes you wish it was summer all year round.

How to use Atlassian Jira with Greenhopper to manage multiple Backlogs - Music To Write Code To - Writing code and listening to music go together like food and wine. I am sure I will also ramble about all sorts of other things.

The initial phase of the responsive redesign of metro.co.uk was a project that spanned 14 two weeks sprints. At the end of the sprint cycles we released a minimum viable product which we had to rapidly iterate to fill in some gaps that didn’t quite make the last mad dash. During this process we migrated from Scrum to Kanban as the pressure to get things fixed was as constant as the changing priority of requirements. Having been through this process I am not sure that I could go back to Sprints for the business as usual part of a project. However we have learnt a lot over the last few months and I thought I would share my lessons learnt in case you are also interested in making this transition.

Scrum to Kanban

1. In order to release as often as possible, focus on smoke tests and automation of deployments between environments. Usually this requires a pretty complex setup that will take some time to find the optimal process.
2. Use feature branches to allow small changes to be encapsulated and tested on each environment. This can take some getting used to but the pay off is well worth it.
3. Don’t under estimate the power of a Dev Ops culture even if you don’t have a specific person for this role empowering both developers and testers to have the time to set everything up correctly will save you time and errors in the future.
4. Break things down to the smallest possible developments based on the feedback that they can provide to avoid blockages. This doesn’t mean large projects can’t be done but should be packaged in multiple small releases.
5. Limit work in progress (WIP) as well as items on the backlog. A large backlog is usually the most inefficient part of this process. No longer can it be the dumping ground for ground for random ideas. If it isn’t done within three months I auto delete and see what people complain about.
6. Hold product performance meetings rather than sprint planning. Bring feedback and measurements and invite both business and development resources and let the data win the arguments. Setting the measurements up takes a while but they payoff of everyone looking at the right metrics is worth it. You will also need a solid goal to be aiming at.
7. Much more conversation needed on a regular basis, we now hold product owner stand ups twice a week as talking every other week isn’t enough when you are moving that fast.
8. Talk about problems define small solutions to provide learning then iterate.
9. Whiteboards are your best friend. All of the walls in our new office are whiteboards and it really helps quick brainstorms. Also allows you to leave complex problems in visible place to revisit over time until solutions become clear.
10. Don’t forget retrospectives.

Conclusion

Now that we have been running with Kanban for over three months it is amazing how much faster the team has become. Breaking things down into small pieces is probably the biggest skill that is needed to keep the process efficient. Also ensuring that the business are engaged throughout the process has taken some time but the benefit is huge. Agility has also increased as now when we find an issue or discover a new key piece of information you are able to act on it straight away rather than waiting until the next planning meeting. If you are interested in reading in more detail about Scrum vs Kanban then I highly recommend reading Scrum vs Kanban by Henrik Kniberg.

Music to Read this Post to

Silicone Soul always bringing the heat and their Darkroom Dubs compilations are a great example of that.

Scrum to Kanban – 10 Lessons learnt from migrating - Music To Write Code To - Writing code and listening to music go together like food and wine. I am sure I will also ramble about all sorts of other things.

I spent this morning running the PageSpeed Insights tool in Google Chrome over this website and it came back with some good tips on how to speed up WordPress Apache to make this site run faster. I thought I would share how I approached making the recommended changes below.

The first critical issue that it threw up was to turn KeepAlive On, this means that Apache keeps the session alive to transfer multiples files. This reduces the latency as each new request for the multiple files that makes up a web page don’t have the overhead of opening and closing a connection. I found this great overview of the options here which is worth reading if you want more details.

I then made the following changes to my /etc/httpd/conf/httpd.conf

#
# KeepAlive: Whether or not to allow persistent connections (more than
# one request per connection). Set to "Off" to deactivate.
#
KeepAlive On

#
# MaxKeepAliveRequests: The maximum number of requests to allow
# during a persistent connection. Set to 0 to allow an unlimited amount.
# We recommend you leave this number high, for maximum performance.
#
MaxKeepAliveRequests 50

#
# KeepAliveTimeout: Number of seconds to wait for the next request from the
# same client on the same connection.
#
KeepAliveTimeout 3

The second critical issue was a lack of compression so I needed to turn compression on and then ensure that all of the file types that benefit from compression were enabled with mod_deflate.

#
# AddEncoding allows you to have certain browsers uncompress
# information on the fly. Note: Not all browsers support this.
# Despite the name similarity, the following Add* directives have nothing
# to do with the FancyIndexing customization directives above.
#
AddEncoding x-compress .Z
AddEncoding x-gzip .gz .tgz

<FilesMatch "\.(php|css|html?|xml|txt|js|pl)$">
SetOutputFilter DEFLATE
</FilesMatch>

The next issue that it identified was a lack of browser caching so I updated my .htaccess file to ensure that files that could be cached by the browser would be as recommended in this post.

## EXPIRES CACHING ##

ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType text/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 2 days"

## EXPIRES CACHING ##

Finally having spent some time on the Google PageSpeed website I saw they had developed the mod_pagespeed Apache module which combines a whole load of Apache web server performance best practices into a single install.

wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-stable_current_i386.rpm
sudo rpm -U mod-pagespeed-*.rpm

Finally I reran PageSpeed Insights and got an overall PageSpeed Score of 94 (out of 100) which was great for a couple of hours works to really speed up WordPress Apache.

Music to Write this Code to

Blackalicious – Alphabet Aerobics is one of those songs that just gets faster and hypes you up hopefully just like you have done to your webserver.

How to speed up WordPress Apache - Music To Write Code To - Writing code and listening to music go together like food and wine. I am sure I will also ramble about all sorts of other things.

This is the second time that I have been through the process of writing a story of how I think that the company I work for should evolve over the next 18 months. I previously wrote about how I thought this would work out for Metro and it is amazing how much of that has actually happened. This story was written at a DMGT level with a focus on how we solve the innovation challenges that a corporation of this size faces. My main premise is that we already have a lot of good ideas being generated but we are not so good at knowing which ones to invest time and money into. Business idea validation usually seems to take a back seat to idea generation but I think that this is the wrong way of looking things. These opinions and ideas are purely mine and don’t reflect the views of anyone at Metro or DMGT. It will be interesting to see how this story plays out over the next 18 months as I have a lot less influence at this level than I did with Metro’s. I have really come to respect story telling as a very powerful way to drive business change, Steve Denning explains this very well in the article “The science behind story telling“. The setting for the below is an induction day for a set of new recruits, the below is only my part of the story of which there were six parts.

My story to come

As you have just heard A+ Media’s digital revenue has recently surpassed their newspaper revenue. This rapid evolution was largely driven by a change in organisational thinking. The focus moved from opinion based decision making to a factual based iterative approach. This increased the speed of innovation and decreased the costs and risks of trying new things.

The process was a disruptive one to the wider business but it was recognised that it was better to disrupt ourselves than be disrupted. Management started by setting goals that focused on digital revenue across the whole of A+ Media. They then used a data driven model to validate a large number of ideas around new digital revenue opportunities.

For each revenue opportunity they formed a customer based hypothesis that they used their considerable client contacts and existing audience to quickly validate. Next decisions were then based on this real world feedback. A+ Media have used this way thinking to foster a culture of constant innovation from iterative learning. The knowledge that data will win any argument over ego was a critical factor in mobilising the whole of A+ Media behind their digital goals.

So I guess you are thinking what does this have to do with me on your induction day? Well you will be taught these techniques and they will help you to shape both the future of A+ Media and each of your respective organisations. This process is called Lean Friday’s and there is a dedicated team who organise and facilitate these. They will be in contact soon, as each of you will be involved in at least one of these sessions a quarter.

Lean Fridays are our idea validation process where we take a cross functional group of people and get them to validate our ideas around digital revenue opportunities. In a competition at the end of every month validated ideas are chosen for further data driven development. The team that validated the idea is also given the opportunity to continue to be involved.

Idea generation and selection is taken care of by a market based approach. Every employee is given the ability to submit an idea in Salesforce for consideration. They are also given a set amount of A+ currency to invest in ideas that they think will provide the most amount of value. Ideas are ranked in Salesforce based on the amount of investment in them. When a successfully validated idea is turned into revenue then a small percentage of profit is given back to both the initial creator and investors of the idea. They are also given additional A+ currency to invest again. An example of this was:

“Stephan Fowler a developer from Metro who came up with the idea to create a marketplace for commercial content creation. Internal knowledge and testing validated how to structure this so editorial would be correctly incentivised and clients validated how much and what they would be willing to pay in trail runs. We then quickly developed an internal prototype using open source software. Over time this was refined and then finally released into the wider marketplace. It has since created over £10 million of profit and Stephan received £10,000 for this.”

Highly visible examples like this have ensured that everyone is interested in the generation and validation of ideas and put constant innovation at the heart of our culture. Good luck with your ideas and investments if you would like to know any more about the process please don’t hesitate to ask.

Conclusion

Waste is a huge problem for large modern organisations, usually business models are optimised over time to reduce that waste. I believe that by ensuring the right validation of ideas we can reduce the waste that occurs at the earliest stages of new business model generation. Lean Friday’s would be an approach that I believe that would work to do business idea validation at scale. I also believe that they would solve one of the other problems that large organisations have which is communication. By bringing a group of people together around a common problem you can quickly learn how other parts of a large business work and gain some insight and knowledge which is very valuable. Technical companies have hack days for this very reason and people like Facebook and Atlassian are already harnessing these approaches to massive business benefit.

Music to Read this Post to

Claude Von-Stroke showing a different side on this Ibiza mix which is more 9am by the pool than 3am in the club.

Lean Fridays: Business idea validation done at scale - Music To Write Code To - Writing code and listening to music go together like food and wine. I am sure I will also ramble about all sorts of other things.

Another challenge that is faced early in projects is how to turn the talented group of individuals assembled into a high performing team. With the ambitious goals of the project laid out it was essential that this was completed as early as possible. The best way I have found to do this is set a goal based around a set of restrictions that the team can only solve by working together. For the Metro WordPress project it was getting our responsive blogs site live for use by editors and end users behind Akamai at the end of our third sprint. I think that the third sprint was a good time to do this as the team already had a basic understanding of the domain, technology, each other and process. I also took some time off right at the deadline as without me leading the project the team would need to work together and communicate more with each other. You need to empower individuals and if you are a leading figure by removing yourself you create the space for others to step up.

Self Organisation

You obviously also need motivated individuals, the right rewards and a clear achievable goal but when I came back in after the deadline you could almost feel the difference. The team had managed to deploy all the code but not quite configure Akamai correctly to deal with cached User Agents for the mobile site. They had self organised to get a far as they did and only an unknown consequence of a design decision stopped them from meeting the target. However the learning from this mistake ensured we made the right choice later in the project and avoided User Agent detection in favour of using widths. The restriction of time, platforms and approach ensured that they had a common frame of reference to approach the problem and organise around.

Emergent Design and Technical Debt

The team had also hacked a lot of things to meet the deadline which they were now all passionately complaining about. I am a big fan of emergent design where you let the pain points of a project show themselves before fixing. This was a great example of that and I then let the team use the rest of the week to clean up the technical debt and you could see that sealed the team’s formation. If you let talented passionate people speak their mind together about constraints and then give them time to fix those issues you get what you actually need not what one person views as the best approach. However if you don’t give the team time to clear the technical debt you will loose respect and all of the good work. They also wont feel empowered to make their own decisions in the future.

Order comes out of Chaos

Order comes out of chaos rather than overly thought order descending into chaos. Wrong assumptions made before problems were fully comprehended have derailed many other projects I have been involved in. Leaving all decisions to the last possible point when the maximum amount of learning has been completed is always a good idea. When people have a clear mental model of the problem rather than an out of date one from previous projects that they assume to be valid. As I mentioned earlier you need to insert chaos at the right time in the project as if it is done too early then you can lose more than you gain.

High Performing Team

To see the passion from everyone having made some compromises for a short term goal and their insistence that this could not continue I knew that this group of people was now a team. The learning that they had from self organising around a clear goal and solidarity against the technical debt showed they were well on their way to be a high performing team.

Key Learnings

• Constraints help creativity.
• Clear goals help people self organise.
• Removing a leader for a short period can help self organisation.
• Allowing pain points to surface due to constraints makes people passionate.
• Passionate people perform better if you then empower them by listening to their opinions and fix the technical debt.
• The group needs a certain level of maturity before trying this approach.

Music to Read this Post to

Guy Gerber absolutely smashing it in his own special way on this melodic techno mix.

How I helped a group of technical people form a high performing team - Music To Write Code To - Writing code and listening to music go together like food and wine. I am sure I will also ramble about all sorts of other things.

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.

Planning for success when agile and traditional methodologies collide - Music To Write Code To - Writing code and listening to music go together like food and wine. I am sure I will also ramble about all sorts of other things.

Over the past few years error pages of the Internet have got a lot more interesting. Page Not Found know as HTTP 404 has been at the front of this movement. Rather than the more staid errors of old developers have started to inject their own special kind of humour into them. I was really interested In the psychology behind these pages, I then read “Your Logo Is Making Me Sick” which explains that when people are angry with your brand the last thing you want to do is have your logo part of that negative experience.

Every product will at some point encounter a critical error and/or force the user to wait. Don’t let those moments become synonymous with your brand.

The other thing to note is the state of the project that this was developed at. We were aiming for a very aggressive MVP release date and the whole team were really pushing hard for this. We knew we wouldn’t get it all right straight away with over 300k articles to migrate from multiple previous CMS’s and a completely new responsive front end. I had spent the day browsing 33 Animals Who Are Extremely Disappointed In You to prepare myself for possible miss of the release date as the project was on a knife edge. Then it struck me for all those people that wouldn’t quite make it to where they wanted why not give them something funny to look at to leave them with a slightly confused but happy feeling. Image rights can be a bit of a nightmare but Metro has some great content and having had a chat with the content team the dancing polar bear was selected.

The Sunday before the project as due to go live the team were in the office in a slightly silly mood and I happened to skate in that day to blow a few cobwebs out. GIMP came out and the dancing polar bear was born. He was later pimped out with a 404 chain just to complete the effect. I distinctly remember one of my team going surely this can’t be the most important thing we have to work on right now. However when you have been banging your head against big problems for a week a break and something to take your mind off what you are doing is exactly what is needed.

The day we went live we were monitoring 404 errors and suddenly saw our 404 page shoot to the top of our most read pages. We realised that it was being done on purpose to share on Twitter and from then on a legend was born. To get #1 on Buzzfeed’s “The 28 Best Error Pages On The Internet” was just the icing on the cake.

Thanks to @stephanfowler for the GIMP skills.

Music to Read this Post to

LINDSTRØM & TODD TERJE – Lanzarote is such a banging tune it just keeps on building and the slightly silly vocal makes me laugh a little like our polar bear friend.

The story behind Metro’s number one entry in Buzzfeed’s best error pages on the Internet - Music To Write Code To - Writing code and listening to music go together like food and wine. I am sure I will also ramble about all sorts of other things.

Metro’s existing CMS “WPS”

When I joined Metro they were using a custom CMS that used GWT for the admin screens which wrote to a CRX content repository and then used Cocoon to pull fragments of XML out and parse them into HTML for the  front end via ESI tags on Akamai‘s content delivery network (CDN). It was an incredibly complicated system that had started with big promises about the “future of semantic publishing” and was originally planned to be rolled out across Associated Newspapers as the default CMS. However the internal department which was in charge of development became Mail Online, the people who wrote their dissertation on it left the company and the project was left to myself and the team at Metro to stabilise and maintain.

During this time it was taking on average three months to get a developer up to speed with the platform and our ability to move quickly was pretty much non existent. The implementation of CRX had also been setup by people who didn’t really understand it’s inner workings properly. Having spent most of a holiday I had on the phone trying to stabilise the system I came back with the knowledge that things had to change. At the same time my boss Jamie Walters had used WordPress.com to setup a blog that had a mobile, tablet and desktop version in less than 3o minutes.

CMS Selection Process

We then went into a large scale look at all of the publishing based CMS systems and quickly realised that spending a lot of money to tie yourself into a vendor who’s main goal is to make money from you by making you upgrade every few years would not be the way forward. As part of that process we saw that Automattic the company behind WordPress.com had a VIP service that allowed you to utilise the might of their WordPress.com infrastructure  as a platform for publishing. This would allow the Metro development to focus on the user experience of news and be able to leverage all of the open source knowledge around the subject.

WordPress VIP’s pricing structure was also very nice and simple with unlimited traffic, bandwidth and storage and a set charge additional charge depending on the support tier you require. They also helped out with our content migration and we ended up going with a high level of support throughout our build and then dropped it down once we had gone live. They also run six data centres in active-active mode so you don’t need to worry about disaster recovery. Automatticians are a very dedicated bunch and are distributed throughout the world which really helps when working on large scale projects such as this. They also have the ability to change the WordPress platform to ensure that you can achieve your goals. One thing to consider is that they check every line of code before it goes up on their platform both before your code goes live and once it is up and running.

WordPress is also constantly being updated by the large worldwide community it has behind it and a lot of the commodity items that a websites needs are taken care of for you. It had to go to the investment board twice but just before the second time CRX melted down and for five days straight we could only run it for 20 minutes out of every hour to update our Akamai cache and keep the site looking somewhat fresh. This couldn’t have come at a better time in the decision making process and we got the sign off we needed.

Things worth considering when switching to WordPress VIP

We are now two months post our go live date and I can safely say that utilising the WordPress VIP platform has been a really positive experience. There are a few things that are worth bearing in mind however.

• WordPress.com does not support the www subdomain so we are now metro.co.uk rather than www.metro.co.uk.
• Initial Automattic code review can take 6-8 weeks to fully complete.
• Every time you make a change to your theme it needs to be approved by an Automattician (most completed within an hour and you can request faster in an emergency).
• WordPress.com does not support the passing of query strings around the application due to their caching setup.
• It is pretty hard to get your local and test builds similar to WordPress.com so get your code on their servers as soon as possible.
• The WordPress platform changes pretty much every day which has great benefits but you need to stay on top of updates.
• As most people who build WordPress sites do it for multiple clients it took us a long time to find someone to join on a permanent basis with the right level of skill.
• If you have any resource managing your servers currently then they will be less busy.
• WordPress VIP also offer self hosted help if you already have everything setup.

For how we approached the project from a project management point of view read some more here.

Links:

• WordPress VIP Metro Migration
• WP Daily: UK’S 3RD LARGEST NEWSPAPER GOES WORDPRESS VIP 
• Metro Responsive Website Launch now with added Swipe

Music to Read this Post to

Four Tet at his best with a great building track of blissed out beats.

Why Metro chose WordPress VIP for their CMS and front end - Music To Write Code To - Writing code and listening to music go together like food and wine. I am sure I will also ramble about all sorts of other things.