I’ve seen a few, but it’s still kind of controversial. That being said, there is a time and a place for agile where it works, but also there is a team composition and a style of agile which works and that style tends to piss off micromanaging middle managers, so it rarely is allowed.
My take is based on years of interaction with companies and friends in other companies. The biggest problem isn’t necessarily Agile, but instead that agile is not intended for long term projects. Agile is fantastic in short turnaround interactions such as web dev, and because these short turnaround places have such easily visible results, managers take them to be gospel. Thus comes Corporate Agile: https://web.archive.org/web/20240524230754/https://bits.danielrothmann.com/corporate-agile Link is from the Internet archive because I can’t find his new site if he moved.
Long story short, corporate agile is the agile the bosses want, as it allows them to be constantly involved with more and more “agile” meetings. You know. Meetings. The antithesis of Agile. The place productivity goes to die. I had to remind our bosses that Agile dictated that stand ups included the developers and the scrum master ONLY multiple times and pointed them to the agile training they gave me. Didn’t matter. They’re the boss. This is a pretty common breakdown in Agile. So, that turned daily standup into daily meeting, since the quick status updates now had to be broken down for the boss. Every. Single. Day.
Agile at its most basic is intended to reduce meetings to once a week so the rest of the time can be spent developing. Every company I know starts including devs in at least 300% more meetings (even junior devs) after switching to Agile for at least 6 months. And on average, it takes half an hour for a programmer to return to the level of productivity they hit before any interruption. This is generally due to the limitations of working memory. (Many research papers on this if you want.)
But to get back to the original point. Because agile concentrates on short immediately tangible and verifiable benefits, any progress that takes longer than a sprint isn’t allowed. (It actually is, with proper implementation, as Agile is supposed to be edited on a team by team basis to make things work, but companies want everyone on exactly the same page.) Guess what doesn’t have immediately tangible and verifiable benefits? That’s right, research. Guess what it’s still in a research phase? Aside from basically anything that isn’t in market yet, self driving technology is very much research driven. Lots of trial, error, and long development cycles. Longer than a sprint for sure. And anyone who says self driving is in market should try an exercise if finding one level 5 self driving car that hasn’t been recalled due to false marketing or safety concerns. The technology isn’t there yet. It could be getting there, but profits are getting in the way of progress.
I’ve seen a few, but it’s still kind of controversial. That being said, there is a time and a place for agile where it works, but also there is a team composition and a style of agile which works and that style tends to piss off micromanaging middle managers, so it rarely is allowed.
I had an article saved in my work slack before I left that company (for health reasons), but a currently popular one seems to be this one: https://johnfarrier.com/agile-failure-what-drives-268-higher-failure-rates/
My take is based on years of interaction with companies and friends in other companies. The biggest problem isn’t necessarily Agile, but instead that agile is not intended for long term projects. Agile is fantastic in short turnaround interactions such as web dev, and because these short turnaround places have such easily visible results, managers take them to be gospel. Thus comes Corporate Agile: https://web.archive.org/web/20240524230754/https://bits.danielrothmann.com/corporate-agile Link is from the Internet archive because I can’t find his new site if he moved.
Long story short, corporate agile is the agile the bosses want, as it allows them to be constantly involved with more and more “agile” meetings. You know. Meetings. The antithesis of Agile. The place productivity goes to die. I had to remind our bosses that Agile dictated that stand ups included the developers and the scrum master ONLY multiple times and pointed them to the agile training they gave me. Didn’t matter. They’re the boss. This is a pretty common breakdown in Agile. So, that turned daily standup into daily meeting, since the quick status updates now had to be broken down for the boss. Every. Single. Day.
Agile at its most basic is intended to reduce meetings to once a week so the rest of the time can be spent developing. Every company I know starts including devs in at least 300% more meetings (even junior devs) after switching to Agile for at least 6 months. And on average, it takes half an hour for a programmer to return to the level of productivity they hit before any interruption. This is generally due to the limitations of working memory. (Many research papers on this if you want.)
But to get back to the original point. Because agile concentrates on short immediately tangible and verifiable benefits, any progress that takes longer than a sprint isn’t allowed. (It actually is, with proper implementation, as Agile is supposed to be edited on a team by team basis to make things work, but companies want everyone on exactly the same page.) Guess what doesn’t have immediately tangible and verifiable benefits? That’s right, research. Guess what it’s still in a research phase? Aside from basically anything that isn’t in market yet, self driving technology is very much research driven. Lots of trial, error, and long development cycles. Longer than a sprint for sure. And anyone who says self driving is in market should try an exercise if finding one level 5 self driving car that hasn’t been recalled due to false marketing or safety concerns. The technology isn’t there yet. It could be getting there, but profits are getting in the way of progress.