Nov 5, 2020 7:15:00 AM

Beyond Agile: Empowering customer care

 

When I joined Solvemate as Head of Engineering in March 2020, two exciting challenges were waiting for me, of which the first one was rather familiar: 

How do we transform a modern cargo cult of often misunderstood agile process artifacts, such as stand-ups, sprints and user stories, into an actual culture of agile principles, where these artifacts become a means to an end?

 

As Solvemate has always had a clear goal and an explicit, marvellous culture already, this was rather straightforward, since our five core values of #teamwork, #transparency, #candor, #commitment and #curiosity are easily translated into a methodology that directly draws a line between developer empowerment and customer satisfaction. Agile and Solvemate are a perfect match! And so are agile principles and customer service. Let me tell you why:

 

 

A culture of agile principles

 

If you are not yet familiar with the Agile Manifesto, here’s the core of it:

 

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

 

In B2C software companies, translating agile principles works by listening to the software’s present and future users and communicating change early for a tight feedback loop to steer where development is going. Solvemate is all about empowering customer support, which sits at the long end of a B2B2C chain together with the end customer. This makes a direct translation more than challenging. 

 

We provide our software as a platform product to other businesses, so two different schedules are at play: That of product development with a feature roadmap and that of customer support, where the only roadmap is literally supporting customers “here and now”. Who could benefit more from individuals and interactions over processes and tools as well as customer collaboration over contract negotiation more than a customer support team, which is all about individuals, interactions and collaboration?

 

 

The conundrum of two different schedules

 

The second challenge wasn't as easy and therefore much more exciting, as no straightforward answer was known to me. To deliver a world-class product, software delivery teams and product owners need a contract which makes sure that project commitments are fulfilled, while the delivery team can work as distraction-free as possible, or the contract is put at stake. Iterative and incremental development are meant for a team to respond to changing requirements, but these are coming from Solvemate’s disruptive chatbot product and require a degree of planning, which comes in the form of fixed-length sprints. Our customers however have different demands and different business cycles that directly cut into product development sprints. But not just that, sometimes, things happen that require the immediate attention of a software engineer, including customer requests as well as incidents affecting service availability. How could I have solved the conundrum of the two different schedules?

 

The formation of the Direct Action Initiative (DAI) is testament to the conflicting requirements of planned, high quality product development and the unpredictability of individual customer requests as well as software development itself, as bugs exist and are often discovered after a project has been delivered. Each software delivery team nominates and assigns one software engineer to serve in the Direction Action Initiative in a single sprint. Within the DAI team’s responsibilities are incident response, customer requests and hotfixing Solvemate’s production code. As each delivery team has to dispatch an engineer per sprint, the resource reduction becomes fully plannable, but as the assignment is rotating, it prevents DAI duty to become a potentially frustrating, dedicated full-time job, all while fostering knowledge transfer and cross-team collaboration, at the same time! We are called Solvemate for a good reason! 😉

 

 

Daily DAI Team Routine

 

Understanding what the DAI team does and why it’s ultimately so great for customer satisfaction is best achieved by looking at what the team achieves on a daily basis. Before any of the other teams’ standups, the DAI team meets for their daily briefing, which is a more fitting term for its work. Aside from the rotating DAI team members, DAI has three permanent members: Support Engineering Lead Liva Karlivane, who is responsible for preparing customer-facing issues and requests, the company CTO Jürgen Vogel for critical high-level decisions, and me, the Head of Engineering as effective, permanent team lead and agile coach. 


Recommended reading: 5 benefits a support engineer will bring to your customers (and your product)


All ongoing work is tracked through a Kanban style project board, which comes with its own backlog, organized primarily by due dates in case of customer requests and secondarily by severity of bugs. That way, customer requests and problems are always prioritized over any other issues! Through her permanent presence, Liva can always ensure that customer requests are understood and provides a backchannel for any questions that might arise, while also shielding team members from any direct meddling. During the briefing, existing, started issues are discussed until they are resolved by team members, while new issues are discussed and, if necessary, injected into the current sprint, should the need arise.

 

Before the DAI team was around, the best case scenario used to be that Liva would quickly find an engineer familiar enough with a topic, who would interrupt their work to work on the issue, while delaying their delivery team’s current work, to the frustration of the Product Owner. In the worst case, she would be bypassed by a Customer Success Manager, who would struggle asking around and finding anyone able to help, ultimately with the same consequences. 

 

Now however, Product Owners, Delivery Teams and, most importantly, our customers get exactly what they want and deserve: Customers get near-immediate support, reliable help and quick remedy for any problems, while Delivery Teams can provide reliable estimations and ultimately an intact agile development process that Product Owners can rely upon. As an added bonus, software engineers get to exchange knowledge and learn about new parts of the technology stack, which ultimately reduces our bus factor. Lastly, isolation between Delivery Teams is lifted and cross-team knowledge transfer established.

 

chapter_end@4x

 

 

Truly Agile

 

At Solvemate, we can say with confidence that we are delivering a world-class product, which is made possible by enabling our own software engineers to employ agile development principles to a maximum extent by being distraction free, all while empowering our customers not just to enjoy our product as a mere consumers of a faceless SaaS product, but as people who enjoy direct support by other people - which is made possible by joining the best of three worlds: Features delivered through reliable business planning, agile development methodologies which close the gap between business needs and development uncertainties, and last but not least, excellent customer service that is directly empowered by those who create and understand our product: Our software engineers.

AUTHOR

As Solvemate’s Head of Engineering, Alex is passionate about connecting people and technologies. He loves a good challenge to bring change for the greater good. On top, he’s wild about great collaborations, but also celebrates people who go ahead emancipated.