Remove Date-driven Behavior to Achieve Agility—Commit to Value, Not Dates

Delivering something on time does not mean it is valuable.

The fear of failing to meet a due date can cause us to act in an overly cautious manner and encourages wasteful date-driven behavior. Because of this, if we do not have a real date constraint, we should avoid manufacturing one. Dates do not motivate; they only get in the way of delivering value expediently.

“When will you be done?”

“When can you commit to delivering that feature?”

“When can we start to earn a return on our investment?”

“What is your commitment for completing the work?”

The dreaded question inevitably comes. Instinctively, you feel like you must give an answer. As described in prior posts, providing a date is perilous with software development as it is an uncertain, complex, creative, and custom endeavor.

The four prior posts on date-driven behavior provide context for the difficulty of predicting dates in the uncertain world of software development:

Introduction: The first post introduces the perils of date-driven behavior, illustrating how it results in waste and inhibits agility and why you should, therefore, minimize it.
Learn More By Doing: The second post focuses on replacing fear with safety and learning more by doing versus planning and designing.
Focus on “Done”: The third post shows how focusing on getting to “Done” with high stakeholder and user engagement beats driving towards a date.
Forecasting Delivery Dates Amidst Uncertainty: The fourth post explains the practice of continually forecasting how long the software delivery will take based on current facts.

This fifth post shows how to avoid date-driven behavior by committing to value versus a date.

Corrective Pattern: Commit to Value, not Dates

As the prior posts in the series have shown, date-driven behavior can introduce significant waste and get in the way of delivering the “Right” product by inhibiting learning and reducing quality.

Committing to deliver software by a date is the nemesis of iteratively evolving software to achieve value. Value is defined as achieving positive user outcomes and business impact. Commitment to delivering by a date assumes work can be delivered in an orderly, certain manner similar to following a recipe. Change is not embraced; rather, it is avoided and made difficult. No room is left to reflect and adapt the scope or the approach to delivering it.

Software is not simple and is rarely an orderly endeavor. Committing to a date for a complex and uncertain activity such as software development will drive a team to wasteful, big, up-front planning and design in an attempt to drive out risk and unknowns up front, aiming to ensure commitment achievement. The perceived certainty is comforting, but it is an illusion.

Committing to value embraces an iterative, experimental, and evidence-driven approach to deliver the “Right” thing. Committing to value assumes that value is more important than a date. However, the value will not stick around forever, so being quick in attaining a valuable solution remains. Committing to value enables value to emerge versus focusing blindly on the delivery of fixed scope by a date.

This pattern shows how committing to value works.

Committing to Value

If we must commit to something, we should commit to:

Supporting people, enhancing collaboration, and making people (teams stakeholders, and users) great
Focusing all our effort on value relentlessly and delivering the simplest thing that can possibly work
Changing our minds about what we are doing or how we are doing it to pivot towards maximum value for users and our business in the shortest time possible

These commitment areas are described in the sections below.

Commitment 1: Make People Great

In the traditional, hierarchical command and control style of management, people became interchangeable parts that are expected blindly to do what they are told and to deliver it on time. Perhaps this is a result of calling software development an engineering discipline, which evokes the mentality that software can be controlled through precision, standardization, predictability, and risk mitigation.

This controlled approach ends in stagnation where teams turn off their mind and wait on their next order. In this model, teams have wide separation from the users of their software. They pull the next item off of the backlog and blindly deliver it unaware of why it is needed or who needs it. Innovation suffers. Unhappiness abounds. Resulting from this approach is a subpar product that produces lackluster outcomes for users, teams, and stakeholders.

Contrast this with an approach where management supports and serves the team by:

Setting a clear vision and purpose for the team and supporting the team in achieving that vision
Breaking down barriers to enable easy collaboration among team members, stakeholders, and users
Removing organizational barriers that impede a team’s ability to deliver value quickly to end users
Helping the team gain the necessary skills needed to deliver value
Giving the team room to iterate the solution and improve their delivery technique

In this model, the team is liberated and given trust and ownership to deliver against the vision. Their minds are fully engaged in finding the right solution for user needs. Where the team needs help, they are supported and coached. Growth is a primary focus. Teams deliver results with high quality and efficiency. As a result, the team, users, and stakeholders are happy and motivated.

Commitment 2: Unwavering Focus on Value and Simplicity

Too often, teams focus on delivering output sprint after sprint, disconnected from their user, trying to deliver every idea in the backlog by a fixed date.

Instead of focusing on output, enable high engagement of the team with users before and after delivery. Engage in rapid build, measure, and learn loops to emerge the right product. To enable this learning engine, build a track of discovery and a track of user testing around the delivery track (where delivery sprints take place) as shown in Figure A.

Use the discovery track to run quick, low-fidelity experiments on uncertain ideas to gain insight into user needs. When ideas are more certain, they flow through the sprint in the typical delivery track to produce enterprise-caliber working software output. This output is then tested with users either in the sprint or right after the sprint ends in the user testing and analytics track. The magic in this approach occurs because the team and users are engaged in each track of work. There is no hand-off between a user experience team, the scrum team, and the user testing team. It is one, powerful, delivery team fully connected to the users of its software.

In this model, the solution that is delivered is exactly what the user needs, nothing more and nothing less. It is the simplest solution that could possibly work. It is not every idea that we could possibly come up with, delivered on time and budget. Instead, we deliver to a target outcome in small, incremental, and iterative experiments and stop when that outcome is reached.

Commitment 3: Quickly Adapt to Change with Ease

Setting a plan in stone at the beginning when the least is known is no way to deal with uncertainty. Having a standard approach to software development is no way to adapt to custom, unfamiliar scope, new technologies, and evolving team dynamics.

Continuous and rapid inspect and adapt loops are critical for adapting to the uncertain, custom, creative, and complex nature of software development.

Allowing the team to have control over the inspect and adapt loop is critical for easing iteration and improvement toward the goal. If change must be managed, metered, controlled, or approved by someone other than the team, it becomes non-trivial to change and likely slows down or possibly halts improvement.

Several of the Agile frameworks have an intense focus on adapting to change. As an example, two of these, Scrum and Lean, have significant provisions for inspecting and adapting as described below.

Scrum has several events focused on inspect and adapt. The sprint review focuses on inspecting and adapting the sprint output by stakeholders, users, and team members. The retrospective provides a chance to reflect on processes, tools, and the team dynamic to identify a key improvement for the upcoming sprint. The daily standup provides a means of inspecting progress and adapting to meet the sprint goal. Backlog refinement looks at measuring progress towards the minimum viable release and ingesting new ideas to meet target outcomes based on user and stakeholder insights.

Lean software development focuses on continuous improvement and a relentless drive to remove waste across the entire value chain. Improvement katas and kaizen events are utilized to focus on the improvement and growth of people to gain insights to meet the challenges of complexity, uncertainty, and emergent needs.

Embracing a continuous improvement mindset to consume change with a change resistance close to zero is the goal.

Conclusion

Driving to a delivery date does not ensure a successful outcome. Driving toward value and constantly adapting along the way emerges a successful outcome. Committing to making people great, focusing on value and simplicity, and adapting to change quickly and easily will deliver value. Commit to value, not dates, and achieve success!

Stay tuned for a final post in the series on how to break the date-driven behavior anti-pattern.

Blogs