The fear of failing to meet a due date can cause us to act in 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 prior to 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 up front equates to simply expecting precision in the midst of 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:1
Apple has been practicing, trying to create, 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, the end result will miss the mark and will not inspire bragging rights. It is likely that a public relations campaign will need to launch to 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 prior to the software being “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 activites 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 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 up front.
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.
- Jony Ive Dishes on Apple Rumors and His Design Team in a Rare Interview, Mark Wilson, Fast Company, December 6, 2017