Making Products That Matter: How Value-driven Development Accelerates Your Teams

Abstract

An increasing number of businesses are seeking new Agile ways to deliver valuable products to their customers. However, many companies that adopt Agile principles soon experience early indicators of struggle, such as starting development before the value to the end user is fully understood or delivering products that are not done. These problems limit the ability of organizations to create value for both their end users and the company. The purpose of this article is to share our experience as practitioners on a range of Agile development practices from a value-driven perspective. Common blind spots are highlighted and the value-driven principles that enable development teams to sustainably create value are explained. Our experimentation with various improvement approaches has provided insight into value-driven principles and the framework that interconnects these principles. This article describes the value-driven framework (VDF) as a methodology developed by practitioners for businesses that struggle to enable their workforce to increase the value of their products. The VDF provides an approach to overcome these struggles in a four-step process: (1) explore to find opportunity, (2) discover the most valuable next step, (3) experiment to try-out and learn, and (4) value will emerge as a sustainable user benefit.

Keywords

Value driven Agile development principles user practitioner

Introduction

Many organizations that decide to adopt Agile methodologies to increase value to the end user do not grasp that the transformation process is more about a shift in mindset and culture than changing the way the development teams work. As a result, these organizations fail to create significant additional value for their customers. A common approach is to provide a training programme for all individuals involved in development activities, to create Scrum teams, to appoint key roles and to declare the transformation to be completed. However, there is a misconception that the transformation towards agility is simply about changing the way the organization works and learning how to implement Agile methodologies rather than changing how the organization thinks and learning to become an adaptive and learning organization.

Indications of emerging problems are individuals having trouble adjusting to their new roles, teams needing considerable time to adapt to their new responsibilities, and management struggling to let go of old habits of governance and control. The consequences are typically a serious reduction in productivity and a decrease in valuable output. This article aims to share our learning as practitioners to help businesses identify blind spots and factors associated with becoming an adaptive learning organization that continuously improves its ability to create sustainable end user value.

Mini Case Study

A scale-up company¹

The company name is known by the Guest Editor of this journal.

developing smart energy solutions agreed they needed to split their growing workforce into smaller, more effective teams and decided to transform into an Agile company using Scrum methodology. The entire development staff attended an Agile training course addressing Scrum development practices. In the next step, the system development team was restructured into smaller component-based development teams and key roles such as product owner and Scrum master were appointed. However, it quickly became clear that many developers were struggling to adjust to their new roles. Furthermore, some teams experienced internal difficulties and faced even greater problems when interacting with other teams to identify interdependencies. The outcome was a greater fall back in productivity and output after the initial adjustment period than anticipated, which caused unrest amongst the management and stakeholders. Therefore, the management decided to hire Agile coaches to speed up the transformation process. The coaches’ job was to guide the teams while they adjusted to the new Agile methods in order to improve efficiency and increase delivery. The Agile coaches had mainly gained experience as Scrum masters in other Agile development companies, so they had a good knowledge of how Scrum should be applied successfully. However, the coaches lacked an understanding of the stepwise experimental process that companies must go through to learn to find their own Agile methods. Agile coaches commonly focus on velocity, which is a measure of the amount of work a team can do during a development cycle. The downside of this approach is that it emphasizes internal processes and output and overlooks value from the end user’s perspective. Anything that does not directly contribute to an increase in team velocity is minimized as much as possible. The result is an increase in output, but not in the value to the end user when the output is delivered. Additionally, the product owners gave the teams backlog items to work on that the teams did not understand. Some of those items did not make sense at all from the teams’ perspective, especially because the user stories that were described by the product owners potentially overloaded the system without adding much value. The development teams proposed to first investigate and solve problems causing instability and loss of performance before developing any new features. However, the product owners considered this proposal to be of much lower priority than developing new requested features. This issue is an example of a blind spot that potentially leads to the destruction of value due to loss of reliability, performance or service.

