Slashdot Mirror
Is Project Management Killing Good Products, Teams and Software? (techbeacon.com)
New submitter mikeatTB writes: "For software development, no significant developer activity is predictable or repetitive; if it were, the developers would have automated it already," writes Steven A. Lowe, Principal Consultant Developer at ThoughtWorks, via TechBeacon. "In addition, learning is essentially a nonlinear process; it involves trying things that don't work in order to discover what does work. You might see linear progress for a while, but you don't know what you don't know, so there will be apparent setbacks. It is from these setbacks that one learns the truth about the system -- what is really needed to make it work, to make it usable, and to make a difference for the users and the business. In other words, the dirty little secret of software development is that projects don't really exist. And they're killing our products, teams, and software." Lowe continues: "Projects, with respect to software development, are imaginary boxes drawn around scope and time in an attempt to 'manage' things. This tendency is understandable, given the long fascination with so-called scientific management (a.k.a. Taylorism, a.k.a. Theory X), but these imaginary boxes do not reduce underlying complexity. On the contrary, they add unnecessary complexity and friction and invite a counterproductive temptation to focus on the box instead of the problem or product. This misplaced emphasis leads to some harmful delusions: Conformance to schedule is the same thing as success; Estimation accuracy is possible and desirable enough to measure and optimize for; The plan is perfect and guarantees success; The cost of forming and dissolving teams is zero; The cost of functional silo hand-offs is zero; The bigger and more comprehensive the plan, the better; Predictability and efficiency are paramount."
To quote Dwight D. Eisenhower, "In preparing for battle, I have always found that plans are useless but planning is indispensable."
If you go into a major project without some sort of project management, it's not going to end well. However, the management of the project needs to be flexible enough to adapt to the changing environment. Decent project management will see when things are under resourced, and help to fill in those gaps (if possible), and should keep the project going in the right direction.
...si hoc legere nimium eruditionis habes...
Some supervision is required, but I know the project I'm working on right now would be better off if we fired everyone between Sr. Director and SVP (half the Directors too!).
1. project managers that graduated from the school of flagellation. the ones that think assigning a firm date to every goal is the only way to ensure it gets completed, and are willing to waterboard you for not adhering to the holy calendar. some of what we do in systems engineering -- like deprecating old systems or rolling out your cloud provided buzzgasm solution -- is highly technical. if you're not willing to draw diagrams or at least document how and why we arrived at some of these goals, youre just another manager.
2. project managers that ignore dependencies. sometimes other teams need to get involved to accomplish a given task or objective and if youre not willing to make the call, then who is? securing time from the beleaguered network guy, the storage zombies, or the NOC is technically under your purvey. if we make it all the way to the calendars release date and you havent done the needful when it comes to taking to other teams and understanding the business structure, then we can hardly be blamed.
3. companies that insist on contract-based project managers. they arent around long enough to learn the business or the systems in place, so they have very little incentive to participate fully in the project lifecycle. these shitlords get away with floating from company to company and doing very little at all.
Good people go to bed earlier.
"The Mythical Man-Month" by Fred Brooks.
This should be required reading once a year for ALL direct and indirect management of any engineering or software development team.
Again with the "Oh, Look at what I found, managing complex tasks is hard!" How many times will we be blessed with the same insight that Mr. Brooks put on paper way back in the 1970's? My guess is "just once more!"
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
Coordination is required. Cutting the red tape is required. Supervision is not.
Management should finally find out that they're a supporting role to those that produce instead of going on a micromanaging power trip.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
The problem is that upper management doesn't understand that status reports have a non-zero, non-trivial cost. When a project gets into trouble, the number of status reports and meetings increase, which surprise surprise, slows down progress. Also, software development is non-linear for at least part of any non trivial project. Refusing to accept that fact has caused problems for decades. Sometimes as a developer, it feels like management is working against us. Does any of that sound like a useful part of running the business?
"Those that start by burning books, will end by burning men."
Indeed, while poorly done planning is useless, or worse, PROPER planning can be VERY useful.
Here's a very important fact - programmers consistently over-estimate how much they can get done in a week or a month. Consistently, that's the key word. We're wrong about how long things will take, but we're wrong in a fairly predictable way. If tasks are well defined, programmers are pretty good at estimating the RELATIVE size of job - task A will likely take about twice as long as task B. Here's what the planned productivity vs actual completed tasks might look like for a typical Agile team, with the amount done measured in "story points":
Sprint #. Plan Actual completed
Sprint 1. 124 98
Sprint 2. 105 96
Sprint 3. 131 102
Sprint 4. 116 97
The team fell short of their plan every time. And they pretty consistently get about 98 points. If management believes the 131 number, there will be problems. It works pretty well if management looks at historical fact and says "this team completes about 98 points per sprint. Let's do the project plan based on 85 points total for the team."
Let's address the "delusions" (straw men) that the author sets up:
> The plan is perfect and guarantees success;
Perfection is not required for something to be valuable. The author's proposal is even LESS perfect. While a plan can't guarantee success, it does at least define success, so you know when you're done, and what you're aiming for. Failing to plan, on the other hand, almost guarantees perpetual scope-creep, where a project can never be a success because it never ends.
> The cost of forming and dissolving teams is zero;
Very often the cost of forming a team is WORTH IT
> The cost of functional silo hand-offs is zero;
Again, not zero, but worth it
> The bigger and more comprehensive the plan, the better;
If you don't have a big-picture plan of what your company or organization is trying to do, what are the odds that you'll accidentally accomplish it?
More specifically, what often happens without a big-picture plan is that functional level teams such as programmers do cool stuff that gets abandoned shortly afterward. They may spend a month integrating the systems of a division that gets sold off two months later. They may do cool stuff for managing desktop applications, while another team is busily moving everything to the cloud.
> Predictability and efficiency are paramount.
Your idea for what you want your team to do sounds good. My different idea sounds good. So does Kevin's idea. Unless we find a way to predict how long these projects will take, WE DON'T KNOW IF WE SHOULD DO THEM AT ALL. There are many, many projects that should be done if we can do them this week, and should not be done if it'll take a year. Yes, predictability *is* important. At a much higher level, the executives at your young, growing company are borrowing millions of dollars to fund the company until it becomes profitable. Those loans start coming due in three years. Yes, for a young company, it's very survival depends on predicting how long these will take and how much they will cost. Predicting is hard (though certain methods make it much easier), but it's essential.