3 ms·

Genuine question, Do we need Agile, Scrum, Kanban, Waterfall, etc. ? It's glorified to-do lists with an opinionated cadence on how often features get deployed.

by screye 3y ago

Genuine question, Do we need Agile, Scrum, Kanban, Waterfall, etc. ? It's glorified to-do lists with an opinionated cadence on how often features get deployed. Do we really need an entire discipline to communicate those simple things. How flexible are we with requirements ? How many stages are in the to-do list ? How many hierarchies are in the todo list? How often do we features to be deployed ? What more do you need to know ? Takes 1 long meeting establish a well-communicated bespoke development cycle for each team. Do we really need a phrase for that ? My experience tells me that the system gets sub-optimally molded to suit the implicit development style of the team whether you like it or not.

__pache__ 3y ago
No, we don't need all this nonsense (on small teams) I hate all the meetings, which we can "feel" don't make sense. When we all "feel" a meeting makes sense, we naturally hop in. Totally different vibes.
lmm 3y ago
> It's glorified to-do lists with an opinionated cadence on how often features get deployed. Do we really need an entire discipline to communicate those simple things. Apparently we do, since we still get people who want estimates months in advance (and then want to punish you if those estimates were wrong), who want to commit to a plan and then follow it and then change it without changing the deadlines, .... > My experience tells me that the system gets sub-optimally molded to suit the implicit development style of the team whether you like it or not. Isn't that precisely the proof that the development processes haven't been communicated clearly enough and got enough buy-in/consensus?
- 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.

by screye 3y ago

__pache__ 3y ago

No, we don't need all this nonsense (on small teams) I hate all the meetings, which we can "feel" don't make sense. When we all "feel" a meeting makes sense, we naturally hop in. Totally different vibes.

lmm 3y ago

> It's glorified to-do lists with an opinionated cadence on how often features get deployed. Do we really need an entire discipline to communicate those simple things. Apparently we do, since we still get people who want estimates months in advance (and then want to punish you if those estimates were wrong), who want to commit to a plan and then follow it and then change it without changing the deadlines, .... > My experience tells me that the system gets sub-optimally molded to suit the implicit development style of the team whether you like it or not. Isn't that precisely the proof that the development processes haven't been communicated clearly enough and got enough buy-in/consensus?

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.