Screach is an award-winning Newcastle-based company that delivers interactive experiences between digital screens and mobile phones, such as a trivia quiz in a pub or an awesome mobile-controlled game on a digital billboard. We are speaking today with their CTO David Challener on how the team manages its development process.
Tell us about yourself. What does Screach do and what is your role?
Screach delivers interactive experiences with digital screens. The easiest example is the following: Imagine an interactive quiz running on a screen in a pub, and people using a mobile app to answer the questions in real time. We set up that interactivity between the mobile app that we call Screach, and the digital screen. We have done quizzes, crowd voting and interactive games, to name but a few. We did one experience for insurance firm SwiftCover in which a course was shown on a big screen, and passers-by were challenged to steer a car along it using their phones as a joypad.
We’ve also built a hardware product called ScreachTV, which allows venues like bars and restaurants to put targeted, relevant and engaging smartphone-compatible experiences such as quizzes, messages, offers and games on their TVs. They’re in around 100 UK venues already as well as some in New York, and that’s increasing all the time.
And you are the CTO of the company, right?
Yes. So anything technical basically goes through me and my team.
How big is your development team and how is it organized?
We have got 10 developers, split out into mobile app developers, a web developer, and a backend developer. Most of our team are people who code for a specific device. We also have a developer who does web and Microsoft-based languages, and another developer who does the backend systems – the database work and our API, which is the main build in our system.
Is the whole team based in Newcastle?
No, we are actually quite remote. We have me and another developer here in the office, and that is it. Our iOS and Android devs are nearby, and the rest of our team is based in Romania.
Can you tell us about your development process?
Yeah, we adhere to the Scrum agile process. It allows us to know upfront what items may cause lags for us. If we have a new set of requirements, we can very quickly prototype those out, see whether this is the right way to go about it, and change quickly.
The other good aspect of Scrum is that as we are quite a remote group, communication is pretty hard. Scrum enables us to have stand-up meetings, get into dates, find out what we are up to, what everyone is working on, and whether there are any roadblocks in the way. It helps us hugely with the communication.
How long are your typical sprints?
Most sprints are probably a week to a fortnight. The sprints are quite short. Sometimes we have shorter sprints, and sometimes longer, and I am quite happy with these periods. The technology we are using is often the latest and cutting-edge, so sometimes the answer is to set a goal and then make highlights of the things you want to know more about. We do these early sprints and find out pretty quickly whether the approach works as expected.
Do you do daily stand-up meetings?
Yes, we do. Actually the whole team does a stand-up meeting at the end of the day. So we all know what everyone in the organization is up to, rather than just developers – which is quite nice. We get to find out better why they are doing their tasks, what they are doing, and the others find out better what we are up to in the development process. So that step has been taken out of Scrum, and everyone does it, it is quite nice.
What are the biggest challenges for you in terms of managing the development process?
I think one of the biggest challenges for us is that so many of developers work remotely, so the communication becomes a big issue. The way we have been tackling it is trying to introduce methodologies that help with communication. We also use various tools to help let people know what they are doing – we use Basecamp, which lets people put in the tasks they are working on and helps with visibility across the team. You can see what someone is up to, what they are doing and whether they may be able to respond quickly to certain questions.
At company level, we use another tool called Yammer. This is somewhere where people can say: ‘This is something cool I have done today, go and check it out’. It is a bit more hands-off, in that you can forget about it for a bit and then go to see what everyone has done that day.
Do you have any changes planned to your process?
There are no big immediate changes planned. It would be good to have more people based here if possible, but I have not got any issues with our team at the moment. We continue to look at how to better understand what people are working on. There is another tool I have been looking at that helps with Scrum, it is called Team Foundation Service. It is good because we have a lot of work in .NET and that would help us formalize those changes, so this is exactly what is missing.
Do you have any advice for other start-ups and CTOs?
Do not be afraid to change – that’s a good way to run the process. When we first started out, we had a completely different vision of how our app would work. We have allowed influences to come in and say: ‘Look, that isn’t right’, and just have been allowing that to change and grow. Some of the biggest lessons we have learned have come from allowing things to change.
