3 ms·

Agile = Strict process. Agile = Lots of meetings. Agile = Releases done on fixed schedule. Agile = User stories defined by product owner. Productive Develop

Agile = Strict process. Agile = Lots of meetings. Agile = Releases done on fixed schedule. Agile = User stories defined by product owner. Productive Developer = Litte/No process Productive Developer = Little/No (formal) meetings Productive Developer = Releases as soon as ripe to release Productive Developer = Doesn't need product owner. Actual usage and metrics tell productive developer what to do next. Agile <> Productive Developer

pflenker 7y ago
That sounds a bit like a complaint about a specific methodology. None of the items at the top can be found in the agile manifesto, IIRC.
jfim 7y ago
If you go back to the actual agile manifesto [0] and the principles [1], you'll see that it's actually closer to the latter, not the former. People over processes, deliver often, with frequent communication between the business people and developers. [0] https://agilemanifesto.org/ https://agilemanifesto.org/ [1] https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html
spookthesunset 7y ago
Yeah not having meetings and process is great for a solo developer working in isolation, but it doesn’t scale to even a single team, let alone a much larger organization. Once you go past a single person working on a product, you need some kind of process to facilitate communication. Once you move beyond yourself you are gonna have a process, either implicitly or explicitly. I vote that it is best acknowledge there is going to be a process regardless of you liking it or not and be explicit and intentional about its formation. Once you acknowledge that there is gonna be a process you can either start from a known set of processes (scrum, kanban, waterfall, XP, whatever) and then iterate on it until it suits your environment. The alternative is to somehow reinvent the process wheel from the ground up and probably not be as effective as if you had started with proven processes. It’s like people who start a project and say “all these frameworks suck!!! I refuse use them! Bloat!!!”. Six months later you look at their codebase and surprise, they’ve created their own implicitly defined framework. They won’t call it a framework, but lo and behold they have a framework. Probably worse on every measurable dimension than what they would have had if they started with what’s out there too. Had they been honest with themselves, they could have saved a ton of trouble being explicit that there will be a framework no matter what and had been intentional about its creation/adoption.
ratww 7y ago
Reminds me of Zed Shaw's methodology: http://programming-motherfucker.com http://programming-motherfucker.com
jiofih 7y ago
None of what you mention is agile, where did you get that? It’s motto is “people over processes”.

pflenker 7y ago

That sounds a bit like a complaint about a specific methodology. None of the items at the top can be found in the agile manifesto, IIRC.

jfim 7y ago

If you go back to the actual agile manifesto [0] and the principles [1], you'll see that it's actually closer to the latter, not the former. People over processes, deliver often, with frequent communication between the business people and developers. [0] https://agilemanifesto.org/ https://agilemanifesto.org/ [1] https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html

spookthesunset 7y ago

Yeah not having meetings and process is great for a solo developer working in isolation, but it doesn’t scale to even a single team, let alone a much larger organization. Once you go past a single person working on a product, you need some kind of process to facilitate communication. Once you move beyond yourself you are gonna have a process, either implicitly or explicitly. I vote that it is best acknowledge there is going to be a process regardless of you liking it or not and be explicit and intentional about its formation. Once you acknowledge that there is gonna be a process you can either start from a known set of processes (scrum, kanban, waterfall, XP, whatever) and then iterate on it until it suits your environment. The alternative is to somehow reinvent the process wheel from the ground up and probably not be as effective as if you had started with proven processes. It’s like people who start a project and say “all these frameworks suck!!! I refuse use them! Bloat!!!”. Six months later you look at their codebase and surprise, they’ve created their own implicitly defined framework. They won’t call it a framework, but lo and behold they have a framework. Probably worse on every measurable dimension than what they would have had if they started with what’s out there too. Had they been honest with themselves, they could have saved a ton of trouble being explicit that there will be a framework no matter what and had been intentional about its creation/adoption.

ratww 7y ago

Reminds me of Zed Shaw's methodology: http://programming-motherfucker.com http://programming-motherfucker.com

jiofih 7y ago

None of what you mention is agile, where did you get that? It’s motto is “people over processes”.