5 ms·
I think you're debating a strawman there. The argument is not that we need to return to other pre-agile SDLC methodologies but rather take what we've learned an
by ebiester 7y ago
I think you're debating a strawman there. The argument is not that we need to return to other pre-agile SDLC methodologies but rather take what we've learned and go further. From the article:
> Now, continuous delivery is what’s expected, and the industry is ready for the next thing. But that next thing shouldn’t be another methodology, according to Mary.
> There is no methodology in my field of software engineering that can conceivably last more than five to eight years,” she said. “Everything that is 10 years old is obsolete. Everything that is 20 years old is archaic.”
> Furthermore, she said, methodology requires codification. Beginning with the Capability Maturity Model (CMM) in the ‘90s, software development methodology meant developers had to show they had standards and that they followed them, rather than demonstrating that their standards were constantly in flux depending on consumer needs. That’s the definition of quality standards lean manufacturing practitioners in Japan originally espoused, Mary said, and they’re not compatible with methodology. Instead, they’re all about learning.
> To that end, Mary is excited about all the ways artificial intelligence will allow software engineers to learn better and faster. Automated testing, continuous deployment and cross-functional collaboration are now table stakes, Mary and Tom agreed. Cutting edge companies will discover the next great approach through an engineering mindset and a willingness to learn.
___
Consider that Mary and Tom Poppendieck were responsible for many of the Lean inclusions of the agile movement, which (largely) came from watching plant manufacturing at Toyota. Similarly, much of the DevOps movement was tied to this as well. If you want to talk about what is next, it is likely taking a first principles look at what we're doing today, questioning best practices again, and saying, "if we were going to make a manifesto in 2020, what would it look like?"
- Someone1234 7y agoYou claim I'm "debating a strawman" but then quote the article that literally says they have no alternative in mind (my chief critique) and point towards artificial intelligence to solve the issue somehow. The only "strawman" here seems to be taking my point about pre-Agile methodologies out of context, and using it to dismiss the entire idea that this article is unconstructive/has no actionable solutions.
- ulisesrmzroche 7y agoYou don't need to provide a viable alternative when you criticize something, this is a false dilemma.
- Someone1234 7y agoNobody you replied to said they shouldn't be allowed to criticize Agile. The criticism in this comment thread was that their advice wasn't actionable, not that actionability was a prerequisite in order to criticize Agile at all. There was no false dilemma here because there was no choices provided (false or otherwise), merely a weakness in an argument raised.
- ebiester 7y agoThe advice they are giving is to stop trusting methods, take the best practices that make sense, and trust your engineers to build a bespoke process from those building blocks. > “I don't care if it’s Lean or Agile, there’s no silver bullet where if you just follow this formula that somebody else followed, you’re going to be great,” she said. “So today, my favorite word is ‘engineering.’ Just let engineers be engineers.” Maybe we need to call it the Lego process. SCRUM is Duplo. Waterfall is worse Duplo. Start there if you need, but get to Lego instead. Maybe Duplo is enough for you.
- hinkley 7y ago> "Everything that is 10 years old is obsolete. Everything that is 20 years old is archaic.” Which is not entirely true since some of the best parts of Agile are XP practices that almost everybody does by default now... Someone once said that the only successful Scrum projects are also doing half of XP (as in, things Scrum doesn't prescribe but are essential anyway). I am still looking for a counterexample.
- tootie 7y agoI honestly don't understand anything that was in this article. Continuous delivery is directly applicable to agile. They are complimentary, but not even really related. From my point of view, the essence of agile development is just continuous improvement. The notion of user stories is a proxy to delivering a small unit of user value from idea to tested and deployed as quickly as possible without having to worry about future requirements.