Companies that decide to immediately focus on team velocity when adopting Agile processes risk their developers becoming disconnected from their purpose. Another downside of focussing on velocity is that it encourages a variety of shortcuts that may cause technical instability and an inability to maintain performance in the long term; this scenario is usually termed technical debt. A significant loss of stability, system performance, user friendliness or even a denial of service may reduce value to the end user and ultimately lead to a loss of customers, and even cause irreparable value destruction.

Value-driven development was created as an alternative path for companies that aim to transform into Agile and learning organizations and is based on ‘outside-in thinking’ that starts with the end user in mind. Development teams need to understand why and how a change may increase value to the end user before they can start speeding up development cycles, otherwise they will ‘get it done’ but they won’t ‘get it right’ (see Figure 1).

Figure 1.

Source: Author’s own.

The Origin of Value-driven Development

The concept of value-driven development evolved gradually. The first principle in the Agile manifesto states: ‘Our highest priority is to satisfy the customer through early and continuous delivery of valuable software’ (Agile Manifesto, 2001). The term value-driven development was first used by Tom Gilb in his publication ‘Value Driven Development Principles and Values’ (Gilb, 2010), in which he described ten Agile values, which encompass simplicity, communication and courage to deliver the stakeholder value. Gilb criticized the Agile community for being too programmer centric and paying too much attention to just producing working software. He stated: ‘We can deliver software functions as defined in requirements, but totally fail to deliver critical value to many critical stakeholders’. Nicolas Gouy also used the term in his book Agile with Guts, A Pragmatic Guide to Value-driven Development (Gouy, 2014) and referred to a definition used by Tom Gilb: ‘Value is perceived benefit: that is, the benefit we think we get from something’. In this article, it is stated that features should add value to users else they should be cleaned up. The interest in value creation has continued to increase; however, a number of different interpretations are used. The bottom-line of value creation is that the benefits outweigh the effort or cost.

The value-driven development approach described in this article was inspired by test-driven development (Beck, 2003). Test-driven development adheres to the ‘Shift Left’ principle, which aims to shift the testing effort to the start of the development lifecycle, when test activities are potentially most valuable as they can accelerate development through collecting valuable data and solving defects as early as possible. The cost of removing defects increases significantly during the later stages of the development life cycle (Boehm in Bird, 2013). In the remainder of this article, we describe how our experience as practitioners has enabled us to develop and refine a framework for value-driven development.

Value Over Quality

Value-driven development is about making products that matter to end users; a key aspect is that the products are actually being used, valued and significantly impact the lives of the users. Most developers initially focus on the technology and their own skills to develop a working product that they expect to be used and valued. Value-driven teams follow the completely opposite approach, as they start exploring how the users work instead of how the technology works. They start interacting with the end user in order to understand why products matter. Value-driven teams think ‘outside-in’ to obtain a sense of purpose and connect them with what they do. They aim to deliver benefits as soon as possible and learn how much value the features actually provide to users as fast as possible. User feedback enables value-driven teams to continuously take the next most valuable step. In contrast, technology-driven teams explore technical innovations to develop and deliver new working products. Product-driven teams strive to deliver new features to extend the capabilities of working products. Quality-driven teams aim to deliver high-quality attributes that enhance the capabilities of products. However, working products of high quality are pointless if they are not being used or valued by users. Value is something of a user’s perspective. Quality is much more of a product perspective. Thus, teams need to avoid the trap of increasing quality while reducing value (see Figure 2).

New high-quality features can often be meaningless to users; such features can be viewed as ghosts that float in the system without purpose. However, new features of low quality may provide alternative solutions that are highly valued. Moreover, quality issues (or bugs) that do not significantly bother end users can exist within features that users do value. Any effort invested in features that are not valued can be considered a waste of time and money. However, when new features of limited value introduce serious issues, they may foul up the entire product. Such features can be regarded as garbage and must be cleaned up as soon as possible before they lead to considerable destruction of existing value (see Figure 2).

Value-driven Teams

