3 ms·
If teams can't consistently implement "Agile", then maybe it's not really that great of a method. Or perhaps it's not much of a method at all, just a bunch of p
by Cacti 10y ago
If teams can't consistently implement "Agile", then maybe it's not really that great of a method. Or perhaps it's not much of a method at all, just a bunch of pseudo-philosophical nonsense, measuring things that aren't relevant and using methods whose correlation with actual results is near random.
I mean, look. We _know_ there is no single project management method that produces good results across the board. That is a fundamental result of undecidability (and related no free lunch theorems). There is no single method, there never has been, and there never will be. The teams that work well do so because they are good at what they do, they have a specific skillset for what they are working on at that time, they work well together and adapt to the circumstances, and frankly, are a bit lucky. That is a moment in time. Most, if not all, teams cannot reproduce that result consistently year after year, nevermind among different teams. It is a fleeting attribute, not a systemic byproduct of _process_, unless the field is so narrowed so far that optimization is in fact possible (which is exceedingly rare, and certainly doesn't manifest itself in general software development).
- AnimalMuppet 10y agoA big part of the point of "agile" is that process is something that you hack/adjust/tune. If you're trying to do agile by dogmatically following a process, expect to fail. When you can say, "Let's tweak our process in this way for the next two sprints, and see if it works better than what we've been doing", that's agile. But you're right, it's fragile. The reason it's fragile is because, as you go up the management tree, eventually agile runs into big-process management. And big-process management wants their reports so that "they know what is going on". Real agile looks sloppy, out of control, even though it delivers more value to the business faster than big-process development does. So real agile scares big-process management, and eventually gets killed by a layer of management that can't deal with it.
- js8 10y ago"When you can say, "Let's tweak our process in this way for the next two sprints, and see if it works better than what we've been doing", that's agile." We did that in our company for about 3 years. Then some guy at the top decided (or maybe that's how he got misunderstood in the middle) what we are doing is not true agile, or whatever, and we are back at square one. So he basically decided to waste all the time we spent in retrospectives and all what we learned. It's like when people say that true Christianity is about forgiveness and other values, which sounds great, until you run into some fundamentalist with the holy book.
- jwdunne 10y agoI liked that comparison - I've thought about both and never made the link. Perhaps there's a general rule of thumb in there some where: "Any idea designed to improve is doomed to eventually worsen"
- AnimalMuppet 10y ago"Any process that requires judgment and understanding will eventually be implemented by someone who has neither."
- jeremiep 10y ago"Agile" has become a meaningless term I feel like. It used to denote the four values of the manifesto for agile software development and devolved into an entire industry of gimmicky practices sold by mediocre engineers who can't even make the simplest of CRUD apps. I'm still very much in favor of these four values. But in and of themselves they require a lot of thought and analysis in a recursive feedback loop to be used properly. What we have instead are mindlessly rigid processes for the sake of having a methodology and a huge track record of epic failures in Agile projects. It has become like a drug - people chase that initial high they will never, ever get back.
- tootie 10y agoGood results require a good team, so you can still easily fail even with a perfect process if your team isn't good. The fundamental tactical process we follow is to make sure every task has clearly defined entrance and exit criteria. Work doesn't start until entrance criteria are met, and it isn't done until exit criteria are met. Each task is the smallest possible feature that delivers incremental value and tasks are listed in priority order. That's the whole deal. Scrum or Kanban layer some more controls on top of that just to handle volume or big organizations. Most attempts at measurement are completely in vain.
- sanderjd 10y agoThose are exactly the things I've been frustrated by. Attempting to break everything down into small chunks with well defined entry and exit criteria can easily be more time consuming and lead to more analysis paralysis than just giving an experienced and trusted team member a goal and letting them work toward a solution, with lots of communication as they go. I suppose YMMV applies, as usual with this sort of thing!
- Retric 10y agoI think people look at Agile from the wrong angle. Agile is old enough that many people don't know what pre-Agile development was like. Often teams would pretend everything is fine until months after projects should have shipped. Pretending things are great while looking for a job or jumping projects was really common. Even cargo cult Agile tends to make it clear things are going to fail ahead of time. Which is huge. Sure, that does not mean the project is good or profitable, because on it's own it's a long way from enough. But, nobody cares about process when things are great, it's when things are failing and you want to get horribly broken to break even where even cargo cult Agile can help.
- braveo 10y ago> Agile is old enough that many people don't know what pre-Agile development was like. Often teams would pretend everything is fine until months after projects should have shipped. Pretending things are great while looking for a job or jumping projects was really common. That's not true, Agile didn't save the software industry, it's just a different methodology with different ideas. The "software crisis " still exists today the same as it did then, the only thing that's changed is young people who don't have the necessary perspective to understand that.
- Karunamon 10y agoIf teams can't consistently implement "Agile", then maybe it's not really that great of a method. Alternative explanation: There are a lot of shitty teams out there. Agile requires a culture shift, not just adoption of a handful of practices from a book. From my limited experience, it works very, very well if, and only if the culture shift accompanies the process shift. If the process is the only thing that changes.. it's painful. Agile process is pointless (and probably actively harmful) if people are so close minded they won't adopt the associated culture.
- deleted 10y ago[deleted]
- marcosdumay 10y agoA method that enables a great (at some random dimension) team to reliably get great results is a great method. It does not matter that other teams can not make it work. But then, the Agile Manifesto was all about "stop talking about this or that method being great and just do what works on your environment!!!" That was the thing that worked everywhere, and all there is to it. Needless to say that Scrum, or any other named process does not fit it.
- desireco42 10y agoTeams can, but often they just call things Agile, but don't really implement it. Honestly it is hard for me to understand or explain that, except by lack of education and understanding. People need to understand what they are doing, how they are going to go about doing that and where they will get work, how it will be tracked etc. Once you have those basic things in place, things just flow. Majority organizations, consultancies etc, they just do hand-waving and nothing more.