Project Practitioners > FAQ: How do I deal with late Agile projects?

FAQ: How do I deal with late Agile projects?

By Brandon Carlson

How do I deal with late Agile projects?

A couple of weeks ago I was approached by some folks considering making the transition to Agile software development. Having done some research on their own, one question had come up and it was one that I had heard before.

“In Agile, if you’re approaching a deadline, is cutting scope the only option?”

Of course the answer is no, but what other options do you have? If I were working on a traditional project I might offer up these options:

  • Move the date.
  • Cut scope.
  • Staff augmentation
  • Overtime
  • Reduce testing time. :-)

I have witnessed each of these phenomena in prior projects and none of them have been very successful at solving the problem. Let’s look at each and discuss why they do or don’t work.

Move The Date

Although this seems to be a logical solution, the practicality of it are completely dependent on context. Unfortunately many projects are commissioned to fulfill a need created through contractual obligations, regulatory requirements, and specific market windows. These types of external pressures make changing the release date of a project or product difficult or impossible. Even if it is possible to move the release date, it is not always desirable. Consider option two.

Cut Scope

Cutting scope seems to always come with a large amount of resistance, but it really shouldn’t. A report by the Standish Group shows that 45% of the features in an application are never used with an additional 19% of those features that are rarely used. What happens to your schedule when if you can identify and cut even 25% of those features? Your schedule would most certainly move in the right direction. This doesn’t necessarily mean that the feature can be cut completely, but the scope of required features could be reduced. Does your reporting engine enable users to fully customize a report when all the users actually need is a simple monthly account summary?

Staff Augmentation

After all these years it seems that we still haven’t accepted the realities of Brooks’ Law. When a deadline approaches, the time allocated to the training of the new staff and the increased communication often manifests itself as a net loss on the schedule. This, of course, may be effective if the staff augmentation happens early enough in the project.


Most of us have been on a project or two that we were asked to buckle down and put in some extra time to get the project done. This often produces immediate results as the team works hard to get the project back on track. What happens then after a month of continuous overtime? Studies have shown significant decreases in productivity when exposed to prolonged overtime. What does that mean to us as those responsible for delivering a quality product? Tired people don’t write good code, requirements, or perform deliberate and thorough testing. Although the project may get an initial burst in productivity, it usually leads to a low morale and poor quality product.

Reduce Testing Time

Ok, the software industry is the only industry I know of that enables poor quality. Phrases like “works on my machine” and “did you reboot?” are an eerie sign of the state of the affairs. Imagine buying a car and, two weeks after your purchase, it just stopped while driving down the interstate. After coming to a complete stop, you popped the hood and pressed the big red “Reset” button. You wait about 10 minutes and start the car once again, feeling good about the fact that you won’t have to do that again for another couple of weeks. Unfortunately, I’ve been at the sending and receiving end of this transaction:

PM: Programmer Pete, how's it going.
Pete: Fine, how is it with you?
PM: Ok, just left my project status meeting. My butt's sore from getting it chewed for 90 minutes straight.
Pete: Yeah? About what?
PM: The schedule.
Pete: Well, that stinks.
PM: Yeah, well that's just part of the Job.
PM: Pete, let me ask you a question.
Pete: Ok
PM: We planned for 5 months of testing for this project.
PM: I was thinking about cutting it back to 3. How would that make you feel?
Pete: I'm fine with it. I'm feeling pretty good about this project.
Pete: We really haven't found much wrong in our developer testing.
PM: Thanks Pete, that's all I needed to know.

I think we all know how this project ends.

Your Point?

Well, it’s back to that again. I have to answer the question. The answer I gave them and others is that all of the above options are available to you in an Agile project. It’s that simple. Agile doesn’t limit your options, you can still make all of the same mistakes you’ve made in the past. The key difference is that Agile provides the framework for identifying project schedule risks earlier on in the project when you have more time to make good decisions.

Of all the options, I still find that options 1 and 2 are often the best choices. Bottom line is that using Agile doesn’t guarantee success, you will run into many of the same problems you’ve always encountered. There is no silver bullet.

Related Links
Alan Koch has argued that reduced testing time can improve project quality, as long as it's applied correctly. A simple flexibility matrix can add a surprising amount of clarity to tradeoff discussions. If you decide adding staff is the way to go, it will be easier with a solid analysis of what staff you need.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Follow Us!
Linked In Facebook Twitter RSS Feeds

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.