How You Can Build Variability in Your Digital Solutions
Updated: Feb 16, 2022
Introduction
Case Study
Organization ShoeShop has a business of selling shoes to customers. It is a business that traditionally involved the physical presence of the customer in the shop. Till some time back, ShoeShop only used software as a support for its main business. However, it now has an online presence that caters to a small segment of its customer base. Having seen the trend of online shopping, ShoeShop has expanded its software offerings. Its main customer base is still retained within the physical environs of its shops. In such a scenario, ShoeShop suddenly finds itself confronted by a disaster like COVID-19. What can it learn about processes from its current situation which will help make the organization come out stronger at the end of this disaster?
Leaving aside the psychological and physical toll of the pandemic, I will be concentrating on this article purely from a business solution perspective.
In general, I found the problem to be multi-pronged.
On one dimension, the supply chain was disrupted, time and resource management were in chaos and both scope and cost moved into an unknown sphere.
On another dimension, is the last mile approach. How do you reach a customer who cannot even be approached any more? In some cases, your traditional customer base may no longer be available overnight.
This problem is not about how you let your personnel work from home and were still able to carry on operations. This problem is more systemic within the organization. And at its core are 2 important areas - Discovery and Operations. Let's ask ourselves a couple of very simple questions:
Has your discovery process given your business enough variability for you to pivot to an alternate plan?
Is your operations pipeline robust enough to handle any pivot in your operations without a glitch?
Discovery -
What is the discovery process?
Traditionally, the discovery process is collated within a ‘Phase gate’. The discovery phase consists of identifying requirements for a project, its targeted market, limitations, etc.
This would help the organization in specifying in exact details the scope of the project (e.g, targeted for the demography of 25-35 in Spain) or going even deeper to understand the nature of the implementation. The result would be multiple levels of documents ranging from Software Requirement Document, Non-Functional Requirement Documents to System test documents. This would be a trigger for Project Managers and Business Sponsors to start having multiple rounds of discussion based on the above documents to finalize the details of the Execution plan.
As you can see, the Discovery phase is an important phase in the lifecycle of any business. However, in the traditional model, this is a separate phase entrusted to few people with specific knowledge.
As we move towards a more ‘Agile’ world, the distance between the Customer and Execution context is reduced. The Discovery Phase is not external, but theoretically happens in a continuous cycle through which the Product Backlog is kept alive as shown below.
However, even in organizations following Agile practices, Discovery is not a monster that is tamed easily. How do you allocate budget/resources to a process you do not even know will deliver value to your organization?
In a traditional model, the discovery phase is kept mostly separate from the execution phase. What would this mean in terms of various components of our business?
Resource - Personnel would be kept separate, meaning those working in the discovery phase would rarely work in the execution phase. Hardware and software resources would need to be handed over between different teams.
Knowledge - Since personnel working in these two phases rarely crossed over, inherent knowledge would need to be passed between personnel working in these phases. Between documentation and code walkthroughs, there will always be a gap when knowledge is transferred between two entities who do not mix.
Budget - The budget for the discovery phase and execution are separate and may even have different sponsors. This leads to a chasm between entities as budget differentiations are the biggest factors in enabling projects.
Case Study contd…
ShoeShop has been satisfied so far with its software offerings and processes. After all, it moved from a Waterfall approach to an Agile framework. It was able to give targeted advice to its customer base. It had capabilities for online shopping and kept updating new offers from time to time. What could go wrong? However, it has suddenly been confronted with a situation where the bulk of its customer base has been tendered void due to physical shopping being completely banned (for posterity - remember lockdowns during COVID-19). How can it pivot to suddenly offering customers a new mechanism of shopping, which could offset the losses its physical entities generate?
Since we have moved to an Agile framework, the Discovery phase has been a continuous process. The customer is engaged after every Sprint if possible or at the very least after every Release. This helps in discovering feedback of customer which is turned into Product Backlog items for future Sprints. This seems to be a correct approach to incrementally and continuously provide new offerings. What then is the problem with this approach, which is not only used by our imaginary Organization ShoeShop, but also many other organizations? We can distill it down to the first questions we had asked in our introduction:
Has your discovery process given your business enough variability for you to pivot to an alternate plan?
This leads us to the question - How do you introduce variability through your Discovery process?
Implementation
Let us look at a 4-step action plan to help introduce variability in the program/feature delivery.
I
The first action needs to be a shift in the customer interaction mindset - from a purely fixed mindset to a variable one. What this means is that we no longer keep the customer as an external entity being discussed at the beginning or end of a cadence. The customer needs to be central to all your discussions at every ceremony of the framework that you follow.
The very act of putting your customer left, right and center in all your discussions will cause a shift in mindset by introducing multiple options that can create their solution for the customer.
How do we put this into practice? There are multiple tools available already. Some of them are listed below. The change in mindset can be brought by repeatedly practicing any of these tools until they become a part of the process.
Journey Maps - Is the visualization of the process a customer goes through to achieve the expected goal. It can be created by superimposing the thoughts and emotions of a customer on a timeline of her actions to achieve the goal. This provides a consolidated narrative that can be used to play through multiple scenarios via personas and often leads to opportunities to be exploited.
Empathy Maps - Provides an overview of a customer’s experience through understanding the key traits the customer possessed. It is a mechanism by which we understand what they felt or thought based on their interactions. This helps us view new opportunities to exploit and offer to the customer.
Design Thinking - Using feedback from tools such as Empathy Maps, Design Thinking allows us to find novel solutions around customer-centric problems. It humanizes problems and resulting research leads to opportunities that can again lead us to obscure but important solutions.
The above are only some of the tools at your disposal to inculcate a customer-centric mindset. You are free to choose any or a mix of such tools. What is of primary importance is to repeatedly use these tools until they have become a part of your organization’s DNA.
II
If you have set up a process to initiate the Discovery process, will it be enough to help you achieve your goal of variability? The second act to follow is to create a pipeline that keeps the flow of items, identified during the initial process, smooth and continuous. This can be looked at through 2 perspectives:
(i) Timeline - The items identified should be introduced in such a way that the flow can be continuous through the processes set up within your organization. Identified features/programs should be introduced to the delivery pipeline in a way where the release timelines are staggered. As an example, some which might be released in a 3-month horizon, some in 6-9 months, etc. From a broader program perspective, this will ensure a continuous flow of value for your organization.
(ii) Prioritization - The second perspective is that of prioritization. A set of processes such as Kanban is ideally suited to keep identify features/programs which can be prioritized based on their readiness and associated factors. The readiness of the feature/program can be matured as the item moves through the various stages of the Kanban process. It does not mean that all aspects of the item are sketched in stone. It, however, means that we have discussed the feature/program and understood the scope. Besides, we understand the various risk factors and the business value that can be gained. And we do have come up with a plan for execution and identify the current unknowns as we go forward. Which are the features/programs that gain us the most value in various horizons of the timeline?
Interchangeably, this can be seen as a queue with the highest priority items in terms of business value and timeline bubbling up in the prioritized queue.
Let me clarify - Prioritization should not only capture the highest value in the shortest time (Weighted Shortest Job First), but it should also help us identify those programs/features which can be most valuable in multiple horizons of time. E.g, A feature to provide Augmented Reality effect for ShoeShop’s customers will be in a longer timeline horizon. However, the value from this could also be high and hence, should be prioritized.
The biggest advantage of following this process is that it gives your organization a focus and options to pivot during crucial phases of operation.
III
Even in organizations following Agile frameworks, knowledge management between business discovery and execution remains a challenge. The third modification required is that of knowledge management within an organization. The general mechanism followed is to create an explicit knowledge base from the tacit knowledge gained by any team working in the discovery pipeline. The team(s) working in the delivery pipeline depend on this knowledge base using multiple tools to extract the knowledge as and when needed.
However, I have found that the best mechanism of knowledge transfer is not to have any transfer at all or if necessary keeping it at a minimum. There would be a multitude of implicit activities committed, assumptions made, which would always remain in the tacit zone and might never be documented in the explicit knowledge base. Any transference of knowledge, no matter how useful the knowledge management tools are, will always cause missteps and wastage.
One of the following 2 ways would be highly beneficial to reduce knowledge management wastage:
(i) Allow ownership of features/programs to team(s). This ensures that knowledge transfer is kept at a minimum. Additionally, the team(s) is/are focused on the program and is/are associated with it throughout its lifespan.
(ii) If (i) is not possible, ensure that several people working in the discovery pipeline are transferred to the delivery pipeline when the feature/program is transferred. This ensures that we do not completely depend on the explicit knowledge management base. The tacit knowledge which had existed in the discovery pipeline is also available, although in a reduced capacity, with the delivery pipeline.
IV
The last but one of the most important modifications is that of budget management. Agile frameworks advise Agile program management. How would this help us through the discovery and delivery pipelines?
(i) Prioritization - One of the most important components of the prioritization is budget. If you have a limited budget, and 2 programs which are competing, which would be given a higher budget? The answer to that question lies in prioritization. It will depend on multiple factors, of course, which will all be factored. If metrics are available, they have to be taken into account. E.g, the number of paying customers through the program. However, in some cases, direct metrics might not be available. E.g, a digital conversion program that might lead to higher performance in the future. The budget for such programs must be fixed to a point where they can generate enough metrics to confirm or reject the benefit hypothesis. For items that are found to be of lower priority, the budget should be reduced, which might lead to the movement of personnel/resources from lower priority to higher priority programs.
(ii) Pivot - Budgeting through an Agile framework also allows the flexibility for program management to pivot at any point where the benefit hypothesis is disproven to a new model and hypothesis.
As shown in the above flowchart, creating a queue encapsulating multiple time horizons allows us to have variability built into our plans. Creating a budget based on the value of such programs and revising them on a cadence allows us the ability to make intelligent choices and pivot as soon as possible to value systems that are better suited to the organization's roadmap. E.g, Would it have helped ShoeShop if they could pivot to their program for bringing in an AR-based approach to online purchase platform? During a lockdown phase, where their core customer base was lost, could this pivot have provided them with a new value proposition?
The point to be noted about this mechanism of budgeting is the repeated checks and balances based on the metrics. This has the inbuilt quality of a transparent process of prioritization.
There is a large collection of literature on pivots, its mechanism, tools, plan, etc, discussion of which is beyond the scope of this blog.
Conclusion
The above 4 action steps show how steps can be taken in a co-ordinated manner, focused on an end-goal of maximizing options and variability. The goal of this is to show how these actions should be interwoven to practically introduce and maintain variability which can help maintain the viability of your business even in times of distress. All of the above processes are already followed in one way or another in all organizations. The need is to ensure the coordination between these steps and interweave their execution.
The next part of this blog will deal with the question of the robustness of the delivery pipeline to ensure it can handle a pivot with speed and security.
About Me : A passionate Agile leader having 16+ years of experience in software industry, I have handled Agile projects of various complexities. Having successfully handled Agile transition for multiple organizations, I write about my experiences, challenges and some solutions.
Connect with me through LinkedIn and Twitter
#Agile #EnterpriseAgility #DigitalTransformation #AgileMindset #AgileCoaching #AgileCoach #ScrumMaster #AgileTransition #AgileProgramManagement #AgileSolutionManagement