Agile Does Not Mean Doing the Impossible

First yes. Yes, over time Agile principles will allow your teams to dramatically increase the amount of work they can do -- enough to be non-believable if I told you about it. After all, "Agile" is really just a marketing term around best practices for iterative and incremental teams and, well, best practices have a tendency to be really good.

But no, it will not fix your problems.

Here's the deal -- you don't make the work horse run faster by electrocuting him. Sure, it scares the hell out of him, and you're bound to get some initial improvement, but it's non-sustainable. Brute force does not make a team better.

What Agile principles do is bring the pain quicker. If you have unreasonable expectations for the next 3 months and week-long sprints, then an agile team is going to bring up that it's not working right from the very first sprint. You may not like this -- after all, traditional projects with long GANTT bars usually don't get feedback until many weeks into the process. Everybody here knows about the segment that makes steady increase until it reaches 80% -- only to remain at 80% for a long time! That's because it's easy to guestimate that you're making more progress than you actually are.

Agile projects aren't like that. You have a complete list of testable chunks of work that, when completed, represent the entire project. As each piece of work gets done, there is automated testing that goes with it. You're either done or you're not. We don't do partial credit.

So if you plan to have 10 iterations and the first three iterations only average about 5% of the total backlog, 10 times 5 percent means, on average, you're currently looking at only finishing about half the work. That's a lot of pain to get early in the project.

How organizations handle this pain depends on the project and the organization. If you want to allow the team to learn in order to reach the next level of performance, you will continue to stress them and give them maximum flexibility to innovate. I can promise you over time they'll figure it out.

This is called giving people time to learn. It's also called "sharpening the saw"

If, on the other hand, you want the product delivered, regardless of the consequences, then insist on sprint goals being completed each sprint even if it means working nights and weekends. I don't like this -- you're doing nothing more than electrocuting the horse -- but I understand that sometimes it has to be done. If your business model is such that it never has time for strategic items like increasing performance 10-30% and instead only has time for quarterly deliverables, then you're on a downward spiral. Have fun with that.

In either case, by having small periods of time in which the team is expected to make something of value in return for their salaries is good for everybody. The team gets better at providing value in small increments. The organization gets better at listening to the teams and learning from them.

Over time, teams getting in the pattern of providing value and providing feedback on organizational issues is good for everybody, no matter how the current project turns out. That's why if I'm put into an impossible situation the best thing I can do is stick to agile principles: promise stuff, deliver what I promise, and predict when I will be done and what's holding me up. If I stick to those principles and work as hard and as best as I can, there's nothing more for me to worry about -- I'm doing what I can. The rest is up to somebody else.

And over time, yes, you'll get that performance boost. But that's after you optimize your team and organization. It doesn't come that way out of the box. Agile does not mean doing the impossible.