Skip to main content

Timeline for Are deadlines Agile?

Current License: CC BY-SA 3.0

25 events
when toggle format what by license comment
May 19, 2018 at 19:06 comment added Calphool @magallanes Care to elaborate? In what ways are construction and "s&r" like construction? Software development in general is about taking ideas you expect to create value, implementing them, measuring results, and pivoting. This doesn't have a lot to do with construction. Once a building is built, the costs of pivoting are generally prohibitive because buildings are subject to physics. Software is not.
May 18, 2018 at 3:56 comment added magallanes @Calphool "Software is not like building a house". Unless you are doing S&R then, it's exactly like building a house. In my business, we deal with construction and software and it's the same (conserving the scales).
Feb 25, 2015 at 22:26 comment added Nagora @Ellesedil By telling them that they don't need to write a big cheque. You'll write a small cheque and after a month decide if we're a bunch of losers like the guys you wrote the last BIG cheque to and if so, tell us not to expect any more.
Feb 25, 2015 at 18:57 comment added Azhdeen Oh, I'm definitely confused, because different people appear to be saying different things. So, here's a scenario: I'm a company that does stuff and I need a software solution that handles a specific aspect of the stuff I want to do. I'm going to talk to a few different companies in a bidding process, at which point I'll negotiate and sign a contract for that work. If deadlines are not agile, and it's even impossible to estimate a time frame or cost, then how can your sales team convince my team to write a large check made out to your company?
Feb 25, 2015 at 18:42 comment added Calphool @Ellesedil: I'm not sure if you're being pedantic, trolling, or if you're legitimately confused. People have been doing time/materials contracts since time immemorial, so there's nothing new here. When a customer goes to a contractor and says "I need ALL this functionality by THIS date", what you get is a bid (lie) that's big enough to cover the fact that nobody has any real idea what it'll cost. Software is not like building a house. Forcing it to be that way simply makes it cost more.
Feb 25, 2015 at 17:51 comment added Nagora @Ellesedil Well, for a start, most clients have been there and bought the Waterfail t-shirt so they already know there's a problem. Secondly, you work with them to prioritize what they want and get away from the "all or nothing" thinking. Then you make a bet with them: "we'll start doing these things in priority order in deliverable steps of 1 month and charge you for delivered value. At any point you can say "screw you" and move on. We bet that you will keep going because you will see actual value faster and have more chances to refine the product than you ever have before, for less risk."
Feb 25, 2015 at 17:12 comment added Azhdeen @Nagora: With that philosophy, how would you ever present a bid to a potential customer? Customer: "Hey, how long and how much would it cost to have a website to play cat videos?" SW Company: "We're agile, we have no idea." Customer: "Good talk, we'll be in touch after we never consider your proposal."
Feb 25, 2015 at 17:02 comment added Nagora @Ellesedil Billing is the hardest part of Agile, but only because buyers are stuck in a mode of thought that NEVER worked. Projects went over budget and came in late when costs and time requirements were presented up-front. But you're asking for exactly that and complaining that Agile can't give you it. Well, neither could waterfall, it just pretended it could. You're asking for the exact thing that makes waterfall projects fail. We're saying "don't do that, and don't kid yourself that you can or ever could".
Feb 25, 2015 at 16:59 comment added Nagora @Ellesedil - the issue here is "project deadlines". If you're starting off a project worth the name and saying "in X months time I must have everything on this list done and tested" then you're doing waterfall and will probably fail. Planning everything up front to the degree needed to do that has been tried and it has repeatedly failed. Agile is an attempt to deliver not only what you think you want, but what you realise you can/need to have as the project progresses and the environment changes. Project-length deadlines with written-in-stone goals is what I'm saying is not agile.
Feb 25, 2015 at 16:46 comment added Azhdeen With what you just described @Calphool, nothing. I have a deadline (time), a budget (cost), a list of features that are required (scope, may be a large list), and a list of features that would be nice to have (extra scope, may be a small list). Then, what makes deadlines "not agile"?
Feb 25, 2015 at 16:11 comment added Calphool @Ellesedil: It's simply a minor variation on basic project management that's existed since the 1950s. Classical project management: you have three constraints on every project. 1) Time, 2) Cost, and 3) Scope. In order to get "extra juice" on one, you must give on the others. Agile says: "give on scope always, but MAKE SURE you're delivering the thing with the highest value, every sprint". Your most important features will be delivered by a date. You allocate funds to a team, they prove to you every 2 weeks that they're delivering your most important features, where's the problem?
Feb 25, 2015 at 12:14 comment added Azhdeen I'm sorry. If agile methodology isn't adaptable enough to provide a reasonable expectation for when a finished project will be available, then it might as well be a government project: at constant risk of being overt budget and indefinitely delayed. If you can't tell me how long it will take until months into the project, then how can you even estimate how much the project will cost? Do you expect your customers to just write blank checks?
Feb 25, 2015 at 10:28 comment added dcorking This answer seems to contradict itself. It first claims "Deadlines are not agile" but then "The key is that the deadline becomes simply a release date for the first version of the software." An agile project may be able to release some features before the deadline, or even after just a few sprints. Perhaps a small rewrite to clarify and link back to the Agile literature may help.
Feb 24, 2015 at 22:41 comment added Calphool @stevebot: Absolutely. People, until they are corrected, assume software development is like building buildings or roads. It's not. It's more like writing a story, or travelling to a distant city. Very little is set in stone, and very little is highly predictable. So, people ask for you to hit deadlines, but they don't know that any answer we give is at best an educated guess, and at worst complete nonsense. A better way to frame the situation is: "Tell me what's most important, and I'll focus on that so you're getting the most bang for your buck, and we'll figure out the story together."
Feb 24, 2015 at 21:24 comment added stevebot @Ellesedil I would say that part of the problem is educating the business that software is not a closed system. The best we can give our estimates. Agile is transparent and works with this fact. Thus I can let my client know an estimated date, but I won't lie about it.
Feb 24, 2015 at 21:22 comment added Calphool @Ellesedil: Tell me your most important feature, or your minimum marketable feature set, give me a few weeks to a few months to build up a track record against your desired feature set (varies depending on how much you're asking for -- it takes more time to predict how long it'll take to get to the moon vs. Pittsburgh). Then I'll tell you, and since my estimate was built on actual deliveries of useful software, we'll be able to bank on the estimate, unlike the fairy tale you're forcing me to give you at the outset.
Feb 24, 2015 at 20:30 comment added Azhdeen So, if deadlines are not agile, when can I expect my software to be ready by so that I can market it to my customers?
Feb 24, 2015 at 19:54 comment added Nagora @MichaelT The OP referred to project deadlines and that's what I'm responding to - long term deadlines set by a PM at the start of a project rather than a sprint. Certainly there are deadlines of a sort in agile, but they have a very different nature to what people typically mean by project deadlines, but maybe it's just semantics that's the problem here.
Feb 24, 2015 at 19:46 comment added Calphool @MichaelT: If you haven't already, I'd suggest you read Tom & Mary Poppendiecks' book "Leading Lean Software Development: Results Are Not the Point". He's simply conveying a fairly popular meme in lean/agile circles. If you and your team are focusing on deadlines more than you're focusing on continuous improvement, you're not really living agile. You might be doing scrum, but not living agile. Do long term deadlines exist? Obviously. Are they what agile teams should focus on? Absolutely not. Deadlines are incidental to agile thinking.
Feb 24, 2015 at 19:31 comment added user40980 @Calphool I have issue with saying that deadlines are waterfall (they exist no matter what methodology is used - they even exist for cowboy coders) and wrong (they exist because of external constraints of time - no more wrong than "we have to have this code run on that hardware with some minimal performance"). It is a time constraint on what an acceptable solution is. Filing taxes by April 15th is a deadline. Having the software to the distributor by Nov 1 so that it can be on the shelves by Nov 27 is a deadline. Neither of these are wrong.
Feb 24, 2015 at 18:20 comment added Calphool I have no clue why people downvoted you. I've been doing agile/xp app dev for over 10 years in a Fortune 100 company -- introduced it here as a matter of fact, and I see absolutely nothing wrong with what you said. I upvoted you back to zero, because whoever downvoted you has to be an agile newb still clinging to their old reality for God knows what reason. People are too simplistic. They think that "Software and deadlines do not work well together" is an absolute. You aim to hit EVERY sprint deadline. You just don't lie about your ability to hit long range estimated dates. It's that simple.
Feb 24, 2015 at 7:37 comment added Nagora @robertbristow-johnson Apparently "they" have no experience with real-world development. A deadline being "a reality" never stopped a project being late or incomplete. Oh, well.
Feb 24, 2015 at 4:15 comment added robert bristow-johnson boy, they dislike your rant against monolithic deadlines more than mine. good job, N.
Feb 23, 2015 at 21:46 review First posts
Feb 23, 2015 at 22:01
Feb 23, 2015 at 21:43 history answered Nagora CC BY-SA 3.0