32
kraator
14d

I just lost faith in the entire management team of the company I'm working for.

Context: A mid sized company with
- a software engineering departmant consisting of several teams working on a variety of products and projects.
- a project management department with a bunch of project managers that mostly don't know shit about software development or technical details of the products created by engineering.

Project management is unhappy about the fact that software engineering practically never sticks to the plan regarding cost, time and function that was made at the very beginning of the project. Oh really? Since when does waterfall project management work well? As such they worked out a great idea how to improve the situation: They're going to implement *Shopfloor Management*!

Ever heared about Shopfloor Management? Probably not, because it is meant for improving repetitive workflows like assembly line work. In a nutshell it works by collecting key figures, detecting deviation in these numbers and performing targeted optimization of identified problem areas. Of course, there is more to Shopfloor Management, but that refers largely to the way the process just described is to be carried out (using visualisation boards, treating the employee well, let them solve the actual problem instead of management, and so on...). In any case, this process is not useful for highly complex and hard-to-predict workflows like software development.

That's like trying to improve a book author's output by measuring lines of text per day and fixing deviations in observed numbers with a wrench.

Why the hell don't they simply implement something proven like Scrum? Probably because they're affraid of losing control, affraid of self managed employees, affraid of the day everybody realizes that certain management layers are useless overhead that don't help in generating value but only bloat.

Fun times ahead!

Comments
  • 3
    Context not required to support your feelings
  • 2
    That sucks. But as they say "It's always a people problem".

    Is management open for help from outside? Maybe an agile-coach or something like that? (Someone who actually knows stuff, not the mr-buzzword-buy-my-book-type).

    As for control, software development is one of the most transparent jobs there is in my option: git, IDE time-tracking + ticket-system and colorful reports with funny diagrams. It does not get any more detailed than that...

    Hope it works out for you! :)
  • 1
    Buy a dozen copies of the mythical man month and give them all some cobra kai education.
  • 2
    @SuspiciousBug I highly doubt it. Upper management won't let themselves being taught anymore. I think they're preparing that shit for weeks if not months. Simply convincing them would imply that they would have to admit a mistake, which won't happen.

    Instead they need to realize themselves that software development is not assembly line work, in which case they'll simply silence the issue and promote something else. Something new. Something even better. But it is to early for that.

    I'm not sure if I want to be the one who told them upfront, because otherwise I'll later be the one who remembers the truth. Like the one who knows the murderer.

    I think that managers starting at a certain level are generally good at "not making mistakes" by either successfully blaming others or by distracting from the error made. Otherwise they would never have reached that position in the first place.
  • 2
    @SuspiciousBug Regarding the measurability of a software developers' work I have to disagree. Any job where you have to process a certain number of tasks of nearly unique size is more measurable than software development. The more complex a task the more risk is attached to it, which generally makes any two such tasks incomparable. Sure you can generate a whole bunch of funny numbers, but how meaningful are they? Risk causes imprecision of any measurements done, even afterwards.

    That's the whole point of why so many project managers fail at managing software development related projects if they originally come from other companies where they had to manage other types of projects. Most fail to realize that managing software development is mostly risk management. That's why scrum or agile in general focuses on what has been learned and constantly updating the plan rather than on planning ahead too far based on wrong assumptions.
  • 0
    @SortOfTested Haha that would be funny, but only if I did it anonymously.
  • 1
    @kraator shit, demand from management that you get paid by lines of code written and not the out come 😆

    But for real tho, what are the other devs thinking about that? Time for a collective dev strike! Unionize!
  • 0
    I know this feeling pretending to work agile because they can add what they want but project still should deliver all functionality on the deadline..
Add Comment