I was recently asked to engage in a debate over whether or not there are deadlines in agile. There were a few folks involved in the debate and the predominant perspective seemed to be that true agile efforts have no external deadlines - all deadlines are self-imposed by the team in the form of an iteration commitment or a scope negotiation with the Product Owner.
This is bunk.
Target dates happen often. Maybe there is a regulatory change taking effect on a certain date. Perhaps there is an upcoming industry event that happens once per year. We might find ourselves in a position where the available capital runs out in another few months. And sometimes the organization makes a very public promise to key customers or stakeholders.
I’m not saying that these things should happen. But they do. And to insist that if they do, then we aren’t agile, is a gross over-simplification of agile.
So, yes, there are deadlines in agile.
A healthy high-functioning agile team is delivering working software frequently. Ideally daily, but certainly every few weeks. They are working in small, discrete pieces. Small pieces make for smoother flow, which allows for more accurate forecasting. Small pieces also allows them to introduce change with less disruption.
A healthy high-functioning team is also keeping a close eye on the number of items they have in progress at any given time. By limiting the amount of work in progress, they are again increasing their ability to respond to change.
A healthy high-functioning team is incrementing the solution, even when they know what the detailed requirements are. They are doing this to reduce risk (less functionality/polish is better than no functionality/polish), to learn about both the implementation and the customer’s response, and to increase their options (this is basic, but works - let’s move on to something else for now).
With these disciplines in place, a target date becomes a discussion of probability and scope. Probability is about the likelihood the desired scope can be completed by the date. If the probability is low, then scope needs to be adjusted. This is not necessarily a matter of whether or not a feature gets delivered, but how much of the feature and in what fashion. This is an opportunity for the team to take on technical debt in a healthy manner. Can we defer type-ahead in the search bar? Can we do an export of data once per day for down-stream systems instead of writing the full API and then implement the API later? Can we launch with fewer products and focus on ones that have fewer options to reduce complexity?
The team is actively involved in all of these discussions. Planning is done based on the data available. Communication is frequent. The team is not making commitments and is not negotiating with an external Product Owner - these are not healthy concepts. The Product Owner is a member of the team and the whole team is forecasting based on data and collaborating together to figure out how to best deliver as valuable a working solution as possible in the time available.