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."
...how long until we automate supervisors and management?
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...
The "smart" people tell me I'm wrong. Then they get sacked, go on to higher paying jobs and are replaced with "smarter" people who tell me I'm wrong. Then they get sacked and go to higher paying jobs while I just solidly churn out product but get my pay cut because they spent their payroll budget paying for these high end managers.
The worst thing that execs do that can kill a company, much less a good product is confusing Project Management with Product Management. One is a trumped up secretary for a team, the other is a leader making critical feature decisions. Very few Project Managers have skills, experience, or even capabilities necessary to be a Product Manager. Any company with a clue is getting rid of Project Management.
said: adding manpower to a late software project makes it later.
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.
Yes.
"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
Or maybe no.
Has the blogger got anything to back up his claims or is it just another consultant looking for a gig?
I've been around for a number of years in the dev trade. I've seen good and bad projects. When project management is done well it makes a world of difference. Everyone knows what needs to be done without needing three meetings a week just to figure out who is working on what. The deliverables get clearly defined, and change management is enshrined and accounted for. Working in this environment is awesome. Now, do project management badly and your project WILL be over budget and over schedule. Nobody will be happy and it will be a crap job. Nobody will be especially clear what the deliverables are because change management is not accounted for and you have moving targets. The team spends more time finding who to blame than just fixing the problem. My opinion - if you are using the wrong tools, you'll have wrong project management. (i.e. Asana is a task tracker, not an asset manager, resource planner, time log, or credential manager... Task tracking is only part of the equation).
Project mis-managers make nice pretty Gantt charts to show the C-suite, but try to actually use them to plan and manage a project. Gantt and PERT were developed as REPORTING visuals during the Polaris missile program to show Congress how things were working. I got a degree in Industrial and Systems engineering before being seduced by computers and during my entire career I never saw any Project Manager that understood that. What's worse they would pull times for task completion out of somewhere the sun never shone.
At one time I was over a group that did final post production QA on in house programs. The project manager allocated a week for the QA testing of the entire system and I told him that it would take at least four and maybe six weeks. I had no input to the original time allocated. On the very first day of testing I was able to find enough problems that when I wrote them up and turned them over to the project manager that day he turned blue. It was at least three weeks work before he was able to get those fixed and give us another shot at testing. Final outcome was that we were right at the six week point before we were able to report the system clean enough to use.
Shitty project management is doing this. But this is no news, is it?
Software stuff is infinetely creative and infinitely complex - it is very easy to screw stuff like this up from a management perspective. Especially since software developers themselves often get predictions about their work wrong - even in an environment where they can control all aspects of their project.
Good project managment is an art and with software it is an exceptionally arcane art. Screw it up even a little and your project goes haywire.
All this is long since well established and it's one of the bains of our profession that we have to deal with day in and day out.
So no news here.
We suffer more in our imagination than in reality. - Seneca
With their SJW company bullshit like not letting you hit on hot chicks and not letting you discuss hot chicks with your co workers. That, and transgender washrooms.
Project Management is a purely Capitalistic invention that was created for the sole purpose of pleasing shareholders - to tell them precisely when they would be spending money and receiving revenue, and precisely how much it would be, in advance of forevermore.
This was its primary purpose. However, it has a nefarious secondary purpose. My company sent me to a PM program and in that program I learned that schedules are there to suppress employee performance reviews to justify not giving meritorious raises. It was right there in the slide deck, in black and white.
One of your goals as a PM is to make sure resources (not allowed to say "people") are NEVER actually on-time, so that managers can use that as justification for mediocre performance reviews. "Push really hard for the stretch goal and make sure it is known that anything else is doing the bare minimum and will not be rewarded." That's what is written in my notes from the class.
Then they invented what is called the "schedule performance index." That is a measure of how well a resource is conforming to the schedule. SPI less than 1 means being late (which is the desired outcome) while SPI greater than 1 means being ahead of schedule. When a resource has an SPI greater than 1, action should be taken to bring the SPI back down below 1 as quickly as possible, either through additional work allocation or by initiating a quality audit, which slows a resource down significantly (a quality audit is basically saying "hey your SPI is > 1 and you're going too fast, so we worry about the quality of your output, so we're going to demand all of these additional reviews because you're not taking your time, and BTW this lack of care for quality will be noted on your performance review).
Modern PM initiatives also require a 2-sigma gaussian distribution of performance review outcome. So, in other words, within 2 SDs of the norm are considered "meets standards barely" while anyone below 2 is seriously underperforming, and over 2 are your one or two "superstars."
This is what PMs are being taught to do. I wish it weren't true, but if you're a technical resource (recall, not allowed to say "people"), you truly are damned if you do and damned if you don't.
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."
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.
"Is HR turning away good job candidates because they are looking for perfect job candidates?"
I feel like some people are refusing to listen to the truth and then after battling with reality for years, they finally arrive to the same conclusion only to announce it like it's some sort of new groundbreaking discovery.
Anons need not reply. Questions end with a question mark.
"The bigger and more comprehensive the plan, the better"
The plan that is genuinely comprehensive enough can just be compiled and shipped as the software product, no?
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
There's the stupid saying that I'm sure we've all heard, "A bad craftsman always blames his tools!". The reality, though, is that some tools are just fucking awful, no matter who is using them. Even in the hands of the best expert to have ever existed there are tools that won't work well at all.
We see that happening with software development. As we've seen more shitty tools like Ruby, JavaScript and even Rust be used, we've seen software quality decline steeply. Such software is often slow. It's bloated. It's hard to maintain. It's just an awful experience for users and programmers alike.
Rust is perhaps the epitome of this phenomenon. In my opinion it takes the worst aspects of the major programming languages, adds in confusion, adds in hype, and the results are a stunning disappointment. Look at how little has been accomplished on Servo, a new web browser engine specifically written in Rust. I've been tracking its progress for a couple of years now, and it's very underachieving, I think. I'd say it's no better than a late-1990s era browser engine, and in some ways it's worse.
I wish we'd see programmers go back to the days of using languages like C, C++, and Delphi. At least that software worked well, it performed well, it was usable, and allowed developers to create and maintain the software within reasonable time frames. It's a far cry from the JavaScript or Ruby projects we see today that deliver a crappy user experience, and it takes the programmers forever just to get something built.
...Programming, Motherfucker!
I first hit this in the 80's. Our company was the first to use microprocessors to replace walls of computers with boxes maybe 3 cubic feet (1x1x3), that by the way did 10 times the work the walls of computers did.
One quarter the defense budget got cut and we went from growing 40% to 20%. 20% growth sounds good to you and me. But to the bean counters it was a layoff. That got the expected profits for the quarter back in line at the expense of future growth and morale.
I have to admit, that first layoff got rid of a lot of deadwood. But the second, third, and fourth really killed the company. Those that were either marginal, or not good at politics, got canned. Those that were good at their jobs looked around, said "um, how about no", and left.
I got hit in the 4th layoff, and only got laid off again once since I learned the signs. The second time was a start up failing, I hadn't yet learned how to read a balance sheet.
MBAs don't understand the morale hit they take when they do a layoff. They may say they do, but they don't. I've survived several layoffs, each time morale went to hell and a lot of good people went searching for more stable pastures.
...that they're worth every penny. They take care of all the bin shuffling and cat wrangling so the developers and engineers don't have to.
Wow. So much to say on this I don't know where to start. In embedded system development, where you are co-developing HW/FW/SW, there is such a mismatch between worlds that I've yet to see a good way to manage it. HW often has three+ month iteration cycles so it is a complete mismatch with software cycles. The only PM magic I've seen is Design Reviews Up Front (DRUP). For example, after the HW folks have rough block diagrams done in the first week or two, have a deep design review with ALL parties (ME/FW/SW/Mfg/Buyers/Service/etc) BEFORE they start detailed schematic design then have another DRUP before layout. This is the closest thing I've seen to continuous integration in embedded systems. Far too often I've seen the EEs show up for the only design review with finished schematics three days late for sending it to layout only to hear from the FW or SW team that the CPU they've chosen will not work. Of course by then it is too late then to fix the problem. The SW team is usually off developing on an overpowered development board (or worse, PCs) that has no relation to the real target so the SW will never fit the real product. The other big review fail I've seen is only inviting your discipline to your design review (eg., only EEs to HW). Inviting only your tribe to only a final review is only an exercise in "how can our tribe improve for next time," not a way to improve this product. I still do run things scrummy, but tend to be very lax on estimates, etc.
Because yes.
All one needs to do is... ask Betteridge.
I have no special gift, I am only passionately curious. --Albert Einstein
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.
If the project is feasible, good developers will get it done regardless of or even despite the plan. The vast majoity of plans have problems because they want a man-year's worth of code from three months of work, which means it was never a good plan. But poor project management can turn a bad plan into a disaster by refusing to acknowledge the delay. I've been in meeting that pretty much involved badgering the developers until our estimates said we'd deliver. Oddly enough those "revised" estimates never came true...
Live today, because you never know what tomorrow brings
Good project managers say no.
So, they get fired or sidelined and the ones who always say yes but are are all bullshit and smoke rise to the top.
That's from a lot of years in the software industry.
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.
Whoa man all the cool hip project managers Agile development as it solves 100% of the problems 100% of the time. It makes you grow a beard and transports you to a hipster Silicon Valley coffee shop with music playing that hasn't even been written yet complete with groupies watching you code.
http://saveie6.com/
Wouldn't have hurt if the author had been given a project plan and a deadline for that article.
Maybe I'm getting old and impatient but it went on for far too long.
Great sentiment and I have seen many of the effects mentioned, but hey, summarize.
If I had a DeLorean... I would probably only drive it from time to time.
Has anyone here worked for Apple, with Steve Jobs or Tim Cook as CEO? I'd love to read what you say about their styles, and their strong and weak points.
And if you worked for both men, then even better - I'd love to read what you say about how they differ.
project managers that graduated from the school of flagellation
I've encountered one that it even worse: the Golgafrincham B ark school of project management where you have to hire a business consultant to go around and make sure that the project really is what we need and, after that, to ask whether the proposed solution will satisfy everyone, and after that to... etc. although it did not get quite as far as involving telephone sanitizers. The result was that what should have been a simple one or two month project took over two years, much of which was pointless and endless consultation to learn what we already knew and it delivered something less useful than it should have been because everyone just wanted it to be over.
So really bad project management not only kills a good product it can almost kill your will to live!
What is this Theory X?
I am still using the Waterfall Model and IBM's Rational Rose Modeler. Does software development get any better?
The difference between an effective and ineffective PM is astounding in most places I've worked. On one end you have a forceful PM who will beat up their resources and harass their managers until the work is done. On the other are the PMPs clinging for dear life to their copy of the PMBOK who are unable to get anyone to do what they want.
You can tell a PM isn't so great when you hear the exact same phrases and jargon repeated in the exact same order on endless conference calls. [1] I'm not saying it's easy either...I could never do that job because I can't coerce people to do what needs to be done. And when it comes down to it, that's a PM's only job...well, that and checking the boxes and filling out Gantt charts.
[1] I swear that one PM I worked with would say "Good morning, who just joined the call?" in the EXACT same tone, rhythm and texture at the sound of every beep on conference calls. It was like a machine!
I work in the auto industry. My big problem with PMs is that they aren't goal oriented. They never ask "what is my goal here?" They just ram an agenda (every problem is a nail if you're a hammer). Different projects have different goals. Did we sell a new 4-zone HVAC controller for an upcoming 2020 SUV? Well, then, come hell or high water, we need to meet deadlines. But, most projects don't have that kinda of relationships. I have done production, tight-timeline projects, true blue sky research projects and several notches in between (today I do something like one or two iterations back from the latest tech, so advanced but not quite research). If you run an advanced development project like a production project with a date vehicles need to be off the line, you're often missing out. The certainty in timeline may be required (for example to beat a competitor, some outside date factor or to finish a demo for some event). But, it usually isn't. But, do PMs think like this? No. The concept of "opportunity cost" is foreign to 99% of PMs. There is an opportunity cost to certainty. More certainty = less efficiency (and that usually means the feature set is cut down or projects get longer as a nearly-direct result of bad project management). You'd think PMs familiar with real-time systems would know this shit.
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.
Get one really intelligent, experienced, accomplished developer who also has really good leadership and communication skills.
Give them two to three assistants. Best if you let that person pick their assistants.
Plan what you're going to try to do.
Identify the shape of it (context, architecture, UX/UI, high level requirements and/or stories.)
Identify biggest risks and biggest value opportunity directions.
Let team go to it.
Assess.
Revisit.
Where are we going and why are we in a handbasket?
Double it and add 30.
FTW Also roughly converts Celsius to Fahrenheit.
Where are we going and why are we in a handbasket?
In my experience, good managers mitigate risk. Itâ(TM)s getting the right balance of efficiency and redundancy. Adequately buffering for over-optimistic expectations, and calling BS on unnecessary work and priorities.
A good manager has a plan B, C, D, E, and F ready to go when things inevitably donâ(TM)t work out as planned.
A good dev should be responsible for their own work and maybe adjacent dependencies, but beyond small teams, you end up needing dedicated folks to coordinate anyway IMHO.
They're trying to reduce everything to statistics and numbers, like Robert McNamara did in Vietnam.
It's trying to make sense of something they don't really understand - the human element. The chaos. Motivation. Leadership. Ability.
"If you can't measure what's important, what you can measure becomes important."
Does no one here have a budget?!
At some point, you need to know when to kill off a project and when to go look for more money for it. Money is finite. Complexity, uncertainty... fine. Doesn't matter. It's not just programming that progresses non-linearly, just about everything worth doing works that way! Management works that way.
Create whatever anachronistic management theory straw man arguments you want. In the end, either you finish the project before the money runs out or you don't.
A persistent problem in project management is that managers are on the manager's schedule while the developers and engineers are on the maker's schedule. This problem was described very well by Paul Graham in the original Maker's Schedule, Manager's Schedule article and was discussed here on Slashdot 8 years ago and it's still a problem. Failure to understand and appreciate these observations is the source of much wasted time on many software projects.
I once did a project without project manager, well there was a project manager on paper, but we didn't even see him ever, we only got one email from him asking "how is it going" for which we replied that we are doing fine.
Anyway, the project was finished weeks early, it had only one bug reported (the software was performing too well so we had to add a sleep into it) and the product saved a lot of money for the customer when it was in use.
agile is an adverb. can be put to anything you do. the opposite is also true. agile is no process or structure or even lack thereof.
was being managed by people that someone promoted (occasionally myself) because that was the only way to get negative-contributors off their team.
The funny thing is before a major shit decision, they expect "noise" from IT and told to ignore. Dont feed the trolls.
A good project manager understands the job and people: she/he knows the team, the product, customers, she/he involves people whatever the weather like.
It is a balancing act that is really performed well by people having knowledge, know how, empathy and without an oversized ego.
If your project manager does not train people (does not know the product) and the staff is quiet new (turn over), it is a run-away sign:
"At least a manager in a McDonald had to work in the kitchen and make burgers"....
In an agile team using Kanban, for example, there is no “project” at all—there’s only a continuous stream of value-delivering work, prioritized by someone who keeps a finger on the pulse of the customer and validated with actual customers.
Yes, we use Kanban, and we deliver a continuous stream of value-delivering work, prioritized. However, the prioritization did not come from someone but an entity of 3, composing of the Project Manager, Product Manager and the Product Owner. These 3 negotiate the best strategy forward, cater all the late changes, factor in the available resources, and keep eyes on the deadline. Yes, there is always a deadline, like it or not. A company with sustainable business have to release a new product when it is still perceived to be valuable to the market, not after.
Project Management has one key role in all the developments - to manage the resources. A development has only finite resource, be it money, people, space, time, equipment, or skillsets. It is obvious that it is not someone who keeps a finger on the pulse of the customer and validated with actual customers who is managing these. Bad Project Management skill can of course get in the way, but so as Bad *. That we should never use these examples to mislead the reader into thinking because some people do not qualify for their roles means those roles are not essential or better off without.
the most obvious being the assumption that it is possible to deliver quality and completeness by the deadline
OMG! This is 21st century and who on earth would still assume this!? No, everyone knows this is not possible, and that's why Project Management work so hard to ensure in advance the necessary resources are in place when needed so that the critical components are ready with an acceptable quality by the deadline.
Focusing on projects can also compromise architectural integrity. For example ...
I don't see why it has to be the case. A well planned project executed by competent people would not draw anything like the example given in the article. Again, we should never use these examples to mislead the reader into thinking something is not needed because of these bad outcomes where the actual reasons lies somewhere else.
Product Centric development does not exclude management of resources nor people. Product Centric development (or rather Value Centric Product Development) focus on business value but business value also tied tightly to the market, thus time, and delivery of value requires resources and therefore management. You can dissolve these functionalities into your team and call them whatever you like, but the role of Project Management is still there and needed, unless the available resources are infinite relative to your development needs. Then may be you should try a bigger development project?
--
No sic due to sic called a sic leave today, said it's sic.
A good management attack can utterly destroy any project.
LIke any other kind of parasites management ruins the ecosystem in which it lives. Linux kernel has no management, only reasonable set of rules and procedures.
It takes a lot of effort to create and maintain a project plan. And the end result is that it is used by management to beat us bloody.
"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."
This describes the process of IT, not just software dev. In every IT job I have had, I was not trained in the specifics going in. I had a degree and an (at the time) cert in demand, but always seemed to get hired for jobs that used similar but different products. I was often on my own, so I was the teacher, the student, the system designer and my own mentor. I did a TON of what Mr. Lowe is talking about. The similarity is that you still have the "how long will this take? When will it be done?" pressure leaning on you in some way, shape or form. You learn to give very very long estimation times so if/when things work out the first time, you look like a hero.
> For the next sprint, you use as likelely doable number the actual completed SP from thr current/just finished sprint.
We're partially in agreement. I said project management should see this team does about 98 points per sprint.
The team likely does some points that aren't their current main project - a few points supporting last month's project, for example. Some companies include points for things like annual compliance training, which is not part of this project. So we can expect that some of what gets done will not be part of this project.
Also, there is how much will LIKELY be done and how much they can PROMISE. If you're telling your biggest customer, or even top brass at your own large company, when the project will be done, you should give a conservative estimate, thinking "we can do at least 85 points. Probably around 97, but at least 85, so let's assume 85 in the plan we present to the board." It's far better to complete a project ahead of schedule than to behind schedule.
Some companies include points for things like annual compliance training, which is not part of this project.
But that would be wrong, see below.
Probably around 97, but at least 85, so let's assume 85 in the plan we present to the board."
Then you are cheating yourself, and never will learn the benefits of agile software development.
And, to my frist quote: how do you sell the extra points to your top brass or customer? That does not make any sense at all to have anything with points in a sprint that is not related to the project.
If you can not do your 95 SP, because your team is busy doing other things, then don't give those other things points, but substract that from your sprint velocity, do 60 SP instead of 95 and tell the management: look here! We can not work with 95 SP because we get extra work load that does not belong to the project.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
All Scrum is Bollocks
YES
Thank you for this....