The commercial software product development became popular at global level with the introduction of PCs (i.e., Personal Computers) in the 1980s and received a strong boost when Internet was recognized as the de facto playground of the future products in the late 1990s.
When in 2001, the famous seventeen experienced software developers met at a resort in Snowbird, Utah, to discuss a better approach for software development, the level of frustration from the high rate of failure in software projects using the Waterfall method, has already hit sky high levels.
Waterfall, being the traditional work management method of the past centuries, uses a sequential, long-duration chain of activities that must be completed one after another before the products could hit the market, try to generate revenue, and collect feedback on its performance.
This means that the software teams would start with a snapshot of what would have been a good, marketable solution for the customers at the time of inception, and then stay away from the market for several months, trying to implement that snapshot of an idea, and hope it still will be valid when they would go to the market months after.
As the experience has shown everyone, this has barely ever been a completely successful approach, as the market (and customer’s interests and expectations) would change over time!
The Waterfall approach would have been more successful and relevant in the time before internet would connect the people around the world and allow them to share opinions and ideas and form interest groups and discussion forums (which were the ancestors to the social media outlets that later came into existence and created a 24/7 connectivity at the global level, where any idea or opinion can be received by millions in a few seconds).
In 2001, things were already changing fast at an accelerated level and no company could afford spending months chasing a solution that would have solved a problem that may no longer exist – or may have changed a lot – by the time the product was deployed to the world outside.
A lot could happen between the capture of the brilliant idea and turning that into a product that customers would like to pay for.
- New trends could form at any moment on the social media, creating new appetite for something new and / or cause dislike towards an existing one.
- Competitors may emerge with a better and new product (or even the same products) much earlier and take away the market share we were hoping to get.
- Economy could slow down and inject fear in the wallets of customers who are now reluctant to spend their hard-earned money on our product.
- Government regulations, international trade restrictions (or clashes) and compliance enforcements may show up on the horizon and limit, change or take away the market access for the product.
It is important to note that during the 1990s some lightweight software development methods were introduced and experimented with, trying to shorten the time-to-market and to find ways to establish short feedback cycles. To name a few: Rapid Application Development (RAD), Unified Process (UP), Scrum, extreme programming (XP).
The decade long experimentation with these methods had created insights for the methodologists and it was time to get together and summarize and formulate them.
That is why in 2001 the “Manifesto for Agile Software Development” (or “Agile Manifesto” for short) was signed to declare and promote a new way of thinking and approach in software product development, that would put focus on where it would matter more and raise attention to the need to appease the customers and involve them as early in the product development efforts as possible.
The Manifesto had 4 main value propositioning statements, two of which we want to consider in this article:
“Value working software over comprehensive documentation”
“Value customer collaboration over contract negotiation”
Agile Manifesto was followed by 12 Agile Principles to provide more insights on the main 4 Values, among which we would also like to pay attention to the following:
“Customer satisfaction by early and continuous delivery of valuable software.”
“Working software is the primary measure of progress”
This created and promoted the concept of “customer centricity” in the entire product and service delivery cycle, from ideation to production.
The Agile frameworks use an iterative, incremental, and evolutionary approach by breaking apart an idea into groups of releasable sets of features called “Minimum Viable Products” or MVPs which are releasable software products with a subset of meaningful / useful capabilities that we expect the customers to like and pay for.
MVPs allow the teams to enter the market much faster compared to a Waterfall approach of completing everything in scope at each stage before being able to create a final product.
The early engagement with the customers helps the teams collect feedback on the interest that the new release has created in the market and see what customers have liked or disliked about it and use that information to fine-tune their next release with a closer response to what they believe will be liked even better this time. They avoid long development durations (i.e., large deliverables) to stay as close to the market and follow its changes as tightly as possible.
Any new products that are introduced to the market will incrementally grow through the MVPs and will follow the needed evolutionary change to mount up to a better match to what provides the best value for the customer.
As it would be expected, the adoption of Agile methodology and its frameworks had a very slow start as many organizations had just finished excelling at Waterfall and have created their Project Management Offices (PMOs) and tons of documentation and gating and sign-off procedures and were quite reluctant in experimenting with something so radically different that would need them to start pushing ideas out as early as possible and incrementally delivering parts of the scopes using self-organizing teams.
As the adoption ramped up and thousands after thousands of organizations started struggling with understanding the practical side of Agile values and trusting their Agile teams and looking differently at how they should deliver products and services, so came the understanding of some fundamental challenges to the way Agile methodology is looking at the concept of value.
Let the confusion begin!
Having a group of “software developers” define value as embedded in the Agile Manifesto had the intrinsic limitation of only considering the customer’s perspective and missing what it would comprehensively mean to the business side, which coincides with what it means for the entire organization.
From a software development team’s perspective which has adopted Agile approach and now wants to collaborate with its customers in the outside world through engaging them in short feed back cycles, created by deploying MVPs – based on what would be most valuable to those customers - and pushing them to production environments, this was the easiest and most natural definition of value.
As Agile methodologies’ popularity rose and organization started growing the number of their Agile teams, the complexity in synchronizing the work towards joint releases led to creation of Agile scaling frameworks (such as SAFe® or LeSS®) to expand the adoption across entire organizations, regardless of the number of teams and the size of the enterprise.
One would have hoped that by now the problem with having a one-sided view into the concept of Value, should have become very visible to both the organizations using them, and the founders of those scaling frameworks, but it would take a good decade before the equivalency of “Customer Value” and “Business Value” pose as an issue.
The simplistic structure of Value Delivery in Scrum or Kanban teams dictated that the Scrum’s Product Owner [PO] (or Kanban’s Service Request Manager [SRM]) act as the sole point of contact for the development team into the business side.
PO/SRM is given the authority to decide on “what is considered valuable, and when it should be delivered?”. PO/SRM is expected to represent the “business” for the development team.
This would have even worked fine for small companies where their PO/SRM was part of the founding team and would be involved in the strategic steering of the organization as much as providing the “business” directive to the team and negotiate with them on what they should and can deliver and by when, to reach the customers as a valuable product or service.
Larger companies soon realized that no PO/SRM can single-handedly work through layers of business, understand what they are trying to achieve and decide on what sub-component of that relates to his/her team. There was also the need for synchronizing the work with other PO/SRM members in a joint effort towards larger deliverables, managing the internal and external dependencies.
That is when Product Management that Scrum and Kanban had tried so hard to get rid of, came back to the picture and the Agile Scaling solutions started embracing them as the inseparable part of the flow of ideas from the business side to the development teams.
The come back of Product Management to the picture led to the discovery of the hidden bias in favor of “Customer Value” and its long-lasted confusion with the “Business Value”.
The Re-definition of Business Value
When the leadership of organization noticed that their Agile teams considered delivering “Customer Value” as their ultimate mission, while from a pragmatic perspective it did not necessarily always match what the enterprise considered a “Desirable Outcome” (i.e., having “Business Value”), a new wave of push backs against Agile adoptions started.
The natural panic that came after, slowed down the adoption of Agile in many organizations and led to wide-spread alteration of Agile methodologies, calling it “their own customized Agile way of doing things”, which could mean anything from painting their Waterfall approach with a new color all the way to using a Waterfall release structure and using Agile frameworks to cage the teams into fast tracked delivery of the work.
Some pushed Agile adoption under the PMO and gave it fancy – yet contradicting and meaningless - new names like Agile PMO. Some organization switched to a “pretend Agile” framework where the management would decide what their Agile teams need to do and then “nicely” dictate that to the PO/SRM folks to bring it to the team and push it to their plates in every planning event.
The reason behind the fear of losing control was that ultimately, for a business to survive and grow, the output of the development teams must generate more of the business outcome that has business value for the organization, and most cases the business outcome is generated through delivery of customer value to the organization’s clientele, but not always!
Some scenarios would be:
- Just because customers love and surely need something, it does not mean it would be feasible for the organization to create and provide it.
- Just because the organization can deliver something specific that customers love and surely need, does not make economically sound and viable for the organization to sustain the product / service in the market.
- There may be strategic decisions in the organization to let go of certain products and services loved and surely needed by some of their customer to use the resources to initiate another line of product and service.
To add to the panic, the organizations also noticed that there is no hard and fast rule on the definition of business value. At this point they had discovered that “Customer Value” and “Business Value” are not the same thing and now the latter was not even clear enough to standardize.
It is also not clear how to define business value for startup companies that do not yet have a well chiselled business model in place. Same can be told about new product and services that are at the early stages of market exploration and MVPs.
How we decide which deliverable has more business value is also not sitting on a straight line. Selling the services and products at one end generates revenue for the organization but calculating the total cost of creating, selling, and maintaining it is a beast of its own.
From direct cost of teams to the opportunity cost of not doing something else, a multi-layered complex costing model needs to be created and tested against the balance sheet to figure out the value that organization actually obtained.
The Scaled Agile Framework (SAFe®), which is the most adopted Agile scaling framework (with 70%+ adoption rate among the Fortune 500) has recently added a set of business agility metrics with one of them focusing on “business outcome”, which is expected to answer the given question “do our solutions meet the needs of our customers and the business?”. It then describes it as measuring whether a development effort has produced the “desired business benefit”. Then in the examples provided we can see relevancy to actual business outcomes (e.g., Net Promoter Score, Cost-per-Ticket, Inventory Turns, Units Sold, Conversion Rate …) and barely any metric that measures customer value anywhere.
At the time of this writing, there is no Agile scaling framework that has shown any attempts to formulate a relationship between “customer value” and “business value”.
It seems like they all have been tiptoeing around the subject awaiting some solution to eventually rise in the horizon so they can plug into that but the resulting complexity from the diversity of organizational structures and market sectors have proven too difficult to surmount so far.
The Agile Manifesto brought the idea of focusing on customers and delivering what they would find valuable. It then caused a general confusion assuming what customer finds valuable is essentially what business renders as valuable and all an Agile team needs to focus on is to deliver “customer value”.
This confusion has led to a general panic at business management level, leading to a wide-spread benevolent dictatorship structure in many organizations where Agile teams are handed over what they should deliver (and not what they believe makes best sense) and they are functioning like high-output development teams stuck in a never-ending nightmare of a Waterfall project.
Even Agile scaling transformation in some organization had led to creation of a new level of “Command and Control” with attempts at pre-planning the entire fiscal for the Agile team by best guessing what would have the highest business value, forming an painful year of planning and re-planning to accommodate the barrage of inevitable changes that would happen throughout a year pushing around their planned deliverables over and over.
The work on finding a way to formulate the relationship between “customer value” and “business value” has not yet led to any Agile resolution that can save the current situation for organizations. One reason being that “business value” can be different for any organization and is hard to structure for newly started companies or new lines of products and services.
While the methodologists and business product management are looking for an approach to connect the dots and calm the panic and allow the encaged Agile teams move towards becoming true self-organizing teams delivering “business value” through their obsessive “customer centricity” and “customer value” delivery, we can hope that the accelerating market changes and the need for quick responses would allow for a better idea-to-market flow that would ease the pressure on the development teams in engaging customers in short feed back cycles.
Exclusive pmmagazine.net 💬
Enterprise Agile Transformation Coach, CIO and Chief Data Scientist
Arman Kamran is an internationally recognized executive leader and enterprise transition coach in Scaled Agile Delivery of Customer-Centric Digital Products with over 20 years of experience in leading teams in private (Fortune 500) and public sectors in delivery of over $1 billion worth of solutions, through cultivating, coaching and training their in-house expertise on Lean/Agile/DevOps practices, leading them through their enterprise transformation, and raising the quality and predictability of their Product Delivery Pipelines.
Arman also serves as the Chief Technology Officer of Prima Recon Machine Intelligence, a global AI solutions software powerhouse with operations in US (Palo Alto, Silicon Valley), Canada (Toronto) and UK (Glasgow).