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."
Project Management isn't suited for Product development.
Most project management methods are based on some fallacies.
1. The users of the product knows what they want: The truth is they don't know what they want until they can get their hands on it, and know if what they see if they like it, hate it, or have a some tweaks that are needed. No matter how many meetings you have with static pictures and blueprints. The user just doesn't know what they want until they can get their hands on it.
2. Development of modules have a start time and a complete time: Function X may take 2 days to develop. Because it is prerequisite for function Y. However after function Y is completed and used function Z, You need to go back to function X, to get the data prepped for function Z, but you couldn't put that code in for function Z support until you have completed function Y which needed X. Coding isn't linear, they are parts that needs to be addressed and fixed, causing other parts to be reworked or adjusted.
3. People are interchangeable: A coder is a coder right. Well no. Some of them are really good at doing Database calls, while others are most comfortable with the HTML and JavaScript. While there is an other one who is most comfortable with the Middle tier code. Sure all of them may be able to code all the parts if needed, but for the most part each ones is going to be a specialist in particular parts. This means not all people are used qually or performing each task as efficiently as someone else.
4. People have lives outside the project: While working most people may get called to take a look at a different project (bug fix a previous completed application) they may need to sit in a meeting for a future project. Also they can get sick, have family emergencies...
5. Coders just code uniformly: There is a degree of artistic pride every coder uses. Everyone will approach problems a bit differently, they may be arguing with the Architect for them to be doing something a particular way or they will just ignore, misinterpret, the internal parts of the spec, and just make sure the output meets the specs. So this often creates some conflict because the internal changes may affect something else (timing, system resource, readability...) So we may need to redo the function, or just adapt the rest of the stuff around these changes.
Most PM policies are based on manufacturing processes. Where the goal matches the outcome. Product Development the outcome is usually different then the initial goal.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Take each task estimate... add 50% and turn the date into management.
Track time estimates, and the 50% slop on top of it. If 1/2 way through the project you have gone through 3/4 of your slop time, you already know you aren't going to make it. If you have only gone through 1/3 of your slop there is a good chance you might actually make it by the 150% time.
I have mod points and I am not afraid to use them
My best (former) manager (I was developing Oracle software for a State agency) said that his number one job was to be an umbrella to keep the shit from falling on us and distracting us
When I became a software development manager, I saw my number one job as keeping the developers from being drug off into endless project meetings and being kept away from doing their work.
SCRUM was my favorite tool, with the daily standup and pre/post sprints meetings were my source for all information to deliver back to the project manager(s).
Project management can be applied to software development, BUT clueless fucking PM's who think that their #1 job is keeping everybody scheduled for project status meetings are going to blow the whole deal.
I'm continually surprised at all the things we learned about engineering software systems that don't get applied back into management.
We know throwing threads at a problem doesn't work if all you do is end up locking everything. We know that high coupling and low cohesion leads to irreducible complexity. Sharing mutable state instead of doing a little bit of analysis to see what the dependencies are and break down tasks to minimize the reach of these dependencies.
Yet somehow, all these lessons from concrete experience (rather than abstract theory) gets thrown out the door in project management, even from managers who were once software engineers. Project management should be there to facilitate message passing and work stealing queues without trying to force when these things happen.
Those who do not learn from commit history are doomed to regress it.
My favourite manager (now retired) had the same philosophy. You'll find a similar theme amongst most people's favourite bosses.
He was an ex-Army (AU) warrant officer and wouldn't hesitate to rip you up like a drill sergeant if it was your fault, but equally wouldn't hesitate to throw it back upstairs if it were a problem with senior management or sales. If any customers were being unreasonable with his engineers, he'd practically teleport to site, sit everyone down, look the customer in the eye and calmly ask them what their business case was for being difficult with a vendor.
He also had a mostly hands-off PM style, he'd just bump into people during breaks at random points, ask a couple of questions, move on. Ask him where the pieces of project were at and he could list them off like a human Gantt chart just based on those queries. But woe betide you if you didn't inform him of any looming problems before they became serious, or if you tried to push blame away. If you came to him with a blunt statement along the lines of "I fucked up, here's the issue, I think this could solve it", he'd bend over backwards to get it sorted.
I've since tried to model my own management style after his - definitely not as successfully.
On anything with more than 5-6 people on a team, a project manager is a necessity. It is inefficient in first-order terms, but keeping people focused on what they are good at (and a dedicated person managing scope) dramatically improves productivity. Generally, less than 10% of hours should be in project management.
Bad project management is a different beast. Bad project managers add needless complexity, waste time, and draw focus to aspects of the project that participants cannot control.
Agile is a manifesto. It's pretty much truisms. Hard to argue with. Scrum is just a daily waste of time.
However Agile has some real concrete components: e.g. 'Hire competent enthusiastic individuals'.
So the first thing to do when a prospective boss claims agile is BULLSHIT DETECT! If the place looks to be staffed with anything other than competent enthusiastic individuals, you know they are just lying to themselves and you. Run away. There is nothing worse than Agile done wrong.
Extrapolate further: Competent enthusiastic individuals...server side Javascript. There are no Agile teams running Javascript on the server! None.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'