3 ms·
Paraphrasing here. "Agile is the worst software development process, except all the rest" More seriously, doing big upfront design was a really bad idea. Agile
by corpMaverick 8y ago
Paraphrasing here. "Agile is the worst software development process, except all the rest"
More seriously, doing big upfront design was a really bad idea. Agile and more specifically Scrum brings a number of ceremonies to keep the "managers" happy and allow the transition. When and if ever companies understand that they can trust their software engineers they can let them to their job. These ceremonies are more like a security blanked for the non software engineers who are frequently clueless about how software is developed.
I prefer to focus on the Agile principles. My favorite is "Continuous attention to technical excellence and good design enhances agility."
- pif 8y ago> Agile is the worst software development process, except all the rest. That's not my opinion. I'll quote Alex' worlds: In the past decade or so, we’ve seen a lot of “fad development methodologies” crop up. [...] They all promise the same thing – cheaper, better software built faster – and they all generally fail to deliver. Like fad diets, these methodologies try to avoid a simple, painful truth: you have to know what to build before you can start building it. (http://thedailywtf.com/articles/The-Great-Pyramid-of-Agile http://thedailywtf.com/articles/The-Great-Pyramid-of-Agile)
- beat 8y ago"Faster" (and "cheaper") are the problems here. I believe Scrum embedded this flaw in its very language by calling the iterative cycle "sprints". You don't run a marathon by breaking it into a bunch of sprints - sprinting in a marathon is foolish. But the language suggests speed. If the Scrum cycle were called "iterations" rather than "sprints", things would be a lot better. Language matters.
- fatnoah 8y ago>If the Scrum cycle were called "iterations" rather than "sprints", things would be a lot better. Agree. To me, the real value of Scrum when done right is the focus on delivering increments of value in a sustainable, repeatable way. Scrum provides a means and the existing hype/buzz/literature gives me some leverage in dealing with non-technical managers and getting them to buy-in to the process.
- beat 8y agoMy favorite feature of Scrum on paper, as designed, is the idea that any change to the requirements for a sprint means the sprint ends right there, and a new sprint is started. It's great for "Just leave us the hell alone for two weeks, and we'll deliver what we promised we'll deliver over these two weeks". Of course, it never works that way. The sprint becomes an arbitrary schedule, and the work of the sprint becomes mutable. Ugh. Sudden, OMG THIS IS IMPORTANT WE MUST DO THIS RIGHT NOW changes in direction are the bane of productivity.
- IggleSniggle 8y agoThis is an interesting language problem. I think part of the reason the words are “agile” and “sprint” is that it’s essentially a way for engineering to communicate iterative progress, convince management that yes, work is getting done, and that really, we’re moving as fast as we can. That there is deception in the wording is, imho, a pragmatic response to management never seeming to understand software development at face value. Eng: “No, we can’t move any faster. This is literally the best we can do. Doing this right, and doing it as fast as possible, involves care and intentionality.” Mgmt; “Can’t you just work more hours right now?” “No, that will not help.” “You guys are lazy. We regularly pull 70 hour weeks to get all the meetings and emails in.” “You know what? Next week, we are going to deliver x,y, and z. Promise. It may mean the overall vision takes longer to execute, but I want to show you how hard we work. We are getting a ton done. We are moving as fast as we can. We are sprinting! Now leave us alone and let us do the work necessary to execute the vision.” Mgmt: “Hey other managers, look how much MY team is kicking ass. They are delivering x, y, and z ON SCHEDULE AND AS PROMISED. They are sprinting, and they basically never tell me ‘no’! Sure, we don’t need y or z to execute the vision, but how else were we to know that? If we hadn’t tried it out? They just sigh and go back to their caves, EVERY WEEK. I’m the best manager.” It’s basically a way to educate about iterative development while giving management a way to save face, no matter how inefficient it may be. A healthy org could do it without the deception, but corporations are krakens.
- gronne 8y agoAdd to that: you have to be prepared for sudden changes in functionality and scope. If you dont then the painful truth mentioned will only apply to utopia (never been there but I hear everyone is rich and thin with infinite throughput).
- corpMaverick 8y agoThat is the thing. You rarely know what you need to build. With big upfront design your are speculating, the design is a house of cards. Agile amplifies learning. You learn as you build because you get early and frequent feedback. Agile relies on having very capable product owners who understand what needs to built. Waterfall relies on design documents. Which will be all wrong anyway if you didn't have a capable product owner driving the vision of the product.