Remove Date-driven Behavior to Achieve Agility—Focus on “Done”

Finish what you start, and stop guessing when you will finish.

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.

This is the third post in a series on removing date-driven behavior. The first post illustrated why date-driven behavior results in waste and inhibits agility and why you should, therefore, minimize it. The second post focused on replacing fear with safety and learning more by doing versus planning and designing.

This third post shows how focusing on getting to “Done” with high stakeholder and user engagement beats driving towards a date.

---

Corrective Pattern: Focus on “Done” Rather Than 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.

The grand idea of this pattern is to avoid sharing dates before being “Done.” This often creates an intense response in those who crave dates for a feeling of certainty and believe in the motivating power of a date.

However, as the prior posts in the series illustrate, the act of setting a date upfront equates to simply expecting precision amid uncertainty as software development is custom, uncertain, complex, and creative. The certainty provided by a date up front is an illusion.

The prior posts also show that dates do not motivate; rather, demonstrating Agile Leadership is the special sauce to motivate a team. Motivate your team by giving them a vision and a purpose and support in achieving it.

Just Say, “No”

Jony Ive of Apple sums up the essence of avoiding the date trap in the following quote on how Apple deals with dates:¹

Apple has been practicing, trying to create, and develop hardware and software for decades . . . and from our experience, it’s sort of better to do the work and say, “hey, we made this,” rather than to announce to everyone, “we are going to do this.” I think that’s a cynical, opportunistic PR move. I think it’s better to just do the work. And from our experience, a lot of what we do fails. In terms of what we explore as a team. And it just seems that that’s something that we should be dealing with, not something we should be dragging everyone else through . . . So we tend to have our heads down and work. And if something is coming out well, then we’ll talk about it.

Many times we feel pressure to give a date when asked. We are usually asked for a date before any work has started at the point of highest uncertainty. Then, we unfortunately promise a date. This scenario plays out often due to bravado, an opportunistic public relations move, pressure to show competency, or pressure to beat the competition.

In fact, given the uncertainty of software development and the destructive behavior resulting from dates, we will, in the end, miss the mark. And this will not inspire bragging rights. A public relations campaign will likely need to launch so we can save face for the missed date.

The greatest point of certainty in software development occurs when the software is “Done” and available for use. Since software development is fraught with uncertainty, avoid providing a date before the software is “Done.”

It is common for uncertainty even in the deployment to production, so simply wait until the software is available in production before announcing your product or feature. The most certain moment is when the software is working and deployed to production.

Give Them Something Better Than a Date

Dates are empty promises. Rather than promise a date up front, bring those requesting a date along for the ride. Engage your users and stakeholders in the development of your product. Figure A illustrates this concept.

By engaging your stakeholders and users in co-creation activities during development, you will easily meet expectations as they will see the product unfold and will help shape it as it is built. There are many ways you can achieve co-creation in this manner:

• Invite your stakeholders and users to your end of Sprint Review to get feedback
• If possible, engage with your stakeholders and users during the Sprint for rapid feedback
• For uncertain product ideas, engage in low-fidelity prototyping discovery activities with your users before you build enterprise-caliber working software in-Sprint
• Perform user testing with your users on Sprint output

This high level of engagement ensures the delivery of the “Right” product.

The users and stakeholders will understand when the product will be finished as they will come along for the ride. There will be no need to promise the date upfront.

---

Conclusion

Giving a delivery date upfront for software development is a bad idea. We must fight against this behavior. Do not give a date up front; rather, involve your users and stakeholders in the creation of your software. This will create a partnership and co-creation scenario to ensure you build the “Right” product.

Stay tuned for future posts in the series on how to break the date-driven behavior anti-pattern.

---

Other Posts in the Series

• Remove Date-driven Behavior to Achieve Agility—An Introduction
• Remove Date-driven Behavior to Achieve Agility—Learn More By Doing
• Remove Date-driven Behavior to Achieve Agility—Forecasting Delivery Dates Amidst Uncertainty
• Remove Date-driven Behavior to Achieve Agility—Commit to Value, Not Dates
• Remove Date-driven Behavior to Achieve Agility—Dealing With Legitimate Date Constraints

---

Related Posts

How to Shift Gears to Become an Agile Leader

Agile Leader Pattern 6 for Building Awesome Teams: Serve the Team

---

Reference

1. Jony Ive Dishes on Apple Rumors and His Design Team in a Rare Interview, Mark Wilson, Fast Company, December 6, 2017