Deadlines in Agile
Deadlines in Agile
Imagine your company taking on a new project. It could be for a client or it could be an internal project – it does not matter. Along with every new project, there should and will be high expectations and lofty goals – and yes, a release date has been set.
"When” it will be done could come from many sources. It could be by some sort of estimation of all the work that needs to be done or it could be a wish or a guess – it could even be external factors deciding this date. Even if it’s internal project, somebody, usually the part of the organization impacted by the project, wants some way of knowing when the project will have this expected impact.
Deadlines are a reality. The question is: how do we deal with deadlines in agile?
Agile Principle: Sustainable Pace
One of the principles from the Agile Manifesto tells us: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”
Sustainable pace and deadlines? Traditional thinking usually leads to a lot of overtime when the project end is coming. This is when the project realizes that all those features that the project has committed to aren’t going to be finished by the set date.
To meet the deadline, overtime is used and that has all kinds of negative impact in the long run. You might increase productivity in the very short term, but the productivity lost after the deadline has been met is a great cost.
One hundred fifty years of research proves that shorter work hours raise productivity and profits, and overtime destroys them.
Short Iterations and Working Software
So, without overtime, how do we implement all those features that at project start were viewed as essential? The answer is that we in agile view essential features as something that is always changing based on feedback when iterating over that list of features.
There is just no way that anyone can know all the essential features up front. Short iterations and having working software as your primary measure of progress assures that when the deadline arrives, you are guaranteed to deliver a working product that is likely to contain features that are actually wanted by your customers.
A Shift in Mindset: Reduced Risk and Higher Precision
In a traditional approach, you are managing against the full set of requirements set out at the beginning of the project. You measure success against how many of these requirements are implemented.
Also, since testing the implemented features is a separate phase which usually doesn’t get the necessary prioritization, you might end up with a lot of features that actually don’t work properly. Not only might the features not work, but since no end user really has been involved in testing the features, you also might end up with features the users don’t want or need.
Instead of risking software that does not work and functionality not wanted or needed, you should change to an iterative approach, where for each iteration, you try to get as much feedback as possible about the new features and changes in features done since last time you got feedback.
There is just no way you can think up, upfront, exactly what your end users want and need. You can have a basic idea and work from that, but you need to have a short feedback loop to work on feedback from your users.
Based on the feedback you get, you can inspect and adapt. Maybe you need to go in a completely different direction or maybe you are on track and just need some minor adjustments.
Using a traditional approach, you might not know until your project is done; with an agile approach, you should know very early with plenty of time to make changes.
Building a product that customers don’t want probably wasn’t part of that lofty goal set at the start of the project. You are essentially shifting from “building all these features by the deadline” to instead trying to “build the best possible product by the deadline.”
What If All Features Are Needed?
Sometimes, for regulatory requirements as an example, you can’t just say you have finished the most important features and that’s that. Another important advantage by having short iterations is that you will catch early warning signs that development will progress more slowly than needed for the deadline to be met.
By catching this early, there will most likely still be time to do something about it, like putting additional teams on the development. If you catch these early warning signs, the general rule about putting more people on the problem and how it will only slow you down won’t ring true.
Doing something about the problem when there is still time to do so is one of the great strengths of a short iteration-based approach.
Manage Deadlines with Change in Mind
To a large extent, deadlines are inevitable. Even if a hard deadline hasn’t been set, there usually are expectations of a release date – either internally from management or the ones being impacted by the project, or externally from customers or other stakeholders.
Still, agile promotes a sustainable pace. Short iterations, feedback and a product that works at all stages is the answer. To some, it’s very comforting to manage the development work by looking at all the upfront requirements and managing against those.
This is, of course, a false sense of security – requirements will change while doing the work. We are much better of embracing change and managing deadlines with change in mind.
I welcome your thoughts in the comments below.
comments powered by Disqus