4 ms·

> since we still get people who want estimates months in advance Its almost like the real world has deadlines and interactions with 3rd parties who need to sch

by nikau 3y ago

> since we still get people who want estimates months in advance Its almost like the real world has deadlines and interactions with 3rd parties who need to schedule things too.

deleted 3y ago
[deleted]
deleted 3y ago
[deleted]
seadan83 3y ago
I think the issue is in the intrinsic unpredictability of software development and secondly that Scrum is not even intended to help with that scheduling problem (it's meant to protect the developers schedule, not the clients schedule!). What do I mean by those two claims? The first, software development is inheritently unpredictable. To explain with an analogy, software development is more like writing a mystery novel than it is like building a house. In construction, the steps for each part are mechanical and the time to do so is well trodden and predictable. When a construction project starts, you can schedule the concrete trucks for specific days and generally be 99% right. Software development on the other hand is more liking writing a murder novel. Rather than commiting to writing a novel which you then might not like, instead we say, "okay, we're going to show you each chapter after we write it and you'll reserve the right to change up the entire story entirely as you see each chapter that is written." That allows the customer things like: "ooh, I really like this secondary character, could we start writing them into the story more!" From a requirements perspective, it's akin to film-making (film making is even more predictable than software development!!) - it's like getting the requirements: "write me a star wars prequel movie!", I then go off and do it and you get Jar-Jar binks - it's a shame to find that out all the way after the film has been made. So, the main conflict I see is we are trying to use a process to say things like: "this book will be done in about 3 months [6 iterations, because we have estimated the product backlog and divided by a well known velocity, and we have even left time for unknown ops problems, bugs and even tech debt pay-down!]. At about the 2 month mark we can bring in the compliance and legal teams (or something like that)." Yet, all the Scrum process really allows is to give the client the right to change direction, it's not there to protect that 3 month time frame. Thus, the claim it's not meant to protect the clients schedule, Scrum is not there to protect that 3 month time frame (if anything it's there to help ensure that time frame can be adjusted [probably upwards] as the product develops) In a way, it's like blaming the maps app for scheduling problems. The maps app can help, but inherently it's not there to make sure a meeting can start on time.
- nikau 3y ago
  > From a requirements perspective, it's akin to film-making (film making is even more predictable than software development!!) - Its actually the exact opposite - when making films they don't shoot the scenes in the sequence they are viewed, they will shoot every scene at the same location in one go due to the cost of setting up equipment, getting staff onsite etc. The exact opposite of agile.
  - seadan83 3y ago
    I was not very clear in that example. My intent was to use 'film-making' as a bit of an analogy for waterfall. IE: requirements are defined in the beginning and the end date is fixed. It would be a very different concept if after shooting each scene a potential audience could decide they want the whole thing up to that point to be re-done to tell a different story and that they want to change the ending every couple of weeks. Scrum really jettisons a "final" date idea, which is something you have in movie-making. Scrum tries to optimize for reactiveness so that a correct product can be made, those potential changes in direction allowed by Scrum all add time to the final product being completed. It's an interesting analogy I think overall because software development is viewed akin to construction of a building. On the spectrum of predictable schedules, movie making and construction are on the predictable sides of the spectrum, software development is way on the other side of that spectrum. In short, when someone says "hey, in the real world we have things like 3 month deadlines. Using Scrum, we'll help ensure we hit that!". I just want to point out that Scrum is not a tool to help hit a 3 month deadline at all. It's just there to ensure that you don't commit to a 3 month deadline, build something that turns out to be the wrong thing and needs to be thrown away at that 3 month mark. It's actually a process to extend deadlines! Every 2 weeks you can get a change in direction that causes a one week (or more) of extra scope increase and/or churn or redoing previous work.

by nikau 3y ago

> since we still get people who want estimates months in advance Its almost like the real world has deadlines and interactions with 3rd parties who need to schedule things too.

deleted 3y ago

[deleted]

deleted 3y ago

[deleted]

seadan83 3y ago

I think the issue is in the intrinsic unpredictability of software development and secondly that Scrum is not even intended to help with that scheduling problem (it's meant to protect the developers schedule, not the clients schedule!). What do I mean by those two claims? The first, software development is inheritently unpredictable. To explain with an analogy, software development is more like writing a mystery novel than it is like building a house. In construction, the steps for each part are mechanical and the time to do so is well trodden and predictable. When a construction project starts, you can schedule the concrete trucks for specific days and generally be 99% right. Software development on the other hand is more liking writing a murder novel. Rather than commiting to writing a novel which you then might not like, instead we say, "okay, we're going to show you each chapter after we write it and you'll reserve the right to change up the entire story entirely as you see each chapter that is written." That allows the customer things like: "ooh, I really like this secondary character, could we start writing them into the story more!" From a requirements perspective, it's akin to film-making (film making is even more predictable than software development!!) - it's like getting the requirements: "write me a star wars prequel movie!", I then go off and do it and you get Jar-Jar binks - it's a shame to find that out all the way after the film has been made. So, the main conflict I see is we are trying to use a process to say things like: "this book will be done in about 3 months [6 iterations, because we have estimated the product backlog and divided by a well known velocity, and we have even left time for unknown ops problems, bugs and even tech debt pay-down!]. At about the 2 month mark we can bring in the compliance and legal teams (or something like that)." Yet, all the Scrum process really allows is to give the client the right to change direction, it's not there to protect that 3 month time frame. Thus, the claim it's not meant to protect the clients schedule, Scrum is not there to protect that 3 month time frame (if anything it's there to help ensure that time frame can be adjusted [probably upwards] as the product develops) In a way, it's like blaming the maps app for scheduling problems. The maps app can help, but inherently it's not there to make sure a meeting can start on time.

nikau 3y ago
> From a requirements perspective, it's akin to film-making (film making is even more predictable than software development!!) - Its actually the exact opposite - when making films they don't shoot the scenes in the sequence they are viewed, they will shoot every scene at the same location in one go due to the cost of setting up equipment, getting staff onsite etc. The exact opposite of agile.
- seadan83 3y ago
  I was not very clear in that example. My intent was to use 'film-making' as a bit of an analogy for waterfall. IE: requirements are defined in the beginning and the end date is fixed. It would be a very different concept if after shooting each scene a potential audience could decide they want the whole thing up to that point to be re-done to tell a different story and that they want to change the ending every couple of weeks. Scrum really jettisons a "final" date idea, which is something you have in movie-making. Scrum tries to optimize for reactiveness so that a correct product can be made, those potential changes in direction allowed by Scrum all add time to the final product being completed. It's an interesting analogy I think overall because software development is viewed akin to construction of a building. On the spectrum of predictable schedules, movie making and construction are on the predictable sides of the spectrum, software development is way on the other side of that spectrum. In short, when someone says "hey, in the real world we have things like 3 month deadlines. Using Scrum, we'll help ensure we hit that!". I just want to point out that Scrum is not a tool to help hit a 3 month deadline at all. It's just there to ensure that you don't commit to a 3 month deadline, build something that turns out to be the wrong thing and needs to be thrown away at that 3 month mark. It's actually a process to extend deadlines! Every 2 weeks you can get a change in direction that causes a one week (or more) of extra scope increase and/or churn or redoing previous work.