7 ms·

I go through some of the alternatives to agile in project methodology here: https://www.ebiester.com/agile/2023/04/22/what-agile-alternative.html https://www.eb

I go through some of the alternatives to agile in project methodology here: https://www.ebiester.com/agile/2023/04/22/what-agile-alternative.html https://www.ebiester.com/agile/2023/04/22/what-agile-alterna... Go back to 2001. Which non-agile methodology would you have liked instead? RUP? How about we all end up in the PMBOK circa 2001? We take releasing monthly, weekly, or faster for granted. We take continuous integration for granted. So many of these ideas came explicitly out of agile delivery or were popularized because of it.

legulere 3y ago
No silver bullet was published 1986 advocating for incremental software development. Feedback cycles in development were always a target for optimization, but often had technological roadblocks.
- ebiester 3y ago
  That looked a lot more like Spiral development. Think about 3 month iterations where the design docs are built and approved before software development begins. It's a bunch of mini-waterfalls.
zwischenzug 3y ago
RAD?
- ebiester 3y ago
  I meant RUP - Rational Unified Process, but RAD also would work - https://en.wikipedia.org/wiki/Rapid_application_development https://en.wikipedia.org/wiki/Rapid_application_development
PaulHoule 3y ago
I've got no problem with continuous delivery. I do have a problem with sprints (instead of wrecking your project with a fake deadline every year, wreck your project with a fake deadline very month.) Granted to do sprints you have to have a better build process than a lot of shops had in the 1990s but taking a week or two to deliver just because the process says so... means a 1-day delay can snowball into a delay of weeks or months. Also there are all the meaningless meetings that people dread. The standup that inexplicably happens first thing in the morning when you struggle to remember what you did the day before. The retrospective that I only want to answer with "I am so tired at the end of this sprint that I just want to go ride my bike in the hills or drink some beer or smoke some pot or play a videogame, not sit around uncomfortably in a group of people that are either disengaged and hiding it or doing a good job of pretending to be engaged" --- To me it is fighting works to bring up the PMBOK because the PMBOK doesn't specify a particular process but it does enumerate the things that have to be managed to manage a project, in "agile the good parts" you are just addressing all of these on a weekly cycle instead of a yearly or longer cycle. I also see the rejection of PERT charts and other dependency managements as a fatal flaw for A.I. and data science projects where model training might take 1/2 of the sprint so if you don't start building your model in the first half you blow. your. sprint. every. time. I first saw people make this mistake 12 years ago and they are still making it. By making people pay attention to a bunch of fake management metrics (story points) you distract them from paying attention to the metrics that matter for a particular app. I've even seen a lack of attention to dependencies be quite harmful to teamwork in more normal software projects because if a team really understood that getting Task A done means you can be efficient at Task B and Task C they might get as much real work done in one sprint than they wind up getting done in three.
- bitwize 3y ago
  Sprints are essential to software development because they make underperformers much easier to fire. With long deadlines, a straggler can take their time and evade detection by management for months if not years, but with sprint commitments to which devs are held accountable on a consistent, fast cadence, stragglers can be easily found and eliminated. Agile in the workplace is not for you, it's for management.
  - ebiester 3y ago
    Any software process is for management. That said, you don't need sprints for that. It just looks like a monthly meeting with your manager, where they say they're disappointed in what you have so far. Then weekly meetings, and then daily micromanagement. You can micromanage in any process.
- layer8 3y ago
  Sprints are Scrum, they are neither Agile [0] nor Kent Beck’s Extreme Programming [1]. [0] https://agilemanifesto.org/ https://agilemanifesto.org/ [1] https://en.wikipedia.org/wiki/Extreme_programming https://en.wikipedia.org/wiki/Extreme_programming
  - deleted 3y ago
    [deleted]
  - bducycy 3y ago
    https://en.m.wikipedia.org/wiki/Extreme_programming_practices#Planning_game https://en.m.wikipedia.org/wiki/Extreme_programming_practice... Agile is just scrum with less steps. That said, the idea above that you can do software in year long release cycles is pretty insane. Release cycles and amount of stakeholder feedback that should be involved in the development process is unique per business and industry needs.
