3 ms·

The company I work for follows an agile-ish methodology. Having attended some agile conferences I would say that there aren't really insights there for most of

• logfromblammo 12y ago
  I think it was like that originally, but now it is just another set of cargo cult rituals, with new management buzzwords. The problem remains that managers in most companies cannot reliably discern the difference between valuable work product and the physical evidence of completely wasted time. They cannot tell at a glance whether the code and/or architecture is museum-quality or DailyWTF fodder. They cannot tell when the entire development team is colluding to implement mortgage-driven development. The fundamental flaw in the system is that managers and developers do not think in compatible ways. To the manager, a developer might as well be an alien, asking him for more cows and sharper scalpels. To a developer, the manager might as well be an alien, asking him to drop his pants and hop up onto the Probulator. What is really needed is someone with both pointy hair and a neckbeard, who can translate easily between the people who need to cover their asses and justify their own existence, and the people who need both rational objectivity and aesthetic merit in their work. Both sides are needed, because honestly I have known too many co-workers that cannot seem to fathom that they don't get paid unless the work they do can somehow add value to the things the company actually sells to people outside the company. The artist usually doesn't know when to sign the thing and ship it to the gallery, and the gallery salesman often has no idea what the piece is actually worth when a customer shows up to make an offer.
  • batoure 12y ago
    I definitely agree with alot of your points. I guess what I meant to say was that for alot of organizations it seems to be useless paradigm gibberish. For our organization it doesn't seem to be, and my purely unscientific observation would be that getting devs on board is more about tools and channeling them through a process. That, you can get someone through pretty quick because its primarily logistics based. We have tickets that are tied to pull requests you have to submit your PRs for test tickets before you can submit your PRs for feature tickets we have a CI server that will run those PR's against the tests at which point we merge everything. This makes it pretty straight forward how development has to get done. Where as, getting people who aren't code driven on-board requires complex paradigm adoption about how we design projects and road-map the business. Some of these people end up at these types of trainings because they are the people who need the indoctrination the most. Developers we have faced have a tendency to either just sort of shrug and go "ok" or to want to totally fight the system and tear it down and replace it with X. We do our best to weed the violent opposition types by using test writing as examples during interviews the violent opposition types usually get visibly frustrated by the "test then code" approach of TDD so we haven't had to much trouble identifying people like this. The long and short would be: I think that the thesis of the OP that lack of dev's is a problem can be rejected because engineering unit employees don't face the same hill climb to adoption that business unit employees do and that this has been enabled by the fact that: developers have at this point written them selves tools to automate their own side of the paradigm... i.e Jira Github and so on