Value-driven teams need a wider range of skills than common development teams. Some team members need to be able to interact with and build relationships with end users. Other team members should specialize in testing so the team can collect valuable data to accelerate the entire development effort, and some members need to focus on maintaining the operational value of the products. Thus, value-driven teams are much better equipped to create value, as they can directly connect with the end users and avoid handovers that may result in a loss of information. Value-driven teams make sure they understand the problem before they start working on a solution; they want to ‘get it right’, before they ‘get it done’. Developers that understand their users and see the bigger picture have a clear advantage in terms of delivering value to the end user. Without understanding Why²

Simon Sinek explains the concept of the golden circle that starts from the inside out in his book Start with Why. Inspirational messages start with ‘why’. This is the reverse order of messages that start with ‘what’.

(Sinek, 2009) change is needed and How it will be used, it is virtually impossible to deliver valuable solutions that matter and provide real benefits to the user. Management have the task of facilitating and supporting development teams to enhance their value creation capabilities.

Figure 2.

Source: Author’s own.

Value-driven Principles

Principle 1: Understand Why Products Matter

Products that help to improve the lives of users are products that matter. To identify which improvements are valued by users, it is vital to interact with and to understand real users’ requirements. Traditional development teams rely on the product owner to provide user stories and answer any questions they might have. However, this approach always carries the risk of a loss of details when information is handed over. Development teams that have the opportunity to directly interact with end users have an advantage, though these teams need a different set of skills. Technical development skills are typically preferred over any other skill. Most developers prefer to deal with the technology, as that is what they do best. In contrast, value-driven teams are aware they need team members with the capability to reach out and connect with end users, in order to communicate effectively and build relationships. Such interactions boost the ability of the team to get the product right. Value-driven teams prefer to interact with their users, as it connects the team to what they do and prevents them from wasting effort. The time and money required to understand why products matter is a fraction of the effort required to develop a product without user input and modify this product over and over again until it is finally right.

Principle 2: See the Bigger Picture

User Story Mapping (USM)³

User Story Mapping is a natural, intuitive lightweight best practice that is captured beautifully by Jeff Patton in his book User Story Mapping (Patton, 2014).

(Patton, 2014) is a lightweight, intuitive method that helps development teams to visualize the bigger picture and provides clear advantages when interacting with real end users. At the start of a USM session, a user will be asked to tell a particular user story and to explain the situation and the steps that lead to the desired outcome. Visualization of the steps within this story forms the backbone of the user story map. In the second step of USM, participating users are asked to brainstorm user stories they value, and these stories are used to build the user story map. In the third step, user stories of higher value are placed on a higher position on the map. The overview that emerges from USM helps developers to obtain a bigger picture of possible user story combinations that are meaningful from the users’ perspective. The fourth step of USM is to identify the minimum viable product (MVP). User stories can be assessed in terms of user value and development effort to identify the most valuable MVP. Conventional Agile teams do not commonly interact with users when creating a story map, rather the team starts by developing user stories from the top of the backlog. However, many conventional product-driven Agile teams face the problem that the backlog does not help them to identify the dependencies between related user stories. Teams complain about this issue, as it limits their ability to propose smart solutions that are valued by the user (see Figure 3).

Principle 3: Discover the Most Valuable MVP

The MVP⁴

Frank Robinson first described the minimum viable product (MVP) in 2001 as follows: ‘Products without required features fail at sunrise but products with too many features cut return and increase risk for both vendor and customer’.

(Robinson in Murphy, 2017) is the earliest possible deliverable product that would be valued by users. However, discovering the MVP is not an easy task. When Frank Robinson defined the MVP, he stated that ‘Too large or too small a product are big problems. The MVP is the difficult-to-determine sweet spot between them’. Products that are too large are expensive to create, take too long to develop and the user feedback required to confirm their value is as intended is provided too late. In contrast, products that are too small are not significant and will not be valued or probably even used.

Users must participate in the discovery of the MVP as they can estimate value, while experienced developers can estimate effort. The aim is to discover the most valuable change from a user perspective that can be developed with minimal effort. When the MVP is identified and agreed upon, the focus for development becomes clear and the user will know what to expect. Another benefit of identifying the MVP is related to mindset. Users frequently tend to demand many more features than they actually need in the hope of obtaining some value; however, this risk-adversary behaviour results in the exact opposite of what was intended. The ability to limit ambition is an advantage, as higher demand is harder to deliver, will cost more and take longer.

