You can be Agile and still hit a deadline
Agile came about to resolve perceived failings in old-school approaches like Waterfall. Agile provided:
- flexibility to readjust plans due to scope change,
- more homogenous, involved teams, and
- shorter cycles that provided value to the end-user earlier.
This works well for environments where the work is continuous and ongoing, and stakeholders are satisfied with a relatively short term view. This is because they can have reasonably high confidence in what will be delivered in the next sprint cycle and when the team will deliver it. Beyond that, the timing and scope of future releases is more uncertain.
However, in many real-world instances, this is not sufficient. For example, the ideal is to deliver all items allocated to a sprint by the end of it. However this often doesn’t occur, as anyone who has watched a burn-down chart go nowhere, up or any other direction than a neat slope down to completion can attest.
Additionally, if several sprints or a collection of tasks in a Kanban board add up to a feature release of significance to the company, it is common to have stakeholders wonder when that feature will be delivered.
This information can be business-critical, not just out of curiosity. If you have to coordinate that release with such things as a marketing campaign, a regulatory environment or synchronising with other systems, then a date of feature delivery with as much confidence as you can muster is very useful.
The Agile paradigm and the supporting Agile project management tools do not support this well. In response, many pundits suggest that you must revert to a “waterfall” approach if you need this level of planning. That is, specify all aspects of the project in moderate to high detail up front, get agreement, sign off, and lock in the scope. Then estimates of the effort involved in each component, and knowledge of the available resources, are combined in a complicated calculation that the PM uses to project a delivery date.
Experienced project managers are well aware of the failings in this approach, the main one being the inflexibility of the scope. If surprises occur throughout the delivery process in the form of components taking more, or less, effort than estimated, misunderstandings of the original requirements, change in market demands, or new feature ideas, the waterfall approach and the tools used, do not cope well, if at all.
So what is a project manager or scrum master to do if they are in this situation? You want to be Agile, but you have to hit a deadline, or at least be able to report an expected delivery date and track to that date.
There is a hybrid approach. Think of it as “dynamic waterfall”, or “Fixed Agile”. This leverages the best of both worlds: setting a scope, tracking to a date, but also the flexibility to adjust the scope as learnings occur.
To achieve this is conceptually simple. All you need is the ability to:
- Input and refine estimates for all the components of a project scope,
- Provide the available resources with their skills and availability,
- Generate, and re-generate a projection of the end date of the project based on the above for a continuous view of the projected delivery date,
- Report the projected end dates to keep all stakeholders apprised of progress,
- Be alerted if the project is going off-target,
- And a mechanism to review and adjust the remaining scope or resources within the constraints to remain on track.
In this way, a project manager can supply a projected delivery date at the start of the project that is as accurate as the current information allows. They can then track how that date looks as progress and learnings occur and immediately know if it deviates from the target too much. They can then involve the stakeholders in adjusting the scope, resources, or due date in as timely a manner as possible.
In practice, the above is hard, if not impossible. Not because the concept is beyond the skilled project manager, but because the tools don’t support this mode of operation. Our view is that the currently available project management tools have become calcified into the Waterfall or Agile camps; they are generally quite similar to each other, do not support the above hybrid approach, and leave too much of the work to the project manager rather than the computer! They provide data, not answers; reports, not assistance. We believe that a well-designed Agile project management tool should leverage automation and intelligent logic to provide insights and remove all the repetitive laborious tasks that PMs have traditionally done.
Below, we will set out the 5 aspects of a system to support this pragmatic, hybrid approach.
“Best Guess” Estimation management
The process starts with the project manager or product owner leading the team to break the desired feature releases or product outcomes into components. The team must then define these components in sufficient detail to provide a “best guess” estimate of the effort involved. These estimates will range from quite accurate, where it is a well-known task the team has done before, to a high level of uncertainty due to the task being new, complex and ill-defined. We want to minimise the number of the latter type. If a task is complex and ill-defined, the team should focus on these to break them down and flesh them out more to minimise the uncertainty.
Then the team provides “best guess” estimates of effort for the tasks. In addition, they should supply the skills required for the task, and any dependencies.
The only thing certain about these estimates is that they’ll be wrong. The system has to be comfortable with this; it has to be a “Best Guess Manager” by facilitating:
- Provision of all the original estimates,
- An ability to optionally provide a level of certainty with those estimates,
- Assistance with maximising the accuracy of these initial estimates by having an ability to refer to past performance of similar tasks,
- Confirmation that all aspects have been considered, including oft-forgotten activities like testing, rectification, deployment, documentation, etc.,
- Refinement of the estimates as work progresses and the content of the project and tasks becomes more clear.
With all of the above, the users will be able to provide the best estimates they can at the start and zero in on more accurate estimates as time goes on, to ensure an increasingly reliable projected end date.
Resource and skill management
As per the Project Management Triangle, we’ve got a deadline (locked in TIME), we’ve specified the SCOPE with our work breakdown with estimates, now we have to address the COST.
In our case, the COST will mainly be the development resources available to carry out the project delivery. There are often other costs, such as subscriptions, systems and devices. The project management system must consider these to come to a total cost,
However, the development resources generally take up the vast majority of a software development project’s cost. Our system needs to have enough information about the resources to project and easily re-project the remaining work’s timing to attain the “Fixed Agile” ideal. The system will have to support the following information about the resources to do this:
- Their skill(s), which are from the same set as the required skills for the tasks in the prior step,
- Their availability in terms of start and end dates as well percentage time devoted to the project if less than full time,
- A productivity weighting to indicate more, or less, expertise and experience,
- An additional productivity ramp-up over a period for team members new to the project or company.
The above information is critical to give us the most accurate automated projections of an end date based on the remaining work in the project.
In addition, a system can assist with keeping itself up-to-date. It could generate daily prompts to devs to update the remaining work for any of their in-progress tasks. The estimated remaining effort is critical to remaining on top of how the projected end date is tracking to the deadline. A scrum master or project manager can spend a lot of time chasing these figures up. If automated, the PM just has to chase up the devs that aren’t responding to these prompts and maybe give them a nudge to do so from now on!
And finally, if the system also handles the daily cost of resources, it can also calculate a projected total cost of the project if that is required.
Dynamic tracking and reporting
This is where the system gets a little waterfall, but in a much more dynamic way than current systems.
The system needs to take the information provided above and extrapolate a projected end date to compare to the target. This will be done at the start of the project as a sanity check to see if the deadline is doable. As an added bonus, it can also be used by companies who build software on contract to determine whether an RFP has a reasonable deadline, how many resources it will take, and even the financial amount to quote for.
As a reminder, the information provided to the system boils down to:
- The components needing to be built, their estimated effort, their dependencies and the skills required,
- The resources, their availability, their cost and their skills available.
From this, the system has enough information to generate a projected end date for the above work. It does this by generating a notional development timeline by allocating the work components over time across the available resources, levelling the timing so there is no over-allocation and effectively generating a GANTT chart view for the project.
Current systems have rudimentary logic for adding up points, which can give a rough approximation of the end date, but this leaves the PM to manually deal with all the variations of dependencies, productivity, availability, etc. Why not let the computer deal with all that?
The GANTT chart generated should be notional and able to be re-generated at any time when the factors that go into it change. This is where we get to the “dynamic waterfall” paradigm. In this way, we would simulate the entire delivery of the rest of the project repeatedly, perhaps multiple times an hour as updates come in, scope changes, resources become unexpectedly unavailable and the like.
If the system presents the output as a GANTT chart, it can also highlight the critical path if a sequence of dependencies drives the end date. The system should ensure that the notional allocation of the tasks minimises this path by respecting the dependency graph.
As the system optimises resource allocations based on skill, it will also be readily apparent if a lack of resources contributes to the end date. The system should be capable of “what if” research on the resources where the PM can notionally add or remove resources to see the effect on the plan.
Early warning system
As discussed above, the system should be able to generate and re-generate a simulation of the project delivery from an up-to-date status any time anything changes. As such, we would have a continuous readout of the best estimate of how we’re tracking against the deadline.
Now it’s just a matter of having reports available and regular updates sent to the stakeholders.
Another critical logic component is an alerting system when the projected end date varies from the target by a pre-defined threshold.
Commonly, a project can go off the rails without anyone having good visibility of this. As a result, it is picked up much later in the process when the resolution options are more limited.
To be Agile and hit a deadline, we need to know as early as possible if the deadline is in jeopardy and the causes. This gives us the best prospect of reviewing the resources or scope to get it back on track.
Scope change manager
So, what can we do about it when we get an alert that we’re starting to go off track? As mentioned earlier, the Project Management Triangle only gives us limited options. The TIME is fixed, so that leaves COST (resources) or SCOPE.
An obvious option is adjusting the resources. We have already discussed how the system should provide the option of doing a “what-if” analysis of how the addition (or removal) of resources of specific skills would affect the predicted end date. This is undoubtedly a go-to strategy if the organisation has that option; however, it will affect the cost, so it may not be an option if the team is working to a budget.
The other approach is to adjust the scope. It is easy to adjust the scope of an open-ended project with no deadline, you simply insert a component or extend the time taken on one, and everything behind it just shuffles to a later delivery date. When you have to keep to a deadline, it is a fair bit more tricky, and this is where the existing tools provide very little assistance.
Conceptually this is easy. We have a certain amount of resource person-days available to us up to the deadline, and we have a certain amount of remaining work to complete. If we are going off track, the remaining work exceeds the resources’ capacity to finish in time. This could be because one or more components are taking longer than expected, or the product owner has come up with a great idea they just have to have in this release. These are very common scenarios and shouldn’t be treated as out of the ordinary or someone’s fault. This is business as usual; we just have to cope. However, we can’t cope with it by taking the unfortunately common approach of asking the team to “just squeeze it in.”
If the remaining work exceeds the remaining time and we can’t resolve it by adjusting resources, the PM must remove something from the scope. The challenge is what, and who makes the call. This is where the Project Management tool can help again.
When making the call, the tool should present the scope of the project and make it clear for each component:
- Whether it has been done (entirely or partially),
- It’s priority,
- The remaining effort,
- It’s dependencies (including how it relates to delivery of a feature or epic).
The tool should allow one or more stakeholders to remove components until the project is on track again, the strategy being to test the removal of the components that are the largest with the lowest priority and with no dependents. The tool should also allow users to perceive all of these factors clearly and analyse “what-if” they remove this or that component by regenerating a projected end date for each scenario.
The interface of this scope management tool should not be oriented toward technical users. Ideally, it should be possible to present this to the Product Manager so they can be pivotal in the decision making. This empowers them and imbues them with the understanding that the solution isn’t simply to put pressure on the tech team to do more in the same amount of time.
Of course, if the PM and team can’t come to a variation of the scope which is acceptable to the key stakeholders and hits the deadline, then some hard conversations have to be had to modify the deadline, extend the budget to pay for more resources, or miss out on scope components certain stakeholders may hold dear.
Conclusion
We hope you can see that being Agile with a deadline is doable with a hybrid approach combined with a Project Management tool that supports it. We have built a prototype of such a tool at fixed.pm based on patent pending logic, and we invite you to try it out for free and tell us what you think.
A system with the above capabilities can also assist with generating instant, dynamic roadmaps and provide projected delivery dates even if you don’t have a deadline.
