At Shutl, we strive to be as agile as possible in our daily work. Being agile is not about using coloured post-it notes, having stand-up meetings, or about writing code like a headless chicken. Being agile is about adaptation: an agile team is able to constantly adapt to the environment despite time pressures, demanding clients, and split infinitives. The reason we view a cheetah as more agile than an elephant is because, while running after a prey, they can adapt their direction in tenths of seconds despite running at the fastest speed any animal runs on earth. Elephants can run very fast but they change directions slowly. If the ground started breaking due to an earthquake, the cheetahs would be able to survive while the elephants would fall through the cracks. In the business world, earth-shattering events like new, disrupting technologies and swings in customers expectation can leave everybody off-balance. Is your company like a cheetah or like an elephant when the market changes under your feet? 

One of the cornerstones of agility is the Short Feedback Loop. The shorter the loop between you and the rest of the world (also known as Your Customers), the faster you get information from the world, and the faster you can adapt to it. Agility is not about running fast (elephants are faster than most humans), it is about changing direction and velocity when needed. What’s the point of moving very fast if you are moving in the wrong direction?

With this in mind, we have introduced Swapping Fridays at Shutl. The goal is to reduce the feedback loop between eBay customers and eBay engineers.  

Swapping Fridays? What’s that about?

Traditionally, all communication between the Engineering team and our customers has been mediated by the Customer Service (CS) team. They talk to eBay users (in our case, to eBay sellers and buyers), help them solve their problems and, in some rare occasions, escalate a problem to Engineering so that an engineer can help. This works OK, but it also means that there is some distance between the clients that want bug fixes and shiny new features and the engineers that are eager to provide them. Longer distance means longer times, which means less information flow, and we wanted to change that. That’s where Swapping Fridays come in.  

Every Friday one of our engineers spends a morning at the CS offices as part of the CS team, talking to customers and finding solutions to their problems. After lunch, a member of the CS team crosses the road in the opposite direction to spent the afternoon being a member of the engineering team, working on escalated tickets.  

How do our people feel about this? We asked two of them. 

The view from Engineering

It was a bright and sunny day when I came to the CS offices. I did not really know what to expect. I had never done any work like that. 

The CS team had just moved into central London and the first thing I noticed was that their offices were all updated. They were great: beautiful with a lot of wood, a lot of light, water fountains… their manager definitely did a great job at finding a place to work!

I was introduced to the person that would be my guide and partner into the unknown world of Customer Service. Time to start working! 

My CS partner spent the first forty-five minutes introducing me to all the tools that the CS team has to use on a daily basis. I was amazed, I was not expecting so many! A software engineer is used to work with several tools at the same time (compilers, editors, SQL clients, log analysers, etc) but our CS team faces a similar plethora of different software systems where I would have expected one single integrated tool. In the case of eBay / Shutl, this is the result of having integrated the systems of two different companies and of reusing a lot of legacy applications, but that is of little consolation for our poor CS team when they need to use different applications to search information about our sellers, the things they sell, and whether or not they are up to date with their payments. 

Once I was familiar with all the tools, after observing my CS partner dealing with a couple of customers by email / forum, it was my turn to turn into a full-blown customer representative. After watching a professional fly seamlessly from system to system, I felt like an elephant trying to move around a tropical forest: slow, clumsy, and out of my element. Practice makes perfect, though, so thanks to the expert guide of my CS partner I was able to do a decent job at CS emails by the end of the morning. 

Another enlightening experience was listening to a couple of calls from the Customer Service Team while they were calling some customers to explain what new services we were offering that could be interesting to them. Some customers jumped at the opportunity (“I’ve been waiting for this for a long time!”) and some other passed (“I will think about it…”), but it provided me with a richer experience and understanding of the people that we develop our code for every week. It is all too easy to lose track of those anonymous clients while one is thinking on reactive stream processing or fixing version conflicts of maven modules! 

The visit also had an unexpected outcome: I realised that there were a couple of things we could change in our CS tools. The changes were small, but they would have a massive impact on the lives of our CS team, making their job easier. They had never thought of asking it (“Is that even possible?”) and we had never thought of the right use cases. As soon as I was back in the engineering office, those stories were added to the backlog. Soon they will make our CS team even more productive, saving them precious minutes on every client’s email or call.   

The view from Customer Support

Without an amazing engineering team, it would not be possible for CS to operate the way we do. When the engineering team came to visit for the first time, the entire CS team suddenly became like meerkats on the lookout, peering over the computer screens in amazement. Having an engineer learn the CS tools and what we do was thrilling, it bridged the gap between two integral parts of the company.

Taking the 3 minute walk from one office to the other, and exploring a new side of Shutl, where engineer after engineer sit doing what engineers do, was for me, exciting. It was incredibly interesting to see the processes behind everything we do and see exactly how much work goes into what we advise our customers. I look forward to learning more, engaging more with the engineering team and working with them to update the tools we use to make the whole process more enjoyable for us and our customers.

Wrapping up…

We have been doing Swapping Fridays for a few weeks now and everybody is enjoying the experience. We feel closer as a team and we are still discovering ways in which we can be more productive. This is possible thanks to our increased interaction. As the Agile Manifesto says: “We value individuals and interactions over processes and tools”. 

The new features described by our engineer above serve as a case in point. Those features would have never happened were it not for the fact that an engineer spent a few hours in the shoes of a CS person. For an agile team, the customer is not only the guy on the street paying for your product, your colleagues from the department across the street are also your clients. Closing the feedback loop between you and them benefits everybody!

What other feedback loops have you narrowed in your company that helped you be more productive and/or more agile? Tell us in the comments!

---

With special thanks to Harriet Day and Chris Jewel for their help and input.

Photo credits: the elephant photo is from the public domain; the cheetah photo is a photo made by Jim Linwood from a statue in Kew Gardens, London, UK, and is used under the terms of CC-BY 2.0.