Figure 3.

Source: Author’s own.

Principle 4: Provide Key Examples

Understanding how the product will be used is crucial to the delivery of valuable solutions. Asking users to provide usage examples—a practice known as ‘Specification by Example’⁵

The book Specification by Example by Gojko Adzic describes the best practice for specifying the product. The examples have double value; they are usually the best possible test cases that prove the product does what it is supposed to do.

(Adzic, 2011)—is a lightweight and effective approach. Questions related to usage are most relevant from a testing perspective. Key usage examples represent the best possible tests to determine whether a product will be valued and are the equivalent of a ‘test ride’.

Principle 5: Build Tests to Collect Data

Test-driven development⁶

The American software developer Kent Beck is credited with invention of test-driven development. He claims he ‘rediscovered’ the practice in 2003.

(Beck, 2003) is a (software) development practice in which a test set-up is initially designed and developed to collect data on product behaviour under various circumstances. In fact, every step of the development process may actually benefit from the availability of such tests, as the tests can be executed as often as required. After a test is successfully developed, it can be expanded to test different aspects and support further steps of development. The iterative process of developing tests and developing products accelerates the ability to create value. The direct benefit of first developing a test is that it helps teams to focus on one development step at a time, without worrying about potential errors. The tests enable errors to be detected early, which provides confidence and makes room for creativity that may result in unexpected valuable solutions.

Test-driven development is the complete opposite of the approach followed by most developers. Many developers claim they want to improve their testing and implement test-driven development, but just do not have the time. Such developers generally rush to start and rush to deliver.

The Wright Brothers’ Example

The Wright brothers’ real breakthrough was their invention to control an aircraft in flight. The brothers followed a different approach and had a unique vision to their competitors; they started with a clear understanding of Why (Sinek, 2009). Their knowledge of bikes—and how they can be controlled in an apparently miraculously balanced way—gave the brothers valuable visionary insight that helped them to solve the aeronautical puzzle. At the start of their development activities, they built a small wind tunnel that they used to test wings and propellers. This helped the Wright brothers to collect accurate data that enabled them to develop good working airplanes and accelerated the entire development process overall.

Principle 6: Set Development Teams Free

Value-driven teams need to be able to explore and experiment with as few distractions as possible to tap into their own source of creative energy and enhance their capabilities.

Their own discoveries will inspire them, especially when they can work without being afraid of making mistakes. An environment that encourages experimentation and learning from failure needs to be established by modern facilitating management approaches.

Software Development Example

Continuous Integration/Continuous Delivery (CI/CD)⁷

CI/CD is not further elaborated in this article as it is mostly a software development topic. Martin Fowler provided an insightful description of continuous integration, that can be retrieved at https://martinfowler.com/articles/continuousIntegration.html

is a valuable innovation that enables developers to integrate and test their code changes as often as needed and obtain immediate feedback. Additionally, the CI/CD pipeline can be configured to trigger various automated activities that support deployment and delivery tasks. This type of development support can free developers from such distractions and enable them to explore and develop valuable solutions.

Principle 7: Assemble the MVP

Teams that need to collaborate to develop a MVP must identify a way to work together effectively. In order to assemble the MVP, the product owner of one of the teams must take ownership over the end-to-end integration process to ensure the integrated solution will work as agreed. Otherwise, integration issues may lead to a loss of perceived value and confidence, which are not easy to restore.

Principle 8: Release the MVP Continuously

Value-driven teams strive to release value as early in the development cycle as possible so users can benefit at the earliest time point. This shortens the feedback cycle and the time required to recoup investment costs. More importantly, value-driven development focusses on taking care of the customers; it is important to consider all aspects that contribute to the value perceived by users and provide users with options and a sense of control.

Principle 9: Collect Feedback from Users on Value

When development and operations are united in DevOps teams,⁸

DevOps is credited to John Allspaw and Paul Hammond who delivered the presentation 10+ deploys per day: Dev and Ops cooperation at Flickr at the O’Reilly Velocity Conference in 2009.