- ebiester 3y ago
  > (instead of wrecking your project with a fake deadline every year, wreck your project with a fake deadline very month.) I have worked in both (albeit as a junior dev), and the culture of the environment and the severity of the deadline meant much more than the space between deadlines. Deadlines at a tax company are always going to be worse than one with no high and low periods. Missing a back to school launch in edtech is going to be catastrophic, and I'd rather know sooner than later so that we can pull things out of the release. In the massive integration days, everyone had already done most of the work and there were a lot of pieces that were 70% complete, and the integration dependencies made it brutally difficult to pull something out of a release. I will defend short iterations all day long. Remember that "sustainable pace" also came out of the agile community. Kent Beck called it a "40 hour week" in XP. > The standup that inexplicably happens first thing in the morning when you struggle to remember what you did the day before. Does nobody else keep notes on their days? That said, what is important at a standup is "who needs help" or "who is waiting on something?" e.g. what is falling through the cracks? It helps to get this information on a daily basis, yes. > The retrospective that I only want to answer with "I am so tired at the end of this sprint that I just want to go ride my bike in the hills or drink some beer or smoke some pot or play a videogame, not sit around uncomfortably in a group of people that are either disengaged and hiding it or doing a good job of pretending to be engaged" I will defend retros, but only if they result in changes that make the team a better place. If I was in a retro that had low engagement, I'd explicitly call it out in the retro that the format is not generating change. > To me it is fighting works to bring up the PMBOK because the PMBOK doesn't specify a particular process but it does enumerate the things that have to be managed to manage a project, in "agile the good parts" you are just addressing all of these on a weekly cycle instead of a yearly or longer cycle. I'm not talking about 7th edition PMBOK here. Let's go back to the 2000 edition. "Each project phase is marked by completion of one or more deliverables. A deliverable is a tangible, verifiable work product such as a feasibility study, a detail design, or a working prototype. The deliverables, and hence the phases, are part of a generally sequential logic designed to ensure proper definition of the product of the project." 2.1 and 2.2 talk about waterfall and spiral before heading into stakeholder management. It follows through the entire system - consider what integrated change control looked like in those days. It's all things we take for granted now - when was the last time you had to write a design doc that was longer than 2 pages? When was the last time you got in a room to hash out and negotiate scope for a year of work? It's truly brutal! Now, this isn't to say I love Scrum. I agree that if you are letting your metrics get in the way of your work then you've done the exact wrong thing. If you know you need to start building your model early then you start building your model early. If you aren't paying attention to your dependencies, then the process has failed and maybe you jump to something else. I'm not even saying there are no flaws in agile, Scrum or otherwise! However, so many of the things that came out of agile were net positive.

legulere 3y ago

No silver bullet was published 1986 advocating for incremental software development. Feedback cycles in development were always a target for optimization, but often had technological roadblocks.

ebiester 3y ago
That looked a lot more like Spiral development. Think about 3 month iterations where the design docs are built and approved before software development begins. It's a bunch of mini-waterfalls.

zwischenzug 3y ago

RAD?

ebiester 3y ago
I meant RUP - Rational Unified Process, but RAD also would work - https://en.wikipedia.org/wiki/Rapid_application_development https://en.wikipedia.org/wiki/Rapid_application_development

PaulHoule 3y ago

I've got no problem with continuous delivery. I do have a problem with sprints (instead of wrecking your project with a fake deadline every year, wreck your project with a fake deadline very month.) Granted to do sprints you have to have a better build process than a lot of shops had in the 1990s but taking a week or two to deliver just because the process says so... means a 1-day delay can snowball into a delay of weeks or months. Also there are all the meaningless meetings that people dread. The standup that inexplicably happens first thing in the morning when you struggle to remember what you did the day before. The retrospective that I only want to answer with "I am so tired at the end of this sprint that I just want to go ride my bike in the hills or drink some beer or smoke some pot or play a videogame, not sit around uncomfortably in a group of people that are either disengaged and hiding it or doing a good job of pretending to be engaged" --- To me it is fighting works to bring up the PMBOK because the PMBOK doesn't specify a particular process but it does enumerate the things that have to be managed to manage a project, in "agile the good parts" you are just addressing all of these on a weekly cycle instead of a yearly or longer cycle. I also see the rejection of PERT charts and other dependency managements as a fatal flaw for A.I. and data science projects where model training might take 1/2 of the sprint so if you don't start building your model in the first half you blow. your. sprint. every. time. I first saw people make this mistake 12 years ago and they are still making it. By making people pay attention to a bunch of fake management metrics (story points) you distract them from paying attention to the metrics that matter for a particular app. I've even seen a lack of attention to dependencies be quite harmful to teamwork in more normal software projects because if a team really understood that getting Task A done means you can be efficient at Task B and Task C they might get as much real work done in one sprint than they wind up getting done in three.

