4 ms·

Show me where in the agile manifesto ANY process is recommended: http://agilemanifesto.org/ http://agilemanifesto.org/ This is the entirety of the issue. Once

Show me where in the agile manifesto ANY process is recommended: http://agilemanifesto.org/ http://agilemanifesto.org/ This is the entirety of the issue. Once one refers to it as a process their entire argument is flawed.

fennecfoxen 12y ago
You click the 'twelve principles' link and go to http://agilemanifesto.org/principles.html http://agilemanifesto.org/principles.html For instance: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." Oh hey! It's a process! Heck, it's like a meta-process, even. THE meta-process.
- walterbell 12y ago
  Heinz von Foerster has spoken about the interaction between properties of the observer and the observed. In the quote below, one could replace "obscene" with "agile" -- each is impervious to objective measurement. http://faculty.stevenson.edu/jlombardi/pdf's/cybernetics/cybernetics_cybernetics_hvf.pdf http://faculty.stevenson.edu/jlombardi/pdf's/cybernetics/cyb... "There is at aperiodic intervals a ritual performed by the supreme judges of this land in which they attempt to establish once and for all a list of all the properties that define an obscene object or act. Since obscenity is not a property residing within things (for if we show Mr. X a painting and he calls it obscene, we know a lot about Mr. X but very little about the painting), when our lawmakers will finally come up with their imaginary list we shall know a lot about them but their laws will be dangerous nonsense."
- darkxanthos 12y ago
  That appears to be the only point in that page that resembles a process. And really it's self-reflection as a principle. But really a process is more mechanical. The manifesto says "Hey! Reflect regularly." That is not the same thing as saying "We must have a retrospective every 2 weeks using the force direction exercise..." Your calling it a "meta-process" implies to me that you also get that distinction.
  - dllthomas 12y ago
    'Your calling it a "meta-process" implies to me that you also get that distinction.' I interpreted "meta-process" as simply a remark that the process (presuming it is one, but that seemed to be the orientation of the author) addressed processes.
- julian_t 12y ago
  So? I really don’t see the problem with this. Sounds like you’re trying to make common sense into a bad thing ;-) “Process” seems to be used as a stick for both sides to beat their opponent with… you are either doing too much or too little. To me, a process is just an agreed way of doing things between a group of people. When it becomes a problem is when circumstances and experience tell you that this now isn’t the best way to proceed any more, but you still have to do it that way (and anyone who has worked for a large organisation will know what I mean) Processes ought to change with time, and a lot of problems arise when they don’t… and so regularly checking whether your way of doing things is working is just sensible.
ssmoot 12y ago
I may be misinterpreting where you're coming from, but I'll give it a shot: "Individuals and interactions over processes and tools" ... "...there is value in the items on the right..." I think that's a recommendation of process. IMO the decade of Agile has been a cluster, mostly because individuals pushing for it (IME, as a generalization) ignore the all important "there is value". Because it's not as fun/convenient/appealing/whatever (early on I was definitely one of those people). I prioritize time with my kids over doing the dishes. That doesn't mean I shouldn't do the dishes. Agile recommends you value people and try not to put barriers in front of communication, but that doesn't mean you shouldn't have a plan, scope of work, estimate, etc. Nothing in the manifesto at least says that. If you're doing fixed scope (yes, everything changes, but within reason it's generally easy to differentiate), fixed bid projects, then not having a plan is a guaranteed way to generate re-work, burnout and budget overruns for any project beyond the trivial. Planning happens, wether it happens ahead of time or just-in-time, it happens. Trying to do the inevitable rework while it's still just paper is better for developers, your company, your clients, anyone. I dunno, it seems like common sense to me. I get a contractor to bid a job in my house. The worst possible thing to happen is it takes longer than he thought and costs more. He can tell me all he wants about YAGNI and evolving understanding. My question to him is why he didn't anticipate this wall might have studs every 16" when I asked him to bid on the installation of in-wall speakers. If he'd planned it, thought through the process of performing the task each step of the way during the bid, then stupid stuff like this wouldn't happen. IMO the Software Development world is a lot like Contracting. Mostly capable people (and some brilliant), but more often than not it's hard to find a contractor who can plan their way out of a wet paper bag. Sometimes there are good reasons for needing to change a plan. But not having one in the first place is not such a reason. You want to thrill clients? Do what you say you will, for the price you say you will, when you say you will. /end-rambling-rant
vannevar 12y ago
Sounds like the premise for a good article. Not, however, this article unfortunately. This article instead throws out a handful of straw-men and chiefly complains that agile doesn't help you with software design, something it's never claimed to do.

