A separate team supports live Drupal websites

For the past half a year we were working on setting up an organised and structured support team in Droptica. I can now happily say that our Drupal support is top notch. In this post, I will explore a bit why we created a separate support team. 

Droptica started as a typical software development company, with a group of drupal developers, who were working on the tasks at hand. This could be a new website for a client or a new feature for an existing website. As most smaller Drupal agencies, we managed ourselves as best as we could: doing what was the most important or urgent first. This however only worked this far.

Growth and changes

Many changes have occurred both on the Drupal market and in Droptica in the last 2 years.

Drupal projects have grown. Drupal is definitely moving towards the enterprise market and bigger implementations. While 3 years ago a typical Drupal project in our company required one to two developers to deliver over a few months, we now work on projects that require even 5-6 developers full time for extended periods of time. The websites we are building are really massive, complicated and require a lot of attention.

Expectations of quality and reliability have also increased as we started to cater to bigger clients. When websites get much more traffic and where errors often come with severe consequences, excellence in execution is becoming an expected requirement. Well organised processes are essential to maintaining the expected standards all the time.

Droptica has grown. We have increased in size by 30% in the last year and by 100% in the last 2 years. We now serve more clients and support many more websites than ever. This is super exciting. It allows us to learn even more and faster and do really exciting stuff, but it also brings along difficulties:

1. If Drupal releases a security update, we have to update over 100 websites as quickly as possible.
2. There is no single person in the company any more which "knows all the projects" - there are too many.

All of the above forced us to organise even better than before.

We embraced SCRUM

We have been using agile approaches much earlier but 2018 was the year in which we really went full agile. We can now safely say that we are an agile company. We use SCRUM methodology on all projects we deliver. Majority of our internal functions and projects are also run in SCRUM.

SCRUM is great. With bigger projects and larger teams it allows us to maintain high quality, organisation and pace on projects. Our clients appreciate the predictability and great control they have over the development process. We have written about the benefits of working in SCRUM and shared our experiences on communication in a scrum team.

SCRUM does not work for support

I could not rate SCUM high enough. However, despite all its qualities, SCRUM does not work well for support.

1. Support requests often come at the last minute and cannot wait for 'the next sprint' (eg. 3 weeks).
2. Support request volume is unpredictable.
3. Often debugging takes more time than fixing, making estimations really difficult.

SCRUM teams cannot do support 'in the meantime'

A team that works on delivering a project in SCRUM cannot support other websites in the meantime. Sprints in SCRUM are relatively short (typically 2 weeks) and tasks assigned should be finished within the sprint. If a team has particular velocity (amount of work they can deliver in a sprint), giving them additional support tasks will cause the sprint not to be delivered. This will be causing unmet expectations and inability to predict delivery dates of projects.

Alternatively, the team could have a buffer of free time left in planning for any support tickets that might arise. Our trials, however, show that this is not a successful mechanism. The team has to switch contexts way too often and the project begins to suffer.

The only situation where we find development teams successfully doing support is when they support a live version of the project they currently work on. This however obviously only works in scenarios when there is a development team that still works on a project. A project that is finished and does not need a full team anymore has to be managed differently.

Enter the Drupal Support team

After many trials and errors with various approaches, we decided that the best solution is to create a dedicated Drupal support team. The support team takes care of all the websites that do not have an active development team. This means all the websites that require less than a full-time developer worth of work.

If a website in support suddenly requires a bigger feature or more work to be done, we assemble a development team which takes over for a while. When the work is finished, the website is handed back to support.

We have been experimenting with this approach for the last 6 months and it has proven the most reliable. In fact, it is so great that we started offering support as a separate service.

Check out our Drupal support offer.