Timeline for Are deadlines Agile?
Current License: CC BY-SA 3.0
45 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 6, 2018 at 15:21 | answer | added | Murph | timeline score: 1 | |
| Nov 6, 2018 at 11:42 | answer | added | k3b | timeline score: 0 | |
| Nov 5, 2018 at 21:04 | comment | added | Rob Crawford | Sprints are deadlines. What's not agile is a required delivery date AND a required set of functionality. | |
| Nov 5, 2018 at 14:49 | answer | added | Juh_ | timeline score: 3 | |
| Dec 6, 2016 at 1:05 | comment | added | JeffO | @Pascal - That's why it's called an estimate. If you're working on a project that has a must be completed by date for a very large set of fixed features determined at the very beginning of the project, why bother being agile? Do a few sprints and reevaluate either the due date or what features you estimate may get done. In reality, that's the best you can do. | |
| Nov 10, 2016 at 18:52 | comment | added | Pascal | @JeffO It cant when its based on estimations...Then you cheat yourself if you believe you can deliver at the right day. | |
| Jul 6, 2016 at 7:29 | comment | added | Masood Khaari | There are some good ideas in this writing: stackoverflow.com/a/1144723/908336 | |
| Feb 25, 2015 at 21:39 | comment | added | psr | Some of my deadlines have proved pretty agile. | |
| Feb 25, 2015 at 4:06 | answer | added | CodeGnome | timeline score: 8 | |
| Feb 25, 2015 at 0:37 | comment | added | jpmc26 | Aren't semantics wonderful, everyone? Whether something is "Agile" is not what you should be focusing on. Just because you label something doesn't make it a bad or good idea. Focus on having a realistic, successful workflow for developing your software. If the practices under the "Agile" label work for your team, wonderful; use them. If not, deviate from the label and do what works. And be willing to change your process as the team learns from past mistakes. (Really, that last one is as "agile" as you can get.) | |
| Feb 24, 2015 at 22:26 | vote | accept | stevebot | ||
| Feb 24, 2015 at 21:30 | history | edited | stevebot | CC BY-SA 3.0 | clarifying what a deadline is by given a common definition |
| Feb 24, 2015 at 21:20 | vote | accept | stevebot | ||
| Feb 24, 2015 at 21:24 | |||||
| Feb 24, 2015 at 21:16 | comment | added | Calphool | There are some teams that manage to implement it more-or-less fully. It requires a lot of management buy in though. | |
| Feb 24, 2015 at 21:13 | vote | accept | stevebot | ||
| Feb 24, 2015 at 21:19 | |||||
| Feb 24, 2015 at 21:09 | comment | added | Eric King | @Calphool I would substitute Scrum with Scrumbut. I don't think I've ever met a team that claims to be using Scrum that actually does Scrum, by the book. :-) | |
| Feb 24, 2015 at 18:55 | comment | added | Calphool | What irks me is when we pretend that Scrum isn't primarily how agile is implemented in industry. Ever been to a conference? Seen them ask which methodologies people are using? Scrum gets 95% of the crowd. Kanban = dumbed-down Scrum. XP is primarily engineering practices, and doesn't tell you much about how to manage the lifecycle. That leaves Scrum as the primary means of implementing agile. Yes, agile is technically a way of thinking, scrum is technically an implementation of that way of thinking. However, agile itself is an implementation of Lean. It's turtles all the way down. | |
| Feb 24, 2015 at 14:40 | comment | added | sleske | Note that "Agile" usually encompasses more methods/practices than just Scrum (for example Extreme Programming and Kanban). It just irks me when people think Agile=Scrum. | |
| Feb 24, 2015 at 2:46 | answer | added | Dogs | timeline score: 15 | |
| Feb 23, 2015 at 23:38 | comment | added | Jules | Here's Ron Jeffries' (one of the original authors of the Agile Manifesto) take on deadlines: xprogramming.com/articles/jatmakingthedate | |
| Feb 23, 2015 at 22:01 | answer | added | stevebot | timeline score: 12 | |
| S Feb 23, 2015 at 21:43 | answer | added | Nagora | timeline score: 1 | |
| S Feb 23, 2015 at 21:43 | history | protected | CommunityBot | ||
| Feb 23, 2015 at 21:41 | comment | added | Calphool | Added below. :-) | |
| Feb 23, 2015 at 21:40 | answer | added | Calphool | timeline score: 9 | |
| Feb 23, 2015 at 21:40 | answer | added | user144228 | timeline score: 0 | |
| Feb 23, 2015 at 21:38 | comment | added | stevebot | @Calphool Care to write an answer? Your comment is insightful and is adding a POV which I do not see in the other answers. | |
| Feb 23, 2015 at 21:26 | comment | added | Calphool | I would say that delivery each sprint is non-negotiable. You assess the work, you put card sizes on it, and you load up enough to keep your team busy until the sprint ends (and the sprint should be small -- anything from a week to a month). "Delivery deadlines" should be based on historical trend of completed work against anticipated work. Agile adds/removes nothing from the old "cost/time/scope" constraint idea, it simply uses scope as the preferred method of managing slippage on the basis that better prioritization against scope is generally preferable to spending more money or time. | |
| Feb 23, 2015 at 21:17 | answer | added | robert bristow-johnson | timeline score: -3 | |
| Feb 23, 2015 at 21:10 | comment | added | stevebot | @EricKing I never said sprints have estimated dates. Work that is estimated, along with my teams velocity implies that certain planned features will likely be done on an estimated date. | |
| Feb 23, 2015 at 21:08 | answer | added | user40980 | timeline score: 27 | |
| Feb 23, 2015 at 21:04 | comment | added | Eric King | Sprints shouldn't have "estimated dates". Sprints should be pre-defined time-boxes. What gets accomplished during each sprint may vary, but the sprints' durations shouldn't. | |
| Feb 23, 2015 at 21:00 | comment | added | stevebot | @JeffO I am saying Sprints are based on estimated work and my teams velocity. I can give my client an estimated date based on my teams velocity for when a feature should be done. THAT is transparency and that is Agile. | |
| Feb 23, 2015 at 21:00 | review | Close votes | |||
| Feb 24, 2015 at 3:57 | |||||
| Feb 23, 2015 at 20:58 | answer | added | br3w5 | timeline score: 18 | |
| Feb 23, 2015 at 20:55 | comment | added | JeffO | Are you saying you periodically have your clients review the software after a sprint, but they have no idea how long it will take nor what functionality to expect? I get future sprints are adjusted based on previous sprints and may have more accuracy, but your next sprint has a deadline with an expectation of certain functionality. | |
| Feb 23, 2015 at 20:42 | comment | added | stevebot | @JeffO a Sprint is a commitment, which shifts based on the velocity of your team. Deadlines are IMO, commitments without honesty or transparency to the client. They do not take into account velocity or the multitude of other risks that go into making software projects. | |
| Feb 23, 2015 at 20:35 | history | tweeted | twitter.com/#!/StackProgrammer/status/569958712359706624 | ||
| Feb 23, 2015 at 20:34 | comment | added | JeffO | Isn't as sprint a deadline? | |
| Feb 23, 2015 at 20:14 | answer | added | Arseni Mourzenko | timeline score: 5 | |
| Feb 23, 2015 at 20:14 | answer | added | Encaitar | timeline score: 20 | |
| Feb 23, 2015 at 20:11 | answer | added | Eric King | timeline score: 158 | |
| S Feb 23, 2015 at 20:00 | history | suggested | pietromenna | CC BY-SA 3.0 | Small changes for better visualization |
| Feb 23, 2015 at 19:58 | review | Suggested edits | |||
| S Feb 23, 2015 at 20:00 | |||||
| Feb 23, 2015 at 19:55 | history | asked | stevebot | CC BY-SA 3.0 |