these roles balance and reinforce each other. Operations have access to valuable operational data or intelligence and know the weak links in the product in the operation and how users operate the system. Ideally, operations should have a feature heat map that visualizes actual usage behaviour in real time, which could provide insight into the frequency of feature usage as well as other behavioural patterns. An abundance of valuable data can be retrieved from a feature heat map. When a new feature is launched, wouldn’t it be exciting and useful if its usage could immediately be viewed by the developers? Thus, continuous monitoring (CM) is a valuable extension of the CI/CD pipeline.

Principle 10: Clean up Waste and Restore Destruction

The closing step of the development cycle is to make sure the value created is sustainable. In practice, developers rarely consider cleaning up features that do not add value. A lot of time and effort was invested to deliver those new features, which makes it difficult for developers to discard these components. Nonetheless, clean-up of useless features must be considered to prevent destruction of the value to users. Useless features take up space and capacity and potentially lower performance, usability and maintainability, it is simply garbage code that needs to be cleaned up. Thus, continuous clean-up (CC) is the final extension of the pipeline. This survival of the fittest features is very much a cruel evolutionary game; the responsibility for killing their ‘darlings’ lies with the creators. However, if the developers value their users over their creations, then CC is probably not that hard at all.

Amusement Park Example

If an amusement park installs an attraction that draws no visitors, despite all attempts to promote it, the attraction will be removed. The operating costs will not be earned, and the attraction will take up valuable space that could be utilized by other attractions that will be visited and contribute to revenue.

Table 1.

The Value-driven Framework

Value-driven Framework	Principle	Method
Explore opportunities	1. Understand Why Products Matter	End User Orientation
Explore opportunities	2. See the Bigger Picture	User Story Mapping
Discover next step	3. Discover the Most Valuable MVP	Slicing & Merging
Discover next step	4. Provide Key Examples	Specification by Example
Experiment to learn	5. Build Tests to Collect Data	Test Driven Development
	6. Set Development Teams Free	CI/CD + Test Automation
	7. Assemble the MVP	End-to-end Integration
	8. Release the MVP Continuously	Release Management
Value emerges	9. Collect User Value Feedback	Continuous Feedback
Value emerges	10. Clean-up Waste & Restore Destruction	Continuous Clean-up

Source: Author’s own.

The Value-Driven Framework

We developed the value-driven framework (VDF), a cohesive set of iterations inspired by the Kata Improvement Cycle⁹

Mike Rother’s research at Toyota was first published in the book Toyota Kata and resulted in the Kata improvement cycle, which is based on scientific thinking and can help individuals, teams, and organizations.

(Rother, 2017). The framework is lightweight, easy to understand and can be applied throughout the entire development life cycle by most development teams without extensive study. In our experience, most developers want to explore new opportunities and, in doing so, they will discover potentially valuable next steps. Experiments designed to collect data result in sustainable learning and valuable outcomes will emerge.

Conclusions

This article shares learning from practitioners to help identify blind spots and the factors that contribute to creation of sustainable value for end users in an ever faster-changing environment.

Many organizations fail to acknowledge that the entire organization needs to be involved in the Agile transformation process in order to improve their ability to create value in a sustainable manner.

While most Agile coaches focus on team velocity and output of deliverables, the VDF provides a simple, logical four-step alternative. Development teams must start with a value-driven mindset, with a focus on increasing value for end users in a sustainable manner. When teams explore the feasible opportunities, continuously identify the most valuable MVP and repeatedly experiment to collect valuable user data, value will emerge either as success or as a learning opportunity. Both success and learning are valuable, sustainable outcomes that lead to the next opportunity to explore. This four-step value-driven approach can support the development of organizations, teams and individuals that strive to increase their value-creation capabilities. However, to start with the end user in mind, teams must be able to establish and maintain contact with end users. Teams that regularly interact with real end users and listen to their user stories have an advantage, as they can collectively explore opportunities and pinpoint the most valuable MVP. This helps to avoid the creation of too small and insignificant products or too large products that require too much effort. Management must facilitate and support their teams in becoming customer-facing teams that establish lasting relationships with their users. This includes hiring team members with skills to communicate and connect with end users. Additionally, it is of the utmost importance that leadership support and trust their teams to do the right thing; well-balanced DevOps teams are truly self-organizing. The main benefit is that self-organization boosts the ability of teams to take ownership over the value to the end user.

