Platforms
The Art of Platform Thinking
Are you a recent adopter of Agile Methodologies or maybe you’ve been a practitioner for a while and wondering why some of the practices don’t make sense all the time? Maybe you’ve developed fatigue over various ceremonies involved in Agile or Scrum environments or are frustrated by an inability to define what valuable functionality will be delivered within a fixed timescale. Fear not, Value-Oriented Incremental Delivery (Void) can help.
But before we delve deeper into the how Void delivers value, let’s consider how we got here.
Over the past 15 years, companies have been hopping on to the agile bandwagon and been customizing agile practices to suit their organization structure, in the hope that practicing some of the processes would bring change into the organization. But in the process of adopting the practices, many of the principles of Agile Methodology have been forgotten. Even though the principles are still relevant today—for instance, responding to change over following a plan—we see so many organizations wanting to adopt agile, but they’re stuck with ‘ceremonies’, unable to question their practices.
These ceremonies have become a bottleneck: an excuse to follow pre-defined practices, while agile principles are quietly ignored. Incentives and motivations are too tied to adopting the practices that have encouraged a checklist culture. This culture ensures teams follow certain ceremonies in a cadence—without considering the value that the software delivers to the customer or the long-term impact of not resolving deficiencies in the systems.
Language used on a day-to-day basis influences our thinking, which in turn affects our behavior. So if we are to change the behavior, it helps to start by changing language.
Some of the standard agile practices like Iterations, Velocity, Release Planning, Technical Debt have permeated the industry; people have become familiar with the terms and practicing these ceremonies has become how we talk about managing delivery.
A timeboxed repetitive approach to building software is an additional artificial constraint that limits our ability to deliver value within with a given time. Teams often struggle to define the value to be delivered within a fixed timebox.
The focus of the conversations has been on what scope to deliver within this artificial time constraint, rather than the value produced and how value can be realized quicker.
When a team is not able to fit the next valuable deliverable within the timebox, they scramble to identify what else the team can work on within the given timebox. Instead they should work on the next most important value quotient, such as one that addresses a customer's critical migraine problem or an underserved outcome that improves the market position for the company.
A team of developers, quality analyst, product owners come together and beat the story to death, endless debates about what acceptance criteria are missing, and then comes the interesting part, the 'sizing'. Teams dread the experience of going through sizing and coming to a consensus on what the size of the story should be. How to split the stories to keep it in small chunks? Most of the time the person who has the most convincing skills wins the argument and the team members—either out of fear or not wanting to constantly argue—accept a size whether they believe it or not. Ultimately it comes down to the gut sense of how “long” a given story is going to take to get it done. While the correlation between size and the time taken to deliver can be significantly different, we get a false sense of comfort in our ability to predict the time taken to deliver a given scope within a given period with accuracy.
We can also debate that maybe the teams have not done relative sizing and sizing is different from estimation. Whether we do relative sizing, estimation, break down stories into equal sizes, or the new buzz phrase “No Estimates”, ultimately it comes down to a discussion of process optimization and predictability in delivery, rather than identifying the customer’s value the given need will deliver, what pain points or underserved need will be tackled, how to experiment the change, how to measure, and what we have learned as a continuous experimentation loop.
Tech Debt is too often an excuse to not address a growing developer concern. It crept in as a way out of dealing with a problem, but it steers the focus onto delivering a given scope within the timebox. Ultimately, over a period the team accumulates enough Tech Debt that it move at snail's pace or need to re-architect the system as it is not extensible enough, or the software is developed with poor quality standard. Tech Debt has become a serious value inhibitor by itself, and a very negotiable deliverable severely affecting the developer experience.
It is time to shed our limiting vocabulary and model, and instead adopt methodology that focuses on the principles and on customer value, improving developer experience, and less on the ceremonies.
The emphasis is on understanding the customer, pain points, underserved outcomes and how to realize the value sooner.
The Void model focuses on: value at every stage; activity and experience; and connecting organization goals, vision, initiatives—along with the technology and architecture roadmap—to an effective delivery mechanism to realize value. It also provides a new set of vocabulary to manage delivery, one focused on customer value and value creation.
The Value Quotient helps us understand the actual value associated with an initiative or feature. The pain point attribute helps to visualize the value regarding whether the given quotient helps address a Migraine Problem for your customer, or is it more focused on addressing an underserved outcome —one which will improve market capitalization.
The Underserved Outcome reveals a market that is in need of a solution—this helps customers get the job done better. It represents opportunities for growth, whereas the Migraine Problems reveal the biggest pain points for the customer to leave.
Once you have attributed your value quotient and the pain point, visualizing the value quotient against a set of platform capabilities helps prioritize the value quotient against delivery.
The duration of the experimentation block is determined just in time before the start of the block. The teams should conduct ‘team juggles’ to determine the next value quotient they want to tackle, the duration of the experiment block, how to facilitate the experiment, and what support is needed from the rest of the organization to amplify the impact of the value.
Every value experiment block is followed immediately by a value review. This helps evaluate the experiment based on the measures identified and the impact created. The learnings are taken into consideration in adjusting the value quotients and the experience appropriately.
I would like to thank Grant Joung, Kraig Parkinson, JK Werner, Gareth Morgan for providing feedback on the article.
Void is a delivery model that focuses on the agile principles, providing a loose set of practices.
Void looks at value at every stage, activity and experience. It provides a framework for connecting organization goals, vision, initiatives, along with technology and architecture roadmap to an effective delivery mechanism to realize value sooner. It also provides a new set of vocabulary to manage delivery; one focused on customer value and value creation.But before we delve deeper into the how Void delivers value, let’s consider how we got here.
Over the past 15 years, companies have been hopping on to the agile bandwagon and been customizing agile practices to suit their organization structure, in the hope that practicing some of the processes would bring change into the organization. But in the process of adopting the practices, many of the principles of Agile Methodology have been forgotten. Even though the principles are still relevant today—for instance, responding to change over following a plan—we see so many organizations wanting to adopt agile, but they’re stuck with ‘ceremonies’, unable to question their practices.
These ceremonies have become a bottleneck: an excuse to follow pre-defined practices, while agile principles are quietly ignored. Incentives and motivations are too tied to adopting the practices that have encouraged a checklist culture. This culture ensures teams follow certain ceremonies in a cadence—without considering the value that the software delivers to the customer or the long-term impact of not resolving deficiencies in the systems.
Practices have killed the principles
Practices have created a false sense of security and comfort to agile development because they are nominally based on agile principles. As these practices have become ingrained in the way of work, it has created a set of vocabulary which is focused on process optimization and less on value creation. The language we use is shaping how we approach agile—and it’s not always to the benefit of our projects.Language used on a day-to-day basis influences our thinking, which in turn affects our behavior. So if we are to change the behavior, it helps to start by changing language.
Some of the standard agile practices like Iterations, Velocity, Release Planning, Technical Debt have permeated the industry; people have become familiar with the terms and practicing these ceremonies has become how we talk about managing delivery.
Iterations
A timeboxed repetitive approach to building software is an additional artificial constraint that limits our ability to deliver value within with a given time. Teams often struggle to define the value to be delivered within a fixed timebox. The focus of the conversations has been on what scope to deliver within this artificial time constraint, rather than the value produced and how value can be realized quicker.
When a team is not able to fit the next valuable deliverable within the timebox, they scramble to identify what else the team can work on within the given timebox. Instead they should work on the next most important value quotient, such as one that addresses a customer's critical migraine problem or an underserved outcome that improves the market position for the company.
Velocity
A team of developers, quality analyst, product owners come together and beat the story to death, endless debates about what acceptance criteria are missing, and then comes the interesting part, the 'sizing'. Teams dread the experience of going through sizing and coming to a consensus on what the size of the story should be. How to split the stories to keep it in small chunks? Most of the time the person who has the most convincing skills wins the argument and the team members—either out of fear or not wanting to constantly argue—accept a size whether they believe it or not. Ultimately it comes down to the gut sense of how “long” a given story is going to take to get it done. While the correlation between size and the time taken to deliver can be significantly different, we get a false sense of comfort in our ability to predict the time taken to deliver a given scope within a given period with accuracy. We can also debate that maybe the teams have not done relative sizing and sizing is different from estimation. Whether we do relative sizing, estimation, break down stories into equal sizes, or the new buzz phrase “No Estimates”, ultimately it comes down to a discussion of process optimization and predictability in delivery, rather than identifying the customer’s value the given need will deliver, what pain points or underserved need will be tackled, how to experiment the change, how to measure, and what we have learned as a continuous experimentation loop.
Figure 1: the experimentation Loop
Tech Debt
Tech Debt is too often an excuse to not address a growing developer concern. It crept in as a way out of dealing with a problem, but it steers the focus onto delivering a given scope within the timebox. Ultimately, over a period the team accumulates enough Tech Debt that it move at snail's pace or need to re-architect the system as it is not extensible enough, or the software is developed with poor quality standard. Tech Debt has become a serious value inhibitor by itself, and a very negotiable deliverable severely affecting the developer experience.
Figure 2: The Tech Debt Wall - Value vs. Effort
Most of our practices have emphasized improving the way we work. This itself is not bad but the language has seriously restricted our thought process—and that has immediate consequence regarding our behavior, our decision making thumb rules, the desired customer outcome and the value delivered.It is time to shed our limiting vocabulary and model, and instead adopt methodology that focuses on the principles and on customer value, improving developer experience, and less on the ceremonies.
Time to rethink our vocabulary and delivery model
Our day-to-day language and model should emphasize three basic principles:
Customer and Value Sandwich
The emphasis is on understanding the customer, pain points, underserved outcomes and how to realize the value sooner.
Figure 3: The Customer and Value sandwich
Organizations can amplify the impact and realize the value sooner, by encouraging a culture of experimentation and learning, and greatly improving the developer experience in building the capabilities. What does that model look like? It’s time to explore Void.
Value-oriented incremental delivery model
The Void model focuses on: value at every stage; activity and experience; and connecting organization goals, vision, initiatives—along with the technology and architecture roadmap—to an effective delivery mechanism to realize value. It also provides a new set of vocabulary to manage delivery, one focused on customer value and value creation.
Figure 4: The Value-Oriented Incremental Delivery Model
As your organization moves towards developing a more outcomes- and value-based portfolio, and as you start translating and executing your organization vision, it is important to ensure the teams have good clarity on the customer value and what kind of impact it has on the customer.The Value Quotient helps us understand the actual value associated with an initiative or feature. The pain point attribute helps to visualize the value regarding whether the given quotient helps address a Migraine Problem for your customer, or is it more focused on addressing an underserved outcome —one which will improve market capitalization.
The Underserved Outcome reveals a market that is in need of a solution—this helps customers get the job done better. It represents opportunities for growth, whereas the Migraine Problems reveal the biggest pain points for the customer to leave.
Once you have attributed your value quotient and the pain point, visualizing the value quotient against a set of platform capabilities helps prioritize the value quotient against delivery.
- Is there a high-value customer migraine problem which can exploit existing platform capabilities to solve the pain point?
- Is there an underserved customer outcome which can leverage existing platform capability to make a significant impact on improving the market capital?
- How should the platform evolve, experiment and explore capabilities which help address the deepest of customer problems and address the underserved outcome?
Figure 5: Value quotient versus platform capability
As you start prioritizing the value quotient through the value funnel, identify the blocks for experimenting with the value quotient. The value quotient should have a well-defined hypothesis on what the value is. How are we going to experiment? And how the value will be measured?The duration of the experimentation block is determined just in time before the start of the block. The teams should conduct ‘team juggles’ to determine the next value quotient they want to tackle, the duration of the experiment block, how to facilitate the experiment, and what support is needed from the rest of the organization to amplify the impact of the value.
Figure 6: the value funnel
In a typical environment, where there are multiple experience teams working on different value quotients, sometimes the value quotient acts an amplifier for the value delivered by another experience team. Identifying the elasticity between the values help understand the limitations and stretchability during the juggles. That is useful when determining the value quotient that the team needs to address next.Every value experiment block is followed immediately by a value review. This helps evaluate the experiment based on the measures identified and the impact created. The learnings are taken into consideration in adjusting the value quotients and the experience appropriately.
Conclusion
Value creation should dictate what practices to adopt to amplify the impact. Focusing on improving the developer experience—along with building a culture of experimentation and learning—fosters creativity, stimulates innovation and enables delivering value incrementally and rapidly. Principles over practices bring the focus back to the customer value creation. This change in language and vocabulary helps shape thinking, and thinking affects behavior.
I would like to thank Grant Joung, Kraig Parkinson, JK Werner, Gareth Morgan for providing feedback on the article.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
