As a software developer I often receive push-back on promoting features or components to a production environment because of outstanding product backlog items.
The problem with this type of approach is that there will undoubtedly always be outstanding product backlog items. These backlog items will vary in criticality and the measure of criticality will be subjective to say the least. For example: Is it critical to get it done for this release or is it just critical to get it done before the end of the project? Is it critical for 5% of the users and not for the other 95% of the users? …
As well, if we are always moving out release dates, we end up with a weak project velocity. The team doesn’t feel like they are doing meaningful work any more, because it is all for a hypothetical system, in a synthetic environment. This is very de-motivating. Effectiveness of time boxing via actual release dates is also lost because release dates keep changing. It is difficult for the team to celebrate wins because deadlines aren’t being met, and the project isn’t delivering value to its users.
With regular non-flexible release dates, we can mitigate all of this. Of course, there will always be unknowns and we will likely be overly-optimistic with respect to what can get done before ’said’ release date, so fixing the date will imply only one thing: what we deliver on that date must be flexible. If tasks don’t get completed for the release, they get shifted into the next release. Likewise, if all of the tasks get done before the release date, we can draw from the next iteration’s task list.
Fixing the release date and leaving the release deliverables flexible is much more effective than fixing the release deliverables and leaving the release date flexible. If we learn to schedule a project this way, we end up with a greater return on investment because we are regularly releasing software that provides business value. We also end up with higher team morale and productivity (by the way, an environment like this tends to attract the brightest of individuals). And finally, we tend to start making decisions based on the behavior of our system in a production environment, with production users. This kind of feedback is real and is the best kind of feedback to evolve our system effectively and efficiently.
No related posts.
Related posts brought to you by Yet Another Related Posts Plugin.
0 Responses to “Critical Chain Scheduling”