Development teams should also be encouraged to experiment. Actively monitoring and rewarding failure is a counter-intuitive measure that is actually beneficial. Teams that do not fail either do not experiment enough or cover up their failures, which limits opportunities to share learning. Experimenting helps to build the value-driven mindset. Test-driven development is a method of experimenting that helps to accelerate the entire development process. Many developers acknowledge the benefits of this practice, yet do not find the time to develop a test to collect system behaviour data from the start of the development cycle. This is where the encouragement of management and provision of the required resources can make a difference. Indeed, the VDF approach can help teams identify the most valuable TDD step, which helps to accelerate the entire value creation process. The final step of the VDF is to continuously collect and process user feedback on perceived value. This real-life feedback provides optimal learning and accelerates development teams’ ability to create value. Teams that are value-driven will protect the value they create and strive to maintain user value whenever there is an issue. This process occurs naturally when teams are customer-centric, as protecting customer value relates to taking pride in their work. Value-driven teams continuously listen to their users and will restore value that is accidently destroyed.

Directions for Future Research

The concept of value destruction receives limited attention in practice. There is attention for lack of performance and instability, though these issues usually receive lower priority than development of new features. These topics require more attention to prevent the destruction of existing value.

Nowadays, software developers are no longer widely regarded as ‘nerds’. Agile methodologies are continuously gaining popularity and technical companies are often admired. Software development companies have learned to deal with complexity and uncertainty, which have resulted in valuable innovations, both in terms of products and new ways of working. In that sense, software development companies are setting the new standard for customer expectations. However, there is a long road ahead until organizations realize the importance of value creation and are able to sustainably deliver value. At present, the optimal, proven way of enhancing value creation is to build and facilitate learning teams that make small steps which are either valuable or easy to correct.

Footnotes

Acknowledgements

The author is truely grateful for help from Andrea Devlin, Bart Driessen, Huib Stoel, Bob van Luijt, Albert Witteveen, and Sage Review Committee.

Declaration of Conflicting Interests

The author declared no potential conflicts of interest with respect to the research, authorship and/or publication of this article.

Funding

The author received no financial support for the research, authorship and/or publication of this article.

References

Adzic

(2011). Specification by example: How successful teams deliver the right software . Shelter Island, NY: Manning Publications Co.

Beck

(2003). Test driven development: By example . Upper Saddle River, NJ: Pearson Education.

Agile Manifesto. (2001). Manifesto for Agile software development. Retrieved from https://agilemanifesto.org/

Bird

(2013). The real cost of change in software development. Retrieved from http://swreflections.blogspot.com/2013/09/the-real-cost-of-change-in-software.html

Gilb

(2010). Value-Driven principles and values—Agility is the tool not the master. Agile Record , Issue 3. Retrieved from https://www.future-processing.pl/wp-content/uploads/2013/11/Gilb-Agile-Principles-2010-agilerecord03_Gilb.pdf

Gouy

(2014). Agile with guts, a pragmatic guide to value-driven development. InfoQ . Retrieved from https://www.infoq.com/minibooks/agile-guts

Murphy (2017). Frank Robinson’s minimum viable product definition. SKMurphy, Inc. Retrieved from https://www.skmurphy.com/blog/2017/04/24/frank-robinsons-minimum-viable-product-definition/

Patton

(2014). User story mapping, discover the whole story, build the right product . Sebastopol, CA: O’Reilly Media Inc.

Rother

(2017). The Toyota Kata practice guide: Developing scientific thinking skills for superior results. ResearchGate . Retrieved from https://www.researchgate.net/publication/318109888_The_Toyota_Kata_Practice_Guide_Developing_Scientific_Thinking_Skills_for_Superior_Results

10.

Sinek

(2009). Start with why: How great leaders inspire everyone to take action . New York: Portfolio Penguin.