Delivery Management approach to Reactive Trader^® – Establishing context (Part I)

How it started

Reactive Trader^® is an amazing example of how great technology is built when technologists have business context and the right technical expertise. The first version of this showcase application was built in 2014, in the very early years of Adaptive. The founders believed the best way to showcase Adaptive’s combination of real business expertise and great technical delivery skills was through working software that our clients would recognise. Initially, Reactive Trader^® was intended to replicate an FX single dealer platform and was very much a test bed for technical innovation, being worked on by people who had time to spare or were temporarily between projects. We used it to demonstrate complex technical ideas in a way that non-technical audiences could understand, by showing them software in a business domain that they recognised. It has proven itself incredibly valuable to Adaptive.

Fast track to October 2019, and Adaptive had expanded to over 220 employees, with offices in four different countries and a growing sales department. This meant Reactive Trader^® grew too, due to the increasing number of people working on it and our strategic goals for new business.

The great technical craftsmanship at Adaptive enabled Reactive Trader^® to evolve into a strategic tool for a number of different stakeholders from sales, UX, desktop strategy, company onboarding within Adaptive and to partners outside of Adaptive.

Why change is needed

This sounds great, but growth comes with its own set of complications. As of late 2019, Reactive Trader^® was experiencing the following issues with various stakeholders:

1. Unpredictability in people availability – This is a common challenge for consultancies, as there is often an unpredictable nature concerning when engagements start or are extended. Therefore, there is constant change, difficult to predict, which results in the bench and resourcing for Reactive Trader^® being unstable.

2. Lack of a consistent team – Clients at Adaptive take priority. Reactive Trader^® is resourced through people’s availability across the organisation when not working on client projects or from our graduate program. This means we always have different people rotating through the team and therefore little consistency, which impacts continuity, context, and knowledge sharing and handover.

3. Different stakeholders and alignment – The growth of Reactive Trader^® as an application meant increasing interest from a number of new stakeholders, from external partners to sales teams, and most recently, the marketing department. Different stakeholders mean different views on priority. Not having a clear and defined delivery approach and way of working, in turn meant that there was a lack of transparency about what was being prioritised and what was delivered. As stakeholders were not being informed and there was no alignment of priorities, this resulted in a lack of engagement.

Both Adaptive and the application had grown over the years, but little effort had been made to think how we should manage and deliver it. If no action is taken to adapt to the changing circumstances, this could result in the risk of having a product no longer fit for purpose, and dissatisfied stakeholders, which will lead to a lack of engagement and a frustrated workforce due to a lack of process, quality control, and knowledge sharing. By carrying on without paying attention to the process, we were running the risk of diminishing the value of Reactive Trader^®

Approach

The inspiration for the delivery management approach to Reactive Trader^® was the STATIK (Systems Thinking Approach to Implementing Kanban) method devised by David Anderson. The STATIK approach is summarised in the below graphic, which is a method to introduce Kanban to organisations.

While STATIK was taken as inspiration, we took a custom approach for Reactive Trader^®.

1. Aligning with purpose: When starting a project, I always like to know the purpose of the project or product. Asking the simple question ‘what is the purpose?’ serves as a litmus test to see how well-aligned people are. When people are clearly not aligned with purpose, it’s a great indicator for needing to re-align/revisit the value proposition or reminding the team and stakeholders of the end goal. Clarifying the purpose is not only a great communication method to align multiple stakeholders, it is also a great motivator. ‘Purpose’, one of Dan Pink’s three elements of intrinsic motivation, is summarised as people being more motivated and wanting to do things that matter. In my 14 years of delivering software, one of the best motivators for a team is seeing how their direct actions contribute to the company’s mission.

2. Understanding the team’s journey and current process/capability: For a project team who have been operating for a while, typically there will be a history of tried and tested approaches, and it’s good to understand the team’s journey. Learning the history of what was tried, tested and perhaps found wanting and why we are doing things a certain way is the foundation of future incremental change. It’s also good to assess the capability and analyse any deltas versus the expected output. The goal is to listen and understand context.

3. Collaborating with stakeholders and the team to establish pain points: In my experience as a change agent, a great way to enable change is to recognise and establish the common pain points that stakeholders have. Visualising and creating empathy for these common pain points generates the least resistance and is a good kick-starter for quick win initiatives. If done correctly, during this process you will forge tighter relationships with your team and stakeholders. The goal here is to acknowledge that change is needed.

4. Make incremental improvements to the process: In my experience, once people view and acknowledge current pain points and see another alternative, they are more willing to give things a try. I believe it’s our job as delivery leads to act as a mirror to this reality and paint or visualise an alternative. At Adaptive, our approach to agile is being pragmatic. Each project or business is unique; we therefore believe the best results are achieved through experimenting to see what works in an incremental manner, being transparent, and collaborating with people impacted by the project. The goal here is collaborating towards a solution or process that is fit for purpose.

In part two, I will be publishing the findings of the above approach and how we have gradually transitioned from a Scrum framework towards Kanban and to a process which is more fit for purpose for the nature of this work.

Andres Gutierrez is contractor Delivery Manager at Adaptive. Andres has worked with many teams in various industries as a Scrum Master or Delivery Manager for over 10 years. His passion is product development, teams, and agile ways of working.

Andres Gutierrez

Delivery Lead,
Adaptive Financial Consulting

Let’s talk