5 ms·

Maybe it's because we've received the secret developers-eyes-only memo: True Agile: Individuals and interactions over processes and tools Working software

by avz 12y ago

Maybe it's because we've received the secret developers-eyes-only memo: True Agile: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Getting shit done over attending meetings and conferences

lhnz 12y ago
This needs to be at the top. 90% of what is sold to me as "Agile" is not at all agile. It is unproductive snake-oil sold by people that benefit by playing with numbers, taking credit and acting as whip. Nowadays the existence of the word in job descriptions is actually a filter for poorly-run companies. Either they unconsciously swallowed the Kool-Aid or there is a lack of managerial trust in the builders and they have chosen to sacrifice work output for an emotionally comforting feeling of control. The insinuation from many companies that anybody would want Agile processes to work efficiently is ridiculous. Those that work well are agile because they intuitively or consciously follow the original principles and are part of a cohesive team that doesn't do unnecessary work.
- avz 12y ago
  I think more and more people realize this. The four original value statements from the Agile Manifesto are mentioned far too infrequently compared to all the processes and tools peddled by various agile salespeople. A friend of mine recently asked me to give a short presentation to a few developers working at his small software company. He suggested that Agile may be a good subject and we spent an hour discussing how his developers analyse, design, code and test their projects so that I could give a relevant talk. It turned out that what they were doing was naturally very close to agile development and the whole talk would have been a waste of everyone's time. I just gave him the link http://agilemanifesto.org http://agilemanifesto.org and ended up talking about XSS.
- redthrowaway 12y ago
  >Nowadays the existence of the word in job descriptions is actually a filter for poorly-run companies I've noticed this, as well. In those friendly little emails LinkedIn keeps sending me, the companies who claim to be big-A Agile are the ones that seem like the least enjoyable to work for. The ones that actually are agile and would be fun to work for find other ways to signal that fact - mostly by using descriptions that show them to be developer-centric and focussed on software.
twistedpair 12y ago
I'd add that the concept of the "story" and the fact that it needs a title of the format "As a <party> I need <functionality> because it add <some business value>." That practice is quite powerful. It continues to amaze me how many project managers are content starting and promising delivery of a project without a clear Definition of Done or any understanding how all this effort will add value to the company/product.
eldelshell 12y ago
"Getting shit done over attending meetings" And yet I've seen "agile" teams waste more time in "agile" meetings than in anything else... except for PingPong.
- LandoCalrissian 12y ago
  Sprint demos, sprint commits, backlog grooming, daily scrums... It goes on and on. So much of it is not actually getting anything done. Make sure your burndown is good guys!
angersock 12y ago
"Working software over comprehensive documentation" And this is why nobody who is a real engineer should ever take most software engineers seriously.
- scrabble 12y ago
  Well written software should generally be able to double as documentation.
  - angersock 12y ago
    Even the cleanest code will only ever tell you how something is done, and not why. The best-factored simply-named controller source or whatever else will not, in isolation and without documentation, ever tell you why we are asking the computer to do the things it does. The problem with this is that somebody (rightly or wrongly) will see the code one day, and infer what they think it is doing, and change it, and break things elsewhere in the world. If you don't want that to happen, you are forced to only ever write code that matches the exact logic of what already exists--and because you, rockstar ninja cowboy that you are, don't have any documentation including business use cases or logic for a particular hack or inelegance, you must then look on and only make the mildest of changes to the sacred monolith. Or, you know, you could document your projects and software like a real engineer, and others can later check that they can make changes with impunity--or even better, throw away chunks of unneeded code wholesale because their time is (according to the docs!) past. EDIT: This whole "The code is the documentation hurrrr" meme is really annoying--it can only express the hows and not the whys. There is more to software than simply the steps the computer takes to transform data. If there wasn't, we'd still be using assembly and Perl every day.
  - figglesonrails 12y ago
    Just no. Well-written software (i.e. clean code, clear functions) is great and a joy to work with, but is absolutely not a substitute for documentation. Public APIs are double-triple-extra not exempt by merely being well-written, especially not C/C++ APIs, which have complex meta-details like "is this thread-safe?", "does this allocate memory?", "can I call this twice using the same object?", etc. I get that if code is clear enough, it should be self-documenting. That alleviates the need to write as many comments. //Comments//. It's not a user manual. It's not an explanation of architecture. It's not a help guide. It's not an example of how to use it. It's not best practices. It's not how to write a plugin for your system. It's not an explanation of why the software is needed or where it fits into the business's plan. It's. Just. Code. I've inherited enough undocumented code to take new stance: if I quit tomorrow and people are unable to train a new person to fully understand my code without me to train them, then I'm doing it wrong. "Wizards" are also liabilities.

