By the book managers (aka Buy a Book managers) have a nasty tendency to believe that there is "One True Method" that will accomplish the goal. They often labor under the misapprehension that if they do x y and z as a manager then they will get P outcome.
In reality, management is more about personalities and conflict resolution then anything else IMO. What I would consider a good manager generally has a lot of different techniques for keeping abreast of a project and making sure things get done on as close to the timetable as is practical, but they choose what technique they use carefully, and they adapt to the dynamics of the specific team they are working with. Good 1st tier management is more of a bespoke process, and a lot less of a one-size-fits-all. It's can also be terribly hard to FIND really good 1st tier managers.
Upper management should really be more focused on long range and strategic planning, but mostly they need to be choosing the front line managers with extreme care and monitoring without micromanaging and getting in the way.
Eh... Sorry for the digression, I've just seen both sides of the coin and as Kier seems to, I believe that management practices buzzwords du-jour are just that. No doubt they are based in a team environment that worked really well, but when you take them out of that particular environment they can do more harm then good unless the manager employing them is deft enough to adapt the processes to his team, and help smooth over the incompatibilities. There are certainly tons of best practices general principles, but viewing any method as a "magic bullet" is almost certainly doomed to failure.
To put it into venue appropriate jargon: Managing human beings on a project is an analog process, not a digital one .
Something I read recently, which certainly rings true in my experience:
Non-programmers in software companies are there to make money not software. If they get control of software projects, those same projects mysteriously slow down to a snails pace and programmers head for the exits. They use over-management, micro-management, methodology fads, impose ****ty tools and practices, meeting madness,... anything to inject chaos, cause strife, and make their jobs necessary. What's important is that they do this on purpose, and they know exactly what they're doing.
On top of that they blame any failure or schedule slip on the programmers using stupidly flawed logic like (good project => good developers) implies (bad project => bad developers). The project went badly? Must be the bad developers.
No amount of '10x' programmers (lol) can overcome management opportunity creation.
Well, I tend not to ascribe to malice what can be chalked up to narrow mindedness/stupidity .
But that's a great quote and certainly fits too (management creation opportunity, blech!)... And it fits with the common problem we see in the states all the time where a company goes public, and shortly the "Leadership" is interested more in getting as much as possible when they leave the company, and couldn't care less about the long term future (or even viability) of the company itself.
I'm a BIG believer in the idea of the company owners valuing the company itself, rather than viewing it as a stepping stone.
I would see that as certainly being true when you introduce management contractors / consultant companies. Their aim seems to be to extend the project to make more money.
However, I have found it isn't true of in house managers, who are reviewed on performance and delivery. I also believe that if you have a good process in place it helps to reduce errors (and thereby reduce risk) and reduce scope creep (or at least allow you rationalise slippage)
I agree with whoever wrote that. When I was Information System Manager, at a firm, coding the intranet and front-end website. I was pushed daily by their demands. It definately wasn't healthy for the development and caused more issues than worth. After I resigned, the position was not filled, and the management was direct with the development team. I believe that it got worse from there.
I ended up coding a custom task manager and bug system just so that management could know what was being done, and how fast.
I'm glad I wasn't a general manager. Dealing with loss and profits would have been hell.
An orderly process of some kind is a must... but it has to be picked to match the people working the project. Super devs may seem like they are getting by just "winging it"... Nope - they are just following their own basic processes learned from experience. AKA - I'm doing what I know works, even if I don't want to explain it to you during anything that even remotely resembles a meeting. =)
Weaker/newbie devs would crumble without any sort of plan in mind - unless you're ok with waiting 5 years for project completion and/or living with more bugs than options. Obviously, chaos doesn't beget order!
Remember, some of the ideas in Agile are about getting rid of those "pain in the butt" meetings. And there's certainly nothing wrong with a good sprint. But you don't want to end up merging two groups with diametrically opposed philosophies on the matter... something that might explain the implosion after the IB acquisition of vB. I can imagine the personality clashing to be symbolized a bit like this (with less suits and more British accents):