bitwize 3y ago
Sprints are essential to software development because they make underperformers much easier to fire. With long deadlines, a straggler can take their time and evade detection by management for months if not years, but with sprint commitments to which devs are held accountable on a consistent, fast cadence, stragglers can be easily found and eliminated. Agile in the workplace is not for you, it's for management.
- ebiester 3y ago
  Any software process is for management. That said, you don't need sprints for that. It just looks like a monthly meeting with your manager, where they say they're disappointed in what you have so far. Then weekly meetings, and then daily micromanagement. You can micromanage in any process.
layer8 3y ago
Sprints are Scrum, they are neither Agile [0] nor Kent Beck’s Extreme Programming [1]. [0] https://agilemanifesto.org/ https://agilemanifesto.org/ [1] https://en.wikipedia.org/wiki/Extreme_programming https://en.wikipedia.org/wiki/Extreme_programming
- deleted 3y ago
  [deleted]
- bducycy 3y ago
  https://en.m.wikipedia.org/wiki/Extreme_programming_practices#Planning_game https://en.m.wikipedia.org/wiki/Extreme_programming_practice... Agile is just scrum with less steps. That said, the idea above that you can do software in year long release cycles is pretty insane. Release cycles and amount of stakeholder feedback that should be involved in the development process is unique per business and industry needs.
ebiester 3y ago
> (instead of wrecking your project with a fake deadline every year, wreck your project with a fake deadline very month.) I have worked in both (albeit as a junior dev), and the culture of the environment and the severity of the deadline meant much more than the space between deadlines. Deadlines at a tax company are always going to be worse than one with no high and low periods. Missing a back to school launch in edtech is going to be catastrophic, and I'd rather know sooner than later so that we can pull things out of the release. In the massive integration days, everyone had already done most of the work and there were a lot of pieces that were 70% complete, and the integration dependencies made it brutally difficult to pull something out of a release. I will defend short iterations all day long. Remember that "sustainable pace" also came out of the agile community. Kent Beck called it a "40 hour week" in XP. > The standup that inexplicably happens first thing in the morning when you struggle to remember what you did the day before. Does nobody else keep notes on their days? That said, what is important at a standup is "who needs help" or "who is waiting on something?" e.g. what is falling through the cracks? It helps to get this information on a daily basis, yes. > The retrospective that I only want to answer with "I am so tired at the end of this sprint that I just want to go ride my bike in the hills or drink some beer or smoke some pot or play a videogame, not sit around uncomfortably in a group of people that are either disengaged and hiding it or doing a good job of pretending to be engaged" I will defend retros, but only if they result in changes that make the team a better place. If I was in a retro that had low engagement, I'd explicitly call it out in the retro that the format is not generating change. > To me it is fighting works to bring up the PMBOK because the PMBOK doesn't specify a particular process but it does enumerate the things that have to be managed to manage a project, in "agile the good parts" you are just addressing all of these on a weekly cycle instead of a yearly or longer cycle. I'm not talking about 7th edition PMBOK here. Let's go back to the 2000 edition. "Each project phase is marked by completion of one or more deliverables. A deliverable is a tangible, verifiable work product such as a feasibility study, a detail design, or a working prototype. The deliverables, and hence the phases, are part of a generally sequential logic designed to ensure proper definition of the product of the project." 2.1 and 2.2 talk about waterfall and spiral before heading into stakeholder management. It follows through the entire system - consider what integrated change control looked like in those days. It's all things we take for granted now - when was the last time you had to write a design doc that was longer than 2 pages? When was the last time you got in a room to hash out and negotiate scope for a year of work? It's truly brutal! Now, this isn't to say I love Scrum. I agree that if you are letting your metrics get in the way of your work then you've done the exact wrong thing. If you know you need to start building your model early then you start building your model early. If you aren't paying attention to your dependencies, then the process has failed and maybe you jump to something else. I'm not even saying there are no flaws in agile, Scrum or otherwise! However, so many of the things that came out of agile were net positive.