How to use Atlassian Jira with Greenhopper to manage multiple Backlogs

April 1, 2013 | Comment

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.

Scrum to Kanban – 10 Lessons learnt from migrating

March 14, 2013 | 4 comments

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

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.
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.
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.
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.
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.
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.
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.
Talk about problems define small solutions to provide learning then iterate.
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.
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.

How to speed up WordPress Apache

March 12, 2013 | Comment

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.

Lean Fridays: Business idea validation done at scale

March 8, 2013 | Comment

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.

Claude VonStroke ‘3 Days lost in Ibiza’ – Recorded for We Love by We Love Space on Mixcloud

How I helped a group of technical people form a high performing team

February 24, 2013 | Comment

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 techno mix.

Planning for success when agile and traditional methodologies collide

February 16, 2013 |

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.

The story behind Metro’s number one entry in Buzzfeed’s best error pages on the Internet

February 12, 2013 | Comment

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.

Why Metro chose WordPress VIP for their CMS and front end

February 9, 2013 | 8 comments

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:

Music to Read this Post to

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

Metro Responsive Website Launch now with added Swipe

November 18, 2012 | 3 comments

Over the past 12 months I have been working with an amazing team of people at Metro the largest free daily newspaper in the world to migrate their existing bespoke CMS and move them to WordPress with hosting provided by WordPress VIP. The press were invited in this week and the management team started to give them a flavour of what is to come in early December. I thought it would be nice to get some quotes out of these articles and put them here so I can remember the calm before the Metro responsive storm.

UPDATE: Swipe was removed from metro.co.uk in October 2013 due to these reasons.

The Metro.co.uk site will become the first UK newspaper destination to allow mobile and tablet users to swipe between articles when it launches

Metro Ramps up Mobile Drive, Marketing Week

Linda Grant, the managing director at Metro, said the newspaper was the “original mobile product” when it launched targeting London Underground commuters in 1999.

Metro to launch new website, Android app and Kindle Fire edition, The Guardian

“We’ve taken app functionality and applied to browser product,” – Jamie Walters, Product Development Director, Metro

Metro Announces Mobile First Strategy and Responsive Site, Journalism.co.uk

“We looked at Drupal and other platforms, but WordPress met our needs,” said Walters. “We no longer have to maintain back end systems.”

Metro Newspapers To Address “Smart Boredom” With Swiping, Techweek Europe

Free urban newspaper brand Metro revealed this week it is experimenting with new ad formats such as mobile payments and full-page interstitials between swipes on its new website as it looks to boost the utility of the ads it presents its readers.

Newspapers finally living up to digital first aspirations, Marketing Week

UPDATE 24.02.2013: The Metro responsive WordPress project was launched on time and under budget and here are more details about how we approached this from a project management point of view. This was also be the first national UK Newspaper with a responsive site and the first for the swipe interaction across all devices that support it.

Music to Read This to

Little People is a friend of mine called Laurent Clerc and he puts out amazing downtempo music. This mix is what he put together for his wife and distributed to all the guests of his wedding.

WordPress Multisite Change Domain Name of Subsite using SQL

November 18, 2012 | 2 comments

I have been working on migrating a website I did for a friend a while ago from an old ASP.NET application I built to my WordPress Amazon EC2 Instance over the last few weekends as the old server we were using for hosting is being retired. I have been working on a temporary domain whilst getting the site up and running using the subdomain dev.cafeontherye.co.uk and now it is time to migrate to www.cafeontherye.co.uk so I thought I would put the steps up here to update WordPress Multisite change Domain name.

First step was to update the DNS settings and change the IP of www to point to the IP address of my WordPress instance on Amazon EC2. Whilst waiting for this to propagate I needed to update all of the settings in WordPress to point to the new domain. I use the WordPress MU Domain Mapping plugin for this so navigated to my Network Admin > Settings > Domains and added a new entry to point to www and made it the primary for that domain. I then logged into MySQL workbench and ran the following.

update [dbname].[wp_site_id]_options
   set option_value = replace(option_value, '[oldsiteurl]','[newsiteurl]');
update [dbname].[wp_site_id]_posts
   set post_content = replace(post_content, '[oldsiteurl]','[newsiteurl]');
update [dbname].[wp_site_id]_posts
   set guid = replace(guid, '[oldsiteurl]','[newsiteurl]');
update [dbname].[wp_site_id]_postmeta
set meta_value = replace(meta_value, '[oldsiteurl]','[newsiteurl]');

Waited around four hours for everything to propagate and Cafe On The Rye lives again in it’s new responsive WordPress form.

Music To Write This Code To

Now the weather is getting colder there is nothing better to warm the soul than Fake Blood mixing up of old tunes sampled in classic Hip Hop tracks.