3 ms·

Agile requires a bit of fudging around the edges, but it already admits that that is required (people > processes). Yeah, YAGNI and its ilk may apply, but some

Agile requires a bit of fudging around the edges, but it already admits that that is required (people > processes). Yeah, YAGNI and its ilk may apply, but sometimes you -do know you're going to need it-. That story is in the pipeline, your users are demanding it; to design and code only to the current story, dismissing the design considerations that that future story would impose upon the current one, is shortsighted and self-defeating. You shouldn't be delivering -features- from that story yet, but by all means recognize that "Oh, we'll need a hook for that, and it would make sense for me to implement this with an event manager so we can add subscribers, and keep these decoupled, rather than just make a direct method invocation", etc, so you can easily tackle that future story when it comes up. Oh, hey, the build and deploy process sucks, and that has no direct user value, and thus no story. Well, deal with it anyway; you -know- that is costing you time, and being able to rapidly iterate = faster development time = less cost = desirable to the user. Etc. Really, agile always seemed to me to be two different things. One was a series of processes. The other was a series of values (among which was people > processes). And a lot of the flack agile has taken recently has been due to people focusing on what happens when teams adhere rigidly to the processes, to the detriment of the values, when it should be the other way around. EDIT: I've also seen teams that take the values as excuses to ignore the processes, which also fails hard. "People over processes? Okay, no process then, everyone just code! Get shit done!" The point is to take on the processes, modify them in accordance with the values as experience leads you. Something doesn't work for your team? Change it. As someone mentioned elsewhere on this thread, that's what retrospectives are for.

tbrownaw 12y ago
And a lot of the flack agile has taken recently has been due to people focusing on what happens when teams adhere rigidly to the processes, to the detriment of the values, when it should be the other way around. The problem is, that's how it's being sold. The perfect Platonic "Agile" may not have strict processes, but the in-practice "Agile" that comes with consultants and certifications and marketing does.
- lostcolony 12y ago
  I'd not go so broad as that, though I tend to agree. Bringing in outside consultation can help when the team is fractured, or when there's a disconnect between the team's needs and what management is willing to allow (that is, an outsider saying to management "Look, you've already agreed to be agile; that means you have to give the team autonomy to try this" can be more effective than the team saying "We want to try this"). But yes, there's a lot of snake oil salesmen, "Agile is good for what ails ya!"
- fennecfoxen 12y ago
  Like many other products, if the person buying doesn't actually understand the difference, the bad stuff will tend to drive out the good. This is not a problem of Agile, it's a problem of the people who choose to hire consultants and adopt methodologies. It might be a problem for Agile -- it damages the brand -- but that'll be a problem for any set of principles in the same space. You're always going to need to keep your eyes open, do your research, and carefully employ both reason and lessons from experience.
- dragonwriter 12y ago
  > The perfect Platonic "Agile" may not have strict processes, but the in-practice "Agile" that comes with consultants and certifications and marketing does. If you are substituting reliance on marketers and consultants selling canned processes telling you what to do instead of your engineers developing their own knowledge of what Agile is and applying it, then, yes, you will get some canned thing sold by marketers and consultants that has an "Agile" label stuck on it but which is the exact opposite of what Agile is -- since any canned, externally-defined, process sold across the industry by marketers and consultants is not only "not Agile", but exactly the problem that Agile was defined to solve. OTOH, that's not a problem with Agile, that's a problem with outsourcing the basic function of engineering your own internal processes without developing internal understanding.
  - dllthomas 12y ago
    In an environment where employees stay with a single company long enough, consultants may be a valuable way of moving information between companies. I'm skeptical that much software development work sufficiently resembles that, though.
tootie 12y ago
Agile has no process, your complaint is with Scrum and I mostly agree. The amount of rigidity in scrum has gotten out of hand. The concept of stories on a backlog and the very iterative approach is the crux of the process and I think it's great. You will always need non-user stories to get set up. Developer stories are fine by me. I also think sprint schedules are artificial and prefer a looser more KanBan approach. My biggest challenge that no one seems to have adequately addressed is working in a multi-discipline team. My scrum team includes UX, visual design, content, and we are all interdependent. It's really, really hard to get them on to scrum because their work has no clear point of completion. You just have to keep it loose which is really the core principle of scrum. It's designed to react to change more than making long-term plans.
- kethinov 12y ago
  The guys who wrote the agile manifesto are also the same guys who created and promote Scrum though. They kinda are one in the same.

tbrownaw 12y ago

And a lot of the flack agile has taken recently has been due to people focusing on what happens when teams adhere rigidly to the processes, to the detriment of the values, when it should be the other way around. The problem is, that's how it's being sold. The perfect Platonic "Agile" may not have strict processes, but the in-practice "Agile" that comes with consultants and certifications and marketing does.

lostcolony 12y ago
I'd not go so broad as that, though I tend to agree. Bringing in outside consultation can help when the team is fractured, or when there's a disconnect between the team's needs and what management is willing to allow (that is, an outsider saying to management "Look, you've already agreed to be agile; that means you have to give the team autonomy to try this" can be more effective than the team saying "We want to try this"). But yes, there's a lot of snake oil salesmen, "Agile is good for what ails ya!"
fennecfoxen 12y ago
Like many other products, if the person buying doesn't actually understand the difference, the bad stuff will tend to drive out the good. This is not a problem of Agile, it's a problem of the people who choose to hire consultants and adopt methodologies. It might be a problem for Agile -- it damages the brand -- but that'll be a problem for any set of principles in the same space. You're always going to need to keep your eyes open, do your research, and carefully employ both reason and lessons from experience.
dragonwriter 12y ago
> The perfect Platonic "Agile" may not have strict processes, but the in-practice "Agile" that comes with consultants and certifications and marketing does. If you are substituting reliance on marketers and consultants selling canned processes telling you what to do instead of your engineers developing their own knowledge of what Agile is and applying it, then, yes, you will get some canned thing sold by marketers and consultants that has an "Agile" label stuck on it but which is the exact opposite of what Agile is -- since any canned, externally-defined, process sold across the industry by marketers and consultants is not only "not Agile", but exactly the problem that Agile was defined to solve. OTOH, that's not a problem with Agile, that's a problem with outsourcing the basic function of engineering your own internal processes without developing internal understanding.
- dllthomas 12y ago
  In an environment where employees stay with a single company long enough, consultants may be a valuable way of moving information between companies. I'm skeptical that much software development work sufficiently resembles that, though.

tootie 12y ago

Agile has no process, your complaint is with Scrum and I mostly agree. The amount of rigidity in scrum has gotten out of hand. The concept of stories on a backlog and the very iterative approach is the crux of the process and I think it's great. You will always need non-user stories to get set up. Developer stories are fine by me. I also think sprint schedules are artificial and prefer a looser more KanBan approach. My biggest challenge that no one seems to have adequately addressed is working in a multi-discipline team. My scrum team includes UX, visual design, content, and we are all interdependent. It's really, really hard to get them on to scrum because their work has no clear point of completion. You just have to keep it loose which is really the core principle of scrum. It's designed to react to change more than making long-term plans.

kethinov 12y ago
The guys who wrote the agile manifesto are also the same guys who created and promote Scrum though. They kinda are one in the same.