by avz 12y ago

lhnz 12y ago

This needs to be at the top. 90% of what is sold to me as "Agile" is not at all agile. It is unproductive snake-oil sold by people that benefit by playing with numbers, taking credit and acting as whip. Nowadays the existence of the word in job descriptions is actually a filter for poorly-run companies. Either they unconsciously swallowed the Kool-Aid or there is a lack of managerial trust in the builders and they have chosen to sacrifice work output for an emotionally comforting feeling of control. The insinuation from many companies that anybody would want Agile processes to work efficiently is ridiculous. Those that work well are agile because they intuitively or consciously follow the original principles and are part of a cohesive team that doesn't do unnecessary work.

avz 12y ago
I think more and more people realize this. The four original value statements from the Agile Manifesto are mentioned far too infrequently compared to all the processes and tools peddled by various agile salespeople. A friend of mine recently asked me to give a short presentation to a few developers working at his small software company. He suggested that Agile may be a good subject and we spent an hour discussing how his developers analyse, design, code and test their projects so that I could give a relevant talk. It turned out that what they were doing was naturally very close to agile development and the whole talk would have been a waste of everyone's time. I just gave him the link http://agilemanifesto.org http://agilemanifesto.org and ended up talking about XSS.
redthrowaway 12y ago
>Nowadays the existence of the word in job descriptions is actually a filter for poorly-run companies I've noticed this, as well. In those friendly little emails LinkedIn keeps sending me, the companies who claim to be big-A Agile are the ones that seem like the least enjoyable to work for. The ones that actually are agile and would be fun to work for find other ways to signal that fact - mostly by using descriptions that show them to be developer-centric and focussed on software.

twistedpair 12y ago

I'd add that the concept of the "story" and the fact that it needs a title of the format "As a <party> I need <functionality> because it add <some business value>." That practice is quite powerful. It continues to amaze me how many project managers are content starting and promising delivery of a project without a clear Definition of Done or any understanding how all this effort will add value to the company/product.

eldelshell 12y ago

"Getting shit done over attending meetings" And yet I've seen "agile" teams waste more time in "agile" meetings than in anything else... except for PingPong.

LandoCalrissian 12y ago
Sprint demos, sprint commits, backlog grooming, daily scrums... It goes on and on. So much of it is not actually getting anything done. Make sure your burndown is good guys!

angersock 12y ago

"Working software over comprehensive documentation" And this is why nobody who is a real engineer should ever take most software engineers seriously.

scrabble 12y ago
Well written software should generally be able to double as documentation.
- angersock 12y ago
  Even the cleanest code will only ever tell you how something is done, and not why. The best-factored simply-named controller source or whatever else will not, in isolation and without documentation, ever tell you why we are asking the computer to do the things it does. The problem with this is that somebody (rightly or wrongly) will see the code one day, and infer what they think it is doing, and change it, and break things elsewhere in the world. If you don't want that to happen, you are forced to only ever write code that matches the exact logic of what already exists--and because you, rockstar ninja cowboy that you are, don't have any documentation including business use cases or logic for a particular hack or inelegance, you must then look on and only make the mildest of changes to the sacred monolith. Or, you know, you could document your projects and software like a real engineer, and others can later check that they can make changes with impunity--or even better, throw away chunks of unneeded code wholesale because their time is (according to the docs!) past. EDIT: This whole "The code is the documentation hurrrr" meme is really annoying--it can only express the hows and not the whys. There is more to software than simply the steps the computer takes to transform data. If there wasn't, we'd still be using assembly and Perl every day.
- figglesonrails 12y ago
  Just no. Well-written software (i.e. clean code, clear functions) is great and a joy to work with, but is absolutely not a substitute for documentation. Public APIs are double-triple-extra not exempt by merely being well-written, especially not C/C++ APIs, which have complex meta-details like "is this thread-safe?", "does this allocate memory?", "can I call this twice using the same object?", etc. I get that if code is clear enough, it should be self-documenting. That alleviates the need to write as many comments. //Comments//. It's not a user manual. It's not an explanation of architecture. It's not a help guide. It's not an example of how to use it. It's not best practices. It's not how to write a plugin for your system. It's not an explanation of why the software is needed or where it fits into the business's plan. It's. Just. Code. I've inherited enough undocumented code to take new stance: if I quit tomorrow and people are unable to train a new person to fully understand my code without me to train them, then I'm doing it wrong. "Wizards" are also liabilities.