Sometimes you have no choice but to deal with a date constraint.
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.
After all this build-up on removing date-driven behavior in the prior posts of the series, let’s talk about dealing with a legitimate date constraint. Legitimate dates in business are inevitable, so we must have rules around how to work with real date constraints.
The four prior posts on date-driven behavior provide context for the difficulty of predicting dates in the uncertain world of software development and techniques for addressing this uncertainty:
- 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.
- Committing to Value, Not Dates: Driving towards 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.
This final post in the series shows how to deal with legitimate date constraints.
Defining Legitimate Date Constraints
Listed below are legitimate software date constraints:
- An event where you would like to show off your product, such as a conference
- A date your competition will release a similar feature or product
- A government or regulatory imposed deadline
- A date that a portion or all of your technology architecture will become obsolete
Examples of illegitimate date constraints are:
- A manufactured date put in place to motivate the team to deliver faster
- A delivery date imposed by someone other than the team
- A date put into someone’s yearly goals
- A date promised to a customer or stakeholder
How to Handle Illegitimate Date Constraints
Any illegitimately formed date constraints should be corrected as soon as possible.
Remove dates that are not given by the team or any date used as a motivating force for team productivity.
If dates are imposed on the team because they are in management goals, these dates should be revised based on team input on a forecasted date range. Even better, simply remove the dates from goals altogether and replace them with value-driven goals.
When a date has been promised to a customer or stakeholder, quickly revise these dates with a forecasted date range provided by the team along with an explanation of the uncertainty. Invite stakeholders and users to the sprint reviews so they can see the product emerge and provide feedback as it is delivered. For highly uncertain items, engage users in low-fidelity discovery experiments to figure out the right product feature to deliver. Once a feature is delivered in a sprint, engage users in user testing to ensure it meets the targeted need.
How to Handle Legitimate Date Constraints
First, do not exhibit date-driven behavior. Do not drive towards the date without embracing the lessons of prior posts. We still are dealing with software. We must follow the same techniques to deal with this uncertain, custom, creative, and complex endeavor. We still need to:
- Learn more by doing
- Focus on done
- Forecast dates amidst uncertainty
- Commit to value, not dates
When we have a date constraint, we must quickly experiment to gain a rapid feedback loop, involve our users and stakeholders before, during, and after delivery, continually forecast a realistic date range based on evidence of our delivery, and strive to commit to value rather than simply delivering anything.
What to Do When Forecasted Delivery Dates are Outside of Your Legitimate Date Constraint
When your team forecasts based on delivery evidence, the forecasted date range may fall outside of your date constraint.
This is when you pull your users closer rather than hide from them. Use close engagement between the team and the users to deliver the simplest solution that could work to successfully deliver by the date constraint. This is where the Agile principle of maximizing simplicity1 becomes paramount.
Simplicity–the art of maximizing the amount of work not done–is essential.
Throw out any scope not needed to meet the target outcome prior to the delivery constraint. Find the 20% of the delivery options that will deliver 80% of the value. Maximize your outcomes while minimizing your output. Find the good solution option and defer the better and best solution options.
Ensure your teams are dedicated to the work at hand, fully capable of delivering with minimal external dependencies and protected from interruption.
Provide a safe environment for your teams to raise impediments swiftly that they cannot solve. As a manager, solve your team’s impediments swiftly.
Focus on quality. Take on technical and experience debt only as a last resort. Throwing quality out the door is where date-driven behavior takes root. Avoid this.
Once you have experienced trying to meet a date in this manner, you should not stop these practices of keeping your users close, maximizing simplicity, emphasizing focus, reducing dependencies, embracing safety and transparency, and avoiding quality sacrifices. Embed this mindset in the way you work moving forward to advance your Agility.
Conclusion
Even with all of this focus on delivering value by the date, you may not make the date. Fortunately, you will have involved your stakeholders and users along the way and proven new ways to move easily and quickly to deliver value in the uncertainty of software development.
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—Focus on “Done”
- Remove Date-driven Behavior to Achieve Agility—Forecasting Delivery Dates Amidst Uncertainty
- Remove Date-driven Behavior to Achieve Agility—Commit to Value, Not Dates
References
Todd Lankford unlocks Lean Leverage in organizations to cultivate powerful, engaged product teams who maximize outcomes and impact.
His articles share his experiences and learnings along the way. Join the mailing list to get them in your inbox.