fennecfoxen 12y ago

You click the 'twelve principles' link and go to http://agilemanifesto.org/principles.html http://agilemanifesto.org/principles.html For instance: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." Oh hey! It's a process! Heck, it's like a meta-process, even. THE meta-process.

walterbell 12y ago
Heinz von Foerster has spoken about the interaction between properties of the observer and the observed. In the quote below, one could replace "obscene" with "agile" -- each is impervious to objective measurement. http://faculty.stevenson.edu/jlombardi/pdf's/cybernetics/cybernetics_cybernetics_hvf.pdf http://faculty.stevenson.edu/jlombardi/pdf's/cybernetics/cyb... "There is at aperiodic intervals a ritual performed by the supreme judges of this land in which they attempt to establish once and for all a list of all the properties that define an obscene object or act. Since obscenity is not a property residing within things (for if we show Mr. X a painting and he calls it obscene, we know a lot about Mr. X but very little about the painting), when our lawmakers will finally come up with their imaginary list we shall know a lot about them but their laws will be dangerous nonsense."
darkxanthos 12y ago
That appears to be the only point in that page that resembles a process. And really it's self-reflection as a principle. But really a process is more mechanical. The manifesto says "Hey! Reflect regularly." That is not the same thing as saying "We must have a retrospective every 2 weeks using the force direction exercise..." Your calling it a "meta-process" implies to me that you also get that distinction.
- dllthomas 12y ago
  'Your calling it a "meta-process" implies to me that you also get that distinction.' I interpreted "meta-process" as simply a remark that the process (presuming it is one, but that seemed to be the orientation of the author) addressed processes.
julian_t 12y ago
So? I really don’t see the problem with this. Sounds like you’re trying to make common sense into a bad thing ;-) “Process” seems to be used as a stick for both sides to beat their opponent with… you are either doing too much or too little. To me, a process is just an agreed way of doing things between a group of people. When it becomes a problem is when circumstances and experience tell you that this now isn’t the best way to proceed any more, but you still have to do it that way (and anyone who has worked for a large organisation will know what I mean) Processes ought to change with time, and a lot of problems arise when they don’t… and so regularly checking whether your way of doing things is working is just sensible.

ssmoot 12y ago

I may be misinterpreting where you're coming from, but I'll give it a shot: "Individuals and interactions over processes and tools" ... "...there is value in the items on the right..." I think that's a recommendation of process. IMO the decade of Agile has been a cluster, mostly because individuals pushing for it (IME, as a generalization) ignore the all important "there is value". Because it's not as fun/convenient/appealing/whatever (early on I was definitely one of those people). I prioritize time with my kids over doing the dishes. That doesn't mean I shouldn't do the dishes. Agile recommends you value people and try not to put barriers in front of communication, but that doesn't mean you shouldn't have a plan, scope of work, estimate, etc. Nothing in the manifesto at least says that. If you're doing fixed scope (yes, everything changes, but within reason it's generally easy to differentiate), fixed bid projects, then not having a plan is a guaranteed way to generate re-work, burnout and budget overruns for any project beyond the trivial. Planning happens, wether it happens ahead of time or just-in-time, it happens. Trying to do the inevitable rework while it's still just paper is better for developers, your company, your clients, anyone. I dunno, it seems like common sense to me. I get a contractor to bid a job in my house. The worst possible thing to happen is it takes longer than he thought and costs more. He can tell me all he wants about YAGNI and evolving understanding. My question to him is why he didn't anticipate this wall might have studs every 16" when I asked him to bid on the installation of in-wall speakers. If he'd planned it, thought through the process of performing the task each step of the way during the bid, then stupid stuff like this wouldn't happen. IMO the Software Development world is a lot like Contracting. Mostly capable people (and some brilliant), but more often than not it's hard to find a contractor who can plan their way out of a wet paper bag. Sometimes there are good reasons for needing to change a plan. But not having one in the first place is not such a reason. You want to thrill clients? Do what you say you will, for the price you say you will, when you say you will. /end-rambling-rant

vannevar 12y ago

Sounds like the premise for a good article. Not, however, this article unfortunately. This article instead throws out a handful of straw-men and chiefly complains that agile doesn't help you with software design, something it's never claimed to do.