3 ms·

I am seeing more and more people involved in making organizations and teams more efficient come back to how the canned / certifications methods are not sufficie

by dkarl 8y ago

I am seeing more and more people involved in making organizations and teams more efficient come back to how the canned / certifications methods are not sufficient by themselves. I am on the same page, noticing how on the project level the actual project management method (like Scrum, Kanban etc) are no the main predictor of success. The pendulum has swung a long way. It used to be that scaling a successful organization up was supposed to mean forgetting what was successful at a small scale and trusting the experience of people who succeeded at a larger scale. In other words, read a book, ignore your instincts and experience that were formed in a small-scale environment, and do what the experts prescribed based on their own experience in larger organizations. Those were dark days. People who followed what seemed like the foolish path, trusting their instincts and limited experience, making things up as they went along, not trusting the software engineering "knowledge" that had been supposedly accumulated and passed down, seemed to be much more successful than people who followed the apparently modest and prudent path of trying to stand on the shoulders of giants. The utter worthlessness in practice of what we read in those big, heavy (and expensive) books, and the leadership failures of the people who relied on those books and touted their own mastery of them, suggests the "experts" were publishing ideation and speculation, not reality. Also their elaborate models of "maturity" were quite similar to the model of maturity we had as college freshman when we measured maturity by "purity tests." For non-Americans, these were ludicrously extensive checklists of sexual and drug-related acts that you would fill out with your friends to see who had the highest total. In retrospect, I don't see any difference between this and measuring software development maturity by the sheer number of possibly helpful practices your organization has adopted, without asking whether they're worth bothering with in the first place.

FooHentai 8y ago
An alternative explanation for the failures of 'big methodology' is the shift in workplace, professional and career trends. Monoculture isn't possible with a diverse, agile workforce and unless everyone's on the same page those big, prescriptive methodologies just don't work. "this is how we do things around here" doesn't work if the newcomer you're preaching to is likely to up sticks in a year or two, and you yourself have only been 'here' a year or two. But that's the makeup of most organisations today. I'm not saying diversity and mobility is a bad thing, but it does explain why those approaches perhaps worked fine for the authors in the time period they experienced it, but don't work today.
- gregdoesit 8y ago
  > Monoculture isn't possible with a diverse, agile workforce and unless everyone's on the same page those big, prescriptive methodologies just don't work This is a really interesting insight. I don't have much personal reference to compare to the software dev cultures in e.g. the 80s or 90s, but there is definitely a shift towards software engineers having more autonomy, more connected with the customers, often being customers of the software themselves.
  - dkarl 8y ago
    I don't know — I came into the software dev world in 2000, and we worked in cubicles and planned in slow waterfall cycles. Integration happened very late in the development process. The managers often wore suits. Programmers didn't talk to clients. In that environment, the old-fashioned processes were still not better than people just making it up as they went along, which is a pretty damning assessment of "decades of progress." I mean, this should be tempered by Keynes' observation that "Practical men who believe themselves to be quite exempt from any intellectual influence, are usually the slaves of some defunct [he said economist, fill in whatever field applies]." The ideas came from somewhere. The people who were "just making it up" distinguished between different forms of testing, used some form of project planning, and followed some kind of waterfall process that was internally iterative. These ideas were found in the experts' books. The difference was that the seat-of-their-parts people left out 80-90% of what the experts said was required for a successful software process, and they produced the same quality software faster and cheaper than people who studied the books and followed the recommendations faithfully. So maybe there was an incremental improvement as more and more ideas were crystallized and propagated through the development community, and the experts erred only in their maximalism.

by dkarl 8y ago

FooHentai 8y ago

An alternative explanation for the failures of 'big methodology' is the shift in workplace, professional and career trends. Monoculture isn't possible with a diverse, agile workforce and unless everyone's on the same page those big, prescriptive methodologies just don't work. "this is how we do things around here" doesn't work if the newcomer you're preaching to is likely to up sticks in a year or two, and you yourself have only been 'here' a year or two. But that's the makeup of most organisations today. I'm not saying diversity and mobility is a bad thing, but it does explain why those approaches perhaps worked fine for the authors in the time period they experienced it, but don't work today.

gregdoesit 8y ago
> Monoculture isn't possible with a diverse, agile workforce and unless everyone's on the same page those big, prescriptive methodologies just don't work This is a really interesting insight. I don't have much personal reference to compare to the software dev cultures in e.g. the 80s or 90s, but there is definitely a shift towards software engineers having more autonomy, more connected with the customers, often being customers of the software themselves.
- dkarl 8y ago
  I don't know — I came into the software dev world in 2000, and we worked in cubicles and planned in slow waterfall cycles. Integration happened very late in the development process. The managers often wore suits. Programmers didn't talk to clients. In that environment, the old-fashioned processes were still not better than people just making it up as they went along, which is a pretty damning assessment of "decades of progress." I mean, this should be tempered by Keynes' observation that "Practical men who believe themselves to be quite exempt from any intellectual influence, are usually the slaves of some defunct [he said economist, fill in whatever field applies]." The ideas came from somewhere. The people who were "just making it up" distinguished between different forms of testing, used some form of project planning, and followed some kind of waterfall process that was internally iterative. These ideas were found in the experts' books. The difference was that the seat-of-their-parts people left out 80-90% of what the experts said was required for a successful software process, and they produced the same quality software faster and cheaper than people who studied the books and followed the recommendations faithfully. So maybe there was an incremental improvement as more and more ideas were crystallized and propagated through the development community, and the experts erred only in their maximalism.