Refactoring EV apps: Lessons in Ownership and Risk

Our client provides software solutions that are relevant to the Electric Vehicle (EV) domain. As part of their solution portfolio, they have a mobile app that enables an EV-driver to start a charging session conveniently. This app consisted of a front-end which the EV-driver interacts with and a back-end which enabled the desired functionality. The back-end had been redeveloped from scratch to implement the latest technologies to enhance security, scalability and to improve overall app performance. Now, the client wanted to refactor the front-end to interface with the newly-developed back-end.

Download the full Insight (PDF) to learn how this refactor nearly failed.

The playing field

The playing field is made up of three key players:

Marketing owned the development budget for the mobile app which makes them the business owner for this project. They had received a negative review from a journalist that primarily focused on the lack of performance of the current mobile app. Hence Marketing had a clear interest to ensure that the refactored app would solve this issue. To that end, Marketing would provide a Product Owner.

App development is part of the IT department. The CIO, being the head of IT is responsible to deliver the refactored mobile app. The CIO is also responsible for project resourcing for all IT-roles. The organisation itself was in a start-up to scale-up phase which reflected in an ambitious roadmap for IT. To prevent delay in delivery of the refactored mobile app, the CIO had chosen to source an external DevOps team.

The DevOps team was sourced based on a fixed-price basis. After all, the scope of the assignment was straightforward: refactor the front-end to interface with the newly-developed back-end. The teams that developed the back-end had already provided artefacts that described how the back-end worked. How hard can it be?

They hit the ground running

Budget was assigned, externally-sourced DevOps team brought in, back-end documentation was shared. The project hit the ground running and the DevOps team started the work. The cracks became visible after the first few weeks:

The DevOps team had studied the back-end documentation and concluded that this documentation specified how the back-end worked, not what the front-end should be doing with it. No Business Analyst was assigned to this team as refactoring was considered purely technical change. The DevOps team looked to direct their questions to the Product Owner. However, the Product Owner was not actively involved in the delivery of the project. The questions the DevOps team had thus remained unanswered.

If you fail to prepare, you prepare to fail

Without discovery on the current functionalities of the mobile app, the DevOps team was left in the dark on what needed to be refactored. Without a support channel for their questions they remained in ambiguity while pressure mounted to deliver. This created the recipe for a Doom Spiral.

Adding Business Analysis capability broke the cycle

The lack of delivery progress eventually resulted in escalation to management. Management asked COPAF Consulting to support. Our Business Analysis capability learned of the story as described above. We set out the following actions to break the Doom Spiral and to pivot towards a more constructive collaboration:

We revised the documentation on how the back-end worked with the DevOps team. From the developers we learned that they had no prior knowledge on what functionalities the current mobile app contained. During refinement sessions we carefully documented questions the DevOps team had. Subsequently, solutions the DevOps team proposed were also captured as actionable user stories.

The Product Owner was informed of his role, but not of his responsibilities. We found a puzzled Senior Marketing professional that did not understand the questions asked by the DevOps team as these were technically abstract. We aligned the Product Owner to have a better understanding of his role and responsibilities. We translated DevOps team questions to functional consequences for the mobile app. Our analytical insights were understood by the Product Owner, resulting in actionable decisions for the DevOps team.

The solutions proposed by the DevOps team were implemented together with the decisions made by the Product Owner. The project started to deliver meaningful progress towards a refactored mobile app.

After a conversation with the Business Controller we found the missing puzzle piece that triggered the escalation to management: the CIO was not provided with an overview that listed current mobile app functionalities and implemented functionalities in the refactored app. We thanked the Business Controller for this valuable input and went to work.

Documentation on the current mobile app was difficult to get, which prevented us getting insight in current functionalities. We chose for a practical solution: we borrowed the test phones from the QA Engineer to map functional capabilities from the current mobile iOS and Android apps. With help from the back-end developers we mapped these capabilities to the new back-end. The resulting overview provided a roadmap of what functionalities had to be present in the refactored mobile app. After aligning with the DevOps team we quickly established what was already implemented:

We presented this overview periodically to the CIO to enable him to see delivery progress and steer accordingly.

What did we do differently?

We had to connect the dots that caused the Doom Spiral to begin with. Eliminate ambiguity, aligning stakeholders and providing a simple overview of where the team was versus their destination. Our top three would look like:

Support the DevOps team by providing them structure on what needed to be refactored rather than how. The DevOps team clearly did not lack motivation as they consistently provided constructive suggestions in how to implement the requested functionality. What lacked was understanding to their world of experience and answers to questions needed resolved before they could proceed.

We earned the collaboration of the Product Owner by presenting the DevOps teams’ challenges in his language. Showing a Senior Marketing professional a use case that functionally describes consequences of action or inaction makes it a lot easier to make a decision. After all, Marketing is interested in a refactored app that provides the best user experience with technology being the enabler rather than the protagonist.

Going through the current mobile app ourselves enabled us to provide stakeholders with a valuable insight. The resulting impact analysis clearly demarcated what was already refactored and what still needed doing. This in turn enabled the CIO to steer the project accordingly.

We were not able to help everyone. Unfortunately, two developers had burned out.

What we all learned

There were also things to laugh at: Marketing had arranged a two meters tall iPhone for a software conference where the refactored app would be launched. After verifying which version of the app the DevOps team was supposed to support for the conference, we found out that this giant iPhone had an Android operating system. Even here, assumptions would have been dangerous!

The retrospective spoke for itself once the refactored mobile app went live:

Was occupied with daily managerial responsibilities within Marketing. Besides being told that he was now a Product Owner, nobody bothered to verify whether he was aware what responsibilities this role bestowed upon him. Once made aware, he became more enabled and engaged with his Product Owner role.

Sometimes the credo “work smarter, not harder” starts with signaling unclear user stories. This allows governance to take effect and enables those in the organisation to take ownership and provide further guidance.

Sourcing a DevOps team for a fixed-price contract was commercially a clever move. But the true business value became sustainable once Business Analysis provided the required structure to deliver.

Is EV-software an isolated case?

EV-software is a relatively young market. Unlike established industries, like financial services, it has far fewer frameworks and best practices to rely on. This makes delivery a lot more challenging and introduces numerous risks that may not have been foreseen on the initial roadmap.

What we see in this market:

Patterns repeat in EV-software projects because, as humans, we revert to past behaviour and experience to get things done. Developing further (market-specific) frameworks would mitigate this.
Project risks are not specific to EV-software. These risks occur because of lack of ownership, undiscovered technical dependencies and unaligned stakeholders.
A single Business Analyst can save time and budget of a full DevOps team not adding value due to ambiguity. The pay-off can be found in sustainable delivery, transparency of scope and stakeholder alignment moving forward.

We provide the structure that a DevOps team needs to refactor an app. We enable a new Product Owner to channel his business seniority to that same DevOps team. We give insight to C-level that allows them to steer a project and communicate progress to their peers with confidence.

Who we are? We are COPAF Consulting. Feel free to get in touch if our story sounds familiar to you.

Facing a similar refactor?

Let’s discuss how to restore ownership, eliminate ambiguity and enable sustainable delivery before the Doom Spiral sets in.