3 ms·

Major software projects can't be built in 2-4 weeks. They're still inherently iterative though, so keeping iterations relatively small is valuable.

SkyPuncher 3y ago
Most major projects can have an iteration delivered in 2 to 4 weeks. It might be a trivial component of the entire system, but it's still progress. I'm on a multi-month project. Our first sprint's goal is: * Get the repos in place. * Get a dummy endpoint running and deployed * Derisk some things on the FE It's not much different than building, say a house. You can demonstrate progress in small pieces. Foundation poured, framing up, roof on, sheathing on, etc, etc.
- khazhoux 3y ago
  Those sound exactly like the things any team would do on a new project, regardless of calling it Agile, Scrum, Kanban, or whatever. I just don't see any difference between this and just having the philosophy: "Do first things first; do the next most important things next; don't bite off giant chunks but instead break them up."
  - crazygringo 3y ago
    Because lots of teams don't break things up. They do give giant chunks to each person, not check in, and then magically expect them all to integrate on the end and on time. This is precisely the common/naive practice that Agile/Scrum/Kanban/etc. is specifically reacting to.
    - SkyPuncher 3y ago
      Yep. This is exactly my experience. You don't need to get crazy about things, but having the defined time periods forces people to actually think about how they're going to deliver things.
  - Cthulhu_ 3y ago
    It's that a lot of people don't have (didn't have?) this philosophy. My previous employer worked in telecom; it wasn't uncommon to have one major feature be under development by one or two guys for eight months at a time. It was specialist work, sure, and the guys knew what they were doing (20-40 years in the business) but then integrating and releasing it was a big job.
psunavy03 3y ago
No one is expecting you to build the entire thing in 2-4 weeks (1-4 weeks to be accurate if we're talking Scrum). The intent is to have a potentially shippable increment at the end of 1-4 weeks which you can demo to a customer (or someone who can credibly speak for them) and get feedback. The idea is that when you combine software, markets, and people's opinions, you're now in a complex adaptive system, where you acting within the system changes the system, and where you can never know enough about it to make long-term plans any more than you can forecast what the weather will be on management's "due date." So you use fast feedback loops to learn as you go and build the right thing as it's needed now, not two years ago.

SkyPuncher 3y ago

Most major projects can have an iteration delivered in 2 to 4 weeks. It might be a trivial component of the entire system, but it's still progress. I'm on a multi-month project. Our first sprint's goal is: * Get the repos in place. * Get a dummy endpoint running and deployed * Derisk some things on the FE It's not much different than building, say a house. You can demonstrate progress in small pieces. Foundation poured, framing up, roof on, sheathing on, etc, etc.

khazhoux 3y ago
Those sound exactly like the things any team would do on a new project, regardless of calling it Agile, Scrum, Kanban, or whatever. I just don't see any difference between this and just having the philosophy: "Do first things first; do the next most important things next; don't bite off giant chunks but instead break them up."
- crazygringo 3y ago
  Because lots of teams don't break things up. They do give giant chunks to each person, not check in, and then magically expect them all to integrate on the end and on time. This is precisely the common/naive practice that Agile/Scrum/Kanban/etc. is specifically reacting to.
  - SkyPuncher 3y ago
    Yep. This is exactly my experience. You don't need to get crazy about things, but having the defined time periods forces people to actually think about how they're going to deliver things.
- Cthulhu_ 3y ago
  It's that a lot of people don't have (didn't have?) this philosophy. My previous employer worked in telecom; it wasn't uncommon to have one major feature be under development by one or two guys for eight months at a time. It was specialist work, sure, and the guys knew what they were doing (20-40 years in the business) but then integrating and releasing it was a big job.

psunavy03 3y ago

No one is expecting you to build the entire thing in 2-4 weeks (1-4 weeks to be accurate if we're talking Scrum). The intent is to have a potentially shippable increment at the end of 1-4 weeks which you can demo to a customer (or someone who can credibly speak for them) and get feedback. The idea is that when you combine software, markets, and people's opinions, you're now in a complex adaptive system, where you acting within the system changes the system, and where you can never know enough about it to make long-term plans any more than you can forecast what the weather will be on management's "due date." So you use fast feedback loops to learn as you go and build the right thing as it's needed now, not two years ago.