Isn't Beck the Dr. Oz of software management? He's built a career on cargo cult practices that destroy software developers. Pushing agile he's done more harm than Tony Hoare's billion dollar mistake.
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.
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.
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.
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.
> (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.
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.
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.
> He's built a career on cargo cult practices that destroy software developers.
That's a very strong statement for which I don't believe you have the data to back it up. He (or his practices) has not 'destroyed' software developers. Not sure if you were working in the pre-agile era, I do agree some shops take to the extreme, but what we had before was a complete mess.
That’s an interesting viewpoint, even surprising to me. Can you be more concrete about what you think is wrong with the agile software development movement Kent Beck co-founded, and how it destroys developers?
It has turned into a system that keeps developers in a constant state of crunch time. It simultaneously pushes all responsibility for delivery on to devs under the guise of “the team self organises” whilst stripping them of any real autonomy to actually feel a sense of satisfaction in completing tasks and delivering projects.
When something goes well the anonymity that “the team” creates to the wider business means that praise goes to the project managers and product owners who, realistically, probably did very little beyond the kick off to deliver.
Indeed. In agile, successes belong to the team; failures belong to the individual developer. The higher-ups will know that it was your commit that broke the build, and they know exactly how many story points you delivered -- or did not deliver -- per sprint by your JIRA metrics.
It's semi-reasonable. The individual parts are reasonable but putting it together to create a branded methodology™ which is "my way or the highway" was the beginning of the agile-industrial complex as we know it.
You might make the case that Kent Back has actually put together two lines of code and run a compiler (even started JUnit) and the thousands of imitators who talk just like Kent Beck haven't, but if you're going to be critical of the agile-industrial complex you have to be critical of the founder too, who created a toxic style of discourse and a piratical business model of agile consulting.
The agile-industrial complex came from Scrum and its certified trainers, and its imitators such as SaFE, not Kent Beck and XP. Kent disappeared for a while to raise goats in Oregon, then worked for Facebook and other companies (as an employee). He’s the last person you should be blaming for what Agile’s become.
