Slashdot Mirror
In Defense of Project Management For Software Teams (techbeacon.com)
mikeatTB writes: Many Slashdotters weighed in on Steven A. Lowe's post, "Is Project Management Killing Good Products, Teams and Software?", where he slammed project management and called for product-centrism. Many commenters pushed back, but one PM, Yvette Schmitter, has fired back with a scathing response post, noting: "As a project manager, I'm saddened to see that project management and project managers are getting a bad rap from both ends of the spectrum. Business tends not to see the value in them, and developers tend to believe their own 'creativity' is being stymied by them. Let's set the record straight: Project management is a prized methodology for delivering on leadership's expectations.
"The success of the methodology depends on the quality of the specific project manager..." she continues. "If the project is being managed correctly by the project manager/scrum master, that euphoric state that developers want to get to can be achieved, along with the project objectives -- all within the prescribed budget and timeline. Denouncing an entire practice based on what appears to be a limited, misaligned application of the correct methodology does not make all of project management and all project managers bad."
How do Slashdot readers feel about project management for software teams?
"The success of the methodology depends on the quality of the specific project manager..." she continues. "If the project is being managed correctly by the project manager/scrum master, that euphoric state that developers want to get to can be achieved, along with the project objectives -- all within the prescribed budget and timeline. Denouncing an entire practice based on what appears to be a limited, misaligned application of the correct methodology does not make all of project management and all project managers bad."
How do Slashdot readers feel about project management for software teams?
I've seen a bad project manager deliver bad products.
I've seen the other end of the spectrum where the PM worked with the devs, and was an all round good project manager.
Strangely, when a team works together, yo get a better result. When the PM is a dictator, you get an entirely different result.
The worst is when there is no project management. Things never get done, or you later find out that 6Month late project was because a new hire decided to swap X out for a
Actually I take it back. The worst is when the Shouty boss decides that shouting is project managing. Then the devs will deliver a mish-mash of shite built on a foundation of bitterness
YMMV
Signature v3.0, now with 42% less memory usage.
You know, I'm a bass player (when I get the time). Nothing even close to, say, Flea, mind you, but decent enough. Ever heard the bass player jokes? We're dumb, can't play, have no talent, you name it. Why? Because there's a lot, an awful lot, of really, really crappy ones. Why? Because of how bands start out. The guy who can play guitar well does lead, the guy who can play passable does the rhythm and the one that can barely coordinate fretting and strumming gets bass. Because you can't fuck up too much there, it's easier and with a bit of luck nobody notices when you suck, can't hit a note or be in time. Bass is easy to pick up, hard to master, I can tell you, but it's easy to not fuck up too badly early on. And if you fuck up, someone's gonna pick up your slack and play the bass for the records.
Same with project management.
When you look at the resume of project managers, you find that many of them had a lot of hats so far. Not necessarily even as part of a programming team or a project. But project management is easy, at least to pick up. You don't really have to produce much. You have to "coordinate", and with a hint of luck the team will be good enough to pick up your slack and compensate for your shortcomings.
That is not true for all project managers, mind you. Like it's not true for all bass players. Some get there because they really want to do it and they are really, really good at it.
It's just the army of really, really crappy ones that you encounter throughout the years that color your vision badly.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
"If the project is being managed correctly by the project manager/scrum master, that euphoric state that developers want to get to can be achieved, along with the project objectives -- all within the prescribed budget and timeline.
This qualifier If the project is being managed correctly is the reason why I slam all the evangelists of agile method or extreme programming or software project management... This give such a huge escape hatch rest of the assertion has zero value. Let us take a look at examples.
If the country is run correctly using proper communistic philosophy there will peace prosperity for all the citizens. No it is not some rhetorical statement I dredged up. I am from India and so many so called intellectuals in India make that statement. Ask, what about Russia? Cuba? Problems of China? They shrug and say "nah, they are not doing communism correctly".
The highly qualified and competent astrologers can accurately predict your life events. Give any counter example they just shrug and say, "these astrologers are not competent"
Every problem brought up by the developers or the management is dismissed, "you are not doing Agile right".
These guys have no clue about statistics, larger numbers and scaling issues. In a typical car or a mechanical system, there are hundreds of components making a few sub assemblies. The number of interactions you are looking at is 10^3 * 10^3 = 10^6 at component level and 10^2 * 10^2 = 10^4 at sub assembly level.
The software my team makes has about 1000 source/header files, about 10,000 functions, and about a million lines of code. The potential for adverse interactions starts at a million at source file level, 100 million at function level and a quadrillion at line level. This is one relatively small piece of mesh generation for finite element analysis. The FEM package our company ships has about a 100 exe files and dlls. If you open your mouth to say, "If you have done modularity right ..." you are hopelessly missing the point. This is insane level of complexity that is not addressed by a kind of process change. Development is already doing incredibly complex job, and the project managers come in make impossible promises to the upper management making our lives even harder.
I asked the Agile tool vendor to for a relatively simple, in my view, feature. When I commit a change to the user story state, check it before committing and do not allow me to commit illegal changes. Do not revert my change 15 minutes later and send me an email about, "the test case should not approved before the functional requirement has been accepted". The response, "minimum of 9 months and a huge change to the web API of the project management system and it would invalidate a few dozen mashups we have written". This joker is telling my upper management that our software certified for nuclear reactor design and aircraft aerodynamics can maintain a three month feature definition to delivery cycle. Is they any wonder most development managers want to find the nearest Agile evangelist and strangle him?
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
The PM is where the disconnect happens, but in a bad environment that's what the upper managers want.
The simple test: Your schedule is blown. Everybody can see that critical path is longer than the remaining schedule. Does the PM go to management and marketing to start managing the late delivery and/or missing features that's GOING TO HAPPEN or do they start cracking whips and blathering about '110%', expecting someone to pull a solution out of their ass?
I think the PM role should be on the project technical leads plate, it's not difficult if you're already buried in it. Splitting the roles is only good for fucking it up. The tech lead is responsible for the project, (s)he should have authority to match. The schedule is part of the project plan, the tech lead and industry knowledge expects are the ones to make the plan. Not some clueless 'MS project jockey' who's never slung code.
The old cliche: 'Projects are always on time, until the deadline.' is an indictment of project managers. They sure the fuck know the schedule is blown. But often paid for 'whip cracking, crack using and upper management pole smoking'. That disfunction is deeper.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
I've worked in a team that had a customer, a product owner, a product manager, a project manager, a scrum master, a senior developer, a junior developer, and a tester. I still have no idea why the company wanted to double up on management. The problems had started from the beginning. The product manager spent little to no time obtaining requirements from the customer, they allowed the customer to outsource the designs and then failed to engage them when it came to determining how the designs worked (i.e., the user stories). Note that even without the requirements, the timeframes were already set and provided to the customer. After the "initial" designed were delivered, the product owner and project manager vanished. The requirements gathering was left as a task for the project manager and scrum master; Neither of which wanted to engage the customer to determine the user stories - they made up their own based on how they they thought the app would work.
The developers were introduced to the project. They were shown the designs, and the project manager and scrum master started dividing the "user stories" between the developers. Note that the user stories contained the HEADING ONLY for a feature (i.e., "Show Page" or "Carousel"). The developers were then asked to "estimate" how long it would take to implement each story. The junior developer started to give time frames. I said that it was bullshit. I explained to them that the user stories should cover every aspect of the how the user interacts with the user - not just a title for something they've seen in a design. I told them that this must be a joke. I'll also take this time to say that I was the senior developer (yes a cynical developer who hates management).
Anyway, we were told that we should just start writing the app as their plan was to give the app to the customer often and then "capture" the changes as needed. Needless to say that the project has been going for over half a year, it was due to go to end user testing almost 3 weeks ago, as we're still getting change requests. We also haven't yet got an API to talk to, so everything we have done that requires data has been done with made up data. Note also that the developer that is writing the API is doing it in a way that doesn't allow any collaboration with the app developers due to the fact that there is no time to do it, so once we get the API, we're going to have to go through the code and either change everything that referenced our "fake" data, or have code in place that translates the real API data format into our made up format.
So to summarise, if there is a bad developer in a team the other developers will have to shoulder a bit more work as the code review process should filter out the bad dev's work. But if there is bad management in a team, the product is doomed.
it is only after a long journey that you know the strength of the horse.
Yvette Schmitter is fast becoming the woman that savvy females nationwide are turning to for business advice, lessons in leadership and the secrets of bringing balance to dating and relationships. Yvette has made it her passion and goal to redefine what it truly means to “BE YOUR OWN BOSS.” As a successful entrepreneur and former management consultant, she has made a name for herself at Deloitte as well as Cap Gemini Ernst & Young. In the business world Yvette has focused her talents on the health care industry, specifically on the issues impacting minorities, especially women of color. Ms. Schmitter has adapted her acclaimed approach to the skills of management and leadership into a foolproof plan for all aspects of a person’s life. She is currently in the process of writing her first book detailing her journey and discovery in becoming a real life “BOSS LADY.”
The New Jersey Assembly recognized her commitment to public service and named her Outstanding Young Woman Leader. While working toward her Bachelor of Science in Civil Engineering at Tufts University, she was voted “Leader of the Future” by her senior classmates. In graduate school, the President of New York University awarded her the “President’s Award” in recognition of her continued commitment to public service at the university; during convocation, Dean Robert Berne bestowed upon her the “Dean’s Award” for outstanding leadership.
While working as a senior consultant at Cap Gemini Ernst and Young, Yvette partnered with MAC Cosmetics and a local beauty parlor, Chez George to create a very special event to empower local battered women. The event, “New Year, New Do and a New You”, allowed the women to receive new hair styles and professionally done makeovers conducted by the MAC Cosmetics make-up artists. This combination of outreach and inspiration is exactly the kind of forward giving momentum that Yvette has dedicated her life’s work to
She is also a writer and regular contributor and commentator to nationally acclaimed websites and television networks such as BETTER TV.
She lives in New York City with a very special boy named Chance.
There is no mention of project management anywhere on that website.
Another source dated February 2015 says she is "Network Services Program Manager Government Programs at Emblem Health", which laid off hundreds of IT workers when it outsourced to Cognizant in April 2016.
>Outside of that, why WOULDN'T you write a section of code the simplest and most straightforward way possible?
Because finding that way can take years of research. This is noble work if you can get it.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
I know a couple of the PM's I've worked with on software projects in the past will be angry and disappointed at the subject line but I've never seen one that demonstrably added value to a software project/product I've been involved with - most have been detrimental to the overall effort. I can say that I do know a number of PMPs that are critical to hardware and marketing programs and have been vital to their success - I'm leading to a conclusion here.
First off, today it seems like getting a PMP certification is something somebody gets when they've been laid off and there are no jobs on the immediate horizon. I know that seems cynical but there seems a lot of truth to the statement - if you can demonstrate that you've worked slightly more than two years, take four or five courses and write an exam? In less than a month and a couple of thousand you too can have "PMP" on your LinkedIn profile.
I've taken the courses (through work) and they do have some value for general knowledge and if you are going to be managing a project which results in a physical object. Software is an entirely different beast and I believe it's impossible for really anybody to really properly plan out how a project will go. Unlike planning a piece of hardware, the required skills with efficiency are somewhat more nebulous (ie I can state with a high degree of confidence how many bricks at a certain quality level can be laid in an hour - I can't do the same for lines of code, it's highly dependent on the coder, development tools, libraries as well as pre-requisite work being done). To be fair, it's extremely hard to properly quantify coders - which makes planning and managing their progress difficult.
The best team lead I ever had, lived by the following set of rules for every project:
1. Set an expectation for the number of lines of working, debugged and documented code per day to something which seems ridiculously low (in his case it was 10 lines per day per coder) but is actually very realistic when you look at actual historical progress of the team/organization.
1.1. Plan contingency time at the end of the project (he liked 30% of the total project time) for new requirements and unexpected issues.
2. Coders work four days a week with one day for training and meetings. See "Management Time vs Maker Time".
3. Management can't talk to coders about their work. Ever.
4. Requirements/Specifications can't change through the project. That's what the contingency time is for at the end of the project.
5. Have an established test plan - In talking to him recently, he now insists upon implementing automated unit and functional tests that the entire software corpus runs through before any major release.
6. Base the plan and milestones on a reverse of the 80/20 rule - look doing what is going to be needed for the what is normally the last 20% and do it first
6.1. Pushing the requirement for the final UI design to the end of the project. Let marketing pay for prototypes and implement them at the end of the project. If the coders need a UI for testing, then they can cobble something together (and I know of two products where this became the final UI).
7. Accept that shit happens - I still get teased about putting in the statement "if (i = 1) {" thirty years ago in one of our projects which was discovered in testing in which the code mostly worked with the exception of one corner case that bugged a number of us (including him) into spending a week trying to figure out what the problem was.
You don't need a project manager to run a software project following these rules - you need a good, knowledgeable and forceful team lead.
Mimetics Inc. Twitter
Project managers in most cases are just a layer between two sets of other managers. If you have a good manager, you donâ(TM)t need a project manager.
Project managers are there to make sure that interactions between different managers on multi-departmental projects happen smoothly, they should not manage or get involved with what exactly the IT department produces, just make sure that they develop a solution that fits the needs for the overarching system. Make sure that the cleaning manager talks to the datacenter manager etc. get metrics on every teamâ(TM)s status but when project managers get involved with individual team members they have failed.
The main problem with projects and project managers is that most of them are micro-managers, the project is too small in scope to be considered a proper project or there is a serious breakdown in managerial skills.
Custom electronics and digital signage for your business: www.evcircuits.com
If you have a bunch of programmers who can't focus and look at their phone every five minutes, then project management will help them out.
On the other hand, if you have developers who know how to self-motivate, and figure out priorities, then no, project management merely serves to make the suits feel comfortable.
The goal of good project management therefore should be to help the first group of programmers develop the skills of the second.
"First they came for the slanderers and i said nothing."
Project managers are usually hired by people who have no technical experience and no project experience. The result is about what you would expect.
And I've been in software development for about 2 decades. I've gotten more done the last year and a half than the decade prior combined.
> Outside of that, why WOULDN'T you write a section of code the simplest and most straightforward way possible?
* Because it doesn't report errors.
* Because failures corrupt critical data.
* Because it does not sanitize its inputs.
* Because it consumes far more resources.
* Because it's not testable without the
* Because it's not secure.
* Because "simple" and "straightforward" does not necessarily mean "intelligible".
* Because it requires a complex set of upstream features which have proven unstable.
The list goes on. Balancing the factors to produce robust, reliable, performant code can become quite a challenge.
...you produce.
If you're an independent software vendor (you make software intended to address markets/verticals - not a specific company) then PROJECT Managers are useful for coordinating deliveries and dependencies between teams (e.g. platform/middleware/sdk coordination) if you don't have high quality PRODUCT Managers. Sadly, finding quality product managers for an ISV is both very difficult and very expensive. Product Managers at ISVs are supposed to have domain expertise - unfortunately, many do not.
If you're a product development group that builds software either for internal corporate use, or a services group that builds software at the behest of an external customer then you're likely to use a form of Project Manager called "Product Owner" - which is supposedly some form of "Product Manager" but it really isn't. The person is basically responsible for tracking the project (the job of a Project Manager) and managing inputs taken from the customer - which makes them think that somehow they're Product Managers...
Ironically, it's much easier to come across a quality project manager today than it is to find a product manager that has any idea what their job actually is. Most modern product managers (most, not all) seem to think that they exist to 'ideate' and sit back and let people discern what exactly they meant - "What's an MRD?" "What's a PRD?" Lol...
YMMV
Loading...
Best project manager I've ever worked with made everything go incredibly smoothly, even on tough projects with frustrating clients.
How? She asked us a simple question: What do you need to get this done?
We told her what we needed, she accommodated our requests with plenty of time to meet deadlines and milestones, and then she trusted us to get our shit done while she met with the client and other management for progress reports, etc.
I prefer to write if statements like "if (1 = i)" exactly for the reason it won't run. However, for javascript linting they call it yoda talk and it is indicated better the other way for readability. Normally I would think that is ok, but these types of bugs can do some pretty nastly things are are often very hard to catch.
Every post you right is less easier to read then most, witch are more easier to reed sense they no how two right end you doesn't.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
"If the project is being managed correctly by the project manager/scrum master..."
Scrum master is a person appointed to make sure that the scrum methodology is being correctly executed in the scrum team.
Scrum master is not a fucking manager. Please stop turning them into one.
> Not every task actually benefits from creativity!
Indeed! At my own company, every week somebody is costing us time and money by trying to come up with a creative way to do something rather than looking up how others have done it successfully for decades.
Most recently, we needed to handle many concurrent TCP connections. We wanted to fire off a request, send other requests on other sockets, then come back later and read the responses, asynchronously. This is instead of sending a request, waiting for the response, then sending another request. Developers creatively brainstormed different ways to do this, coming up with mostly very bad solutions. I pointed out that many concurrent TCP connections has been some many times before, sometimes by people much more knowledgeable than us. The Apache web server has multiple different multi-processing modules to choose from, with many sources describing how each works, and the advantages / disadvantages of each.
Last week they were coming up with creative ways to script getting the IP address of a newly launched AWS instance and adding its IP to the whitelist of another security group. I pointed out we're not the first company to want two AWS instances to be able to talk to each other. Perhaps we should check the documentation. Sure enough, AWS security groups allow you to whitelist access from another security group - no need to get the IP at all. Just click the button once, which then allows all instances in the scaling group to access the protected resource.
I've explained to them that there is a well-defined way to represent many-to-many relationships in SQL databases, known-good ways to represent hierarchy, etc. We don't need to creatively invent any of this.