I just read this post from Mohammad Azam about a project that was impossible to do using Agile practices.
I quote:
A reasonable deadline for the project was approximately 3 months but it had to be completed in a month. At this time an agile book will indicate that the developer should talk to the owner and come to a reasonable deadline. Unfortunately, in this case the owner was fixed with the deadline and was not willing to move it further.
The author further concludes that following the agile principles would have killed the project. He dropped some of the agile principles and practices, and finished the project in 29 days.
Yes, the resultant code was messy but at the end I get to keep my job.
I have no problem with Mohammad dropping agile practices/principles in order to complete this on time and to help him keep his job (especially in the current economy). I do have a problem with the idea that ‘Agile’ can kill a project. The only thing that killed this project is the unrealistic deadline which was set by the owner. The fact that the project was delivered within the requested time frame, and even assuming that it is completely satisfactory to the owner, does not mean that it was a good idea to hold this project to a deadline which only allowed for one third of the estimated workload.
Now some of you are probably thinking “the deadline couldn’t have killed the project since it was delivered within that deadline!”. True, to a point. We all know what happens when developers face tight deadlines: they take technical shortcuts and they accumulate technical debt. Mohammad already stated that the resulting code was messy so i guess it’s safe to assume there’s quite a bit of technical debt there. Being in technical debt is like owing money to Tony Soprano… you better get out of debt fast or things are gonna get much worse, very soon even. The longer you wait with paying off the debt, the more you’ll lose certain abilities and possibilities.
Getting out of technical debt can be pretty expensive, but there’s not really an alternative. If you don’t get out of debt, further maintenance of the code base and adding new features will only become more expensive over time. Failure to pay off the debt will sooner or later kill the project entirely because the gains that the project brings are no longer greater than the costs that come with it. At that point, the decision is often made to build a new system to replace the old one. The new one is gonna fix all of the problems of the old one. And if you’re lucky, the managers will have figured out by then that unrealistic deadlines only cost more money in the long term than a reasonable deadline would have.
I guess it depends on what he interprets as agile.
I’ve been using TDD for at 3 years now and I am starting to think that the “discovery” aspect of some of the agile practices like TDD does add unecessary time to a project,
Now I get great benefit from TDD but I would like to start with a more concrete design that could at least prove some of my assumptions first by having a concrete design.
I mean with TDD and the agile methodology, we do JIT design which means we write our test and then set out on a voyage of discovery to turn the bar green. You design just enough to pass the test. I am starting to wonder if this is as productive as it could be.
I generally work on web UI applications and I get so much functionality designed up front by using clickable wireframes. This helps get feedback instantly by using a good tool to generate the wireframes.
Does the customer worry about clean code? Will your company prosper if you can deliver quicker for less money.
I think we have lost sight a bit of what the name of the game is.
Describing the UI in UI terms and not user stories that are often advocate.
I’m willing to bet that Mohammad isn’t going to make the deadline for the next major release. The next time, the owner will make the deadline even more narrow because Mohammad agreed to sacrifice a month of his life trying to make the first. Is this all worth it?
I’ve come to the stage that I’m going to try to talk some sense into that particular customer. If he sticks to his deadline, then I’ll try to sell a reduced feature set. If he still doesn’t want to cooperate, then neither am I (economical crisis or not). We need to get out of the dark ages with our craft!
Remember the fifth agile principle: quality over crap!
I have been thinking a lot about our profession as a craft lately. I know this is often a difficult conversation, but here is the conversation as we should want to have it as professionals.
1. I’m sorry, but the complete list of requirements you provided will take 3 months given our history of shipping software. Here are some other options to increase our velocity for the next 30 days: If they exist, name them. New machines, other tools, more devs on the team (iffy) , etc.
2. No, we will not stop using the practices that we know work to develop high quality software in order to move more quickly. That is a violation of professional ethics.
3. Given current capability, here is the amount of functionality we can deliver in 30 days. Please prioritize your backlog of work so that we get to your highest priority items first and you can choose when to deliver.
And so on. The bottom line is that if a team subverts themselves in order to deliver once, it is now an expectation. If we don’t expect quality and craft from ourselves, no one will. Certeinly not your customers.
On the other hand, why isn’t this okay? If you are building IKEA furniture, rock on. If you are under the illusion that you are crafting heirlooms, you are kidding yourself.
“At that point, the decision is often made to build a new system to replace the old one. The new one is gonna fix all of the problems of the old one. And if you’re lucky, the managers will have figured out by then that unrealistic deadlines only cost more money in the long term than a reasonable deadline would have.”
Unfortunately, probably the managers will not have figured out this. They will decide to replace the old system with a new one, blaming for the failure Java, .Net, or whatever technology used. And the new system will use SOA over an ESB, will be prettier, but will be slower, and will still not solve the old problems. Just like when we switched from VB-like-client-server to the web.
@Paul Cowan, Agilists like to think they don’t do design up-front, but that is a lie. Or it works by plain luck. If you have a bunch of inexperienced developers, the project will work only if it is very simple (plain MVC forced by the chosen framework is sufficient), or by plain luck. The complex projects will only work out if there are some experienced developers, who can ‘feel’ the design without drawing it on paper. They do design up-front (not detailed design, but enough to keep things in place), they just don’t print the diagrams.
Martin Fowler said in a presentation, ‘the simplest thing that could possibly work, not the stupidest thing’. You shouldn’t design for imaginary requirements, but you must design with the known requirements in mind. All the time. If you are to recreate Google, you can’t just start the project using Rails’ scaffold or Seam-gen, and wait that the Map-Reduce thing just ‘appear’ magically in the design after half of the system is coded.
That is the anti-pattern. ‘The Agile’ won’t solve your problems. But the VALUES of agile do help you to keep the important things in focus. Not at documenting failure, not at getting 100% testing coverage, but at your true goal, that is working software.
And, thinking that ‘Agile will kill the project’ means you just don’t get it at all. Agile is not ‘blindly and zealously following the XP practices’, because this means ‘following a plan’ one of the ‘less valued’ items in The Manifesto. Do what you need to do. Drop what you need to drop. But not because you’re lazy, but because you judged it is the right decision in your context.
Heh, who hasn’t been Mohammed? This sounds like so many “start-ups” that I’ve worked for. I launched a product working my ass off for a 6 month delivery for v1.0, then when the requirements came in for v2.0 I estimated another 4-6 months of effort, and was told to get it done in 1. Oh, and I’d get to hire and train a graduate developer to “help” me. Too much, I left. The product survived, maybe they changed their tune, maybe they found someone with lower standards. Don’t know, don’t really care. 🙂
However the simple fact is technical debt or no, getting software out sooner & cheaper brings money in earlier. It is a very simple equation in business, put up or shut up. I am all for outlining how better principles and practices will aid the longevity of a product, making it easier to maintain & extend, but Agile only goes part-way. Requirements are the cornerstone and no methodology is going to help if we cannot define precisely what the end customer/user is expecting to see.
If my employer, the guy who’s ass is on the line with investors & loans and stress to pay me a 9-to-5 salary or hourly contract rate, says it needs to be done by x, then I do my damnedest to get it done by x. “But” I make sure he knows, and understands up front what compromises are taken. Otherwise I say it’s unreasonable and hope to find a new, more reasonable employer.
Wouldn’t Agile (or at least XP) say to negotiate scope rather than slip the date?
If you say “I can deliver a working system by then, but not all of these features – here’s how much each will cost in time, you choose which you want” you may have a better negotiating position.