Then it's a good thing we have a platform that lets you and a million others pitch a few dollars at a high-risk venture, instead of begging banks for the payoff.
That's all true, but they weren't exactly lauded kings. They were treated like slaves, and people have to take that out to absurd conclusions: the occasional beating, the rape, the right to just kill them for looking at you wrong, it all translates to evil men satisfying their sadistic bloodlust at all hours of the day.
It's really the kind of mistake fiction writers frequently make: the bad guy doesn't have motivations; he's just evil. He stomps on children and kicks puppies so he can gloat about how deliciously evil he is. Even Holt Fasner and Vladimir Harkonen weren't like that; Fasner only cared about himself, and Vladimir *was* a sadistic ass, but neither of them were evil just to be evil. Even Vladimir Harkonen believed what he did was creating progress, bringing order to a universe fraught with the weak and the unstructured, an untamed wilderness that needed to be paved over and modernized into a giant industrial machine where men labored for more progress; his sadism was a personality quirk, not a big red sign to show that he was evil embodied.
To give slave owners motivations is to make them human; and to make them human is to admit you have the same motivations. Slaves would be useful, and the fruit of slave labor would be desirable; and you reject slavery because it's wrong, and so you try to strangle off that recognition that it would be useful. Most people can't fathom the act of taking the correct course because the things you'd like are simply morally wrong; you're only a good person if you find those things undesirable and have no interest at all. If you simply turn away from the temptation and stand fast to what you believe is right, you're just a black-hearted devil dressed up like a white knight.
Nobody wants to admit that Adolf Hitler was the logical conclusion of every-day human thinking.
Oh, I don't know... because worker seems to imply they had some choice in this instead of being property.
Slave labor is still labor. They're still workers, and they still need to get paid. The difference is we pay them what we want, not what they want; sometimes we don't pay them enough, and they starve, and it's expensive.
That's something a lot of people miss: there's all kinds of novels written in worlds where they reference some backwards nation or evil corporation using slave labor and thus having infinite resources because it's free. Problem is you have to feed your slaves or they die; you have to give them medical care or they don't produce as good a rate of return; and somebody has to make that shit. Slaves are farming food? That's great. You can take, say, 90% of it, and the other 10% is their pay because they need to not die or you'll need to spend 60 times their monthly budget on a new slave to replace them. Think about how useless an 8 year old is as a worker; do you want to sink all that slave labor into building a new slave, 8 or 10 or 14 years before it's even useful? Maybe you can get a better deal paying sailors for 10 months of their time sailing to another country, abducting people, and sailing back with their catch.
Slave labor wasn't as bad as people believe... if you lived long enough to be slave labor. Getting abducted from your home, dragged packed like sardines in the ship, more than half your comrades dying of disease and malnutrition, poked, prodded, sold, screamed at... if you made it, what you got was a shitty life akin to poverty in prison. People imagine slave masters constantly beating slaves while smiling wickedly with demon fangs poking out of their mouths; in reality, the actual labor wasn't too bad, just everything else about life sucked--particularly the part about being property, confined to a barn like some sort of mule, and occasionally raped.
What it was was inefficient, expensive, and nationally embarrassing. It was so embarrassing we instituted a compromise in the Union whereby half of all states would be slave states for some 50 years, after which the Federal Government was allowed to legislate slavery away. Then we got in a war with ourselves about the whole thing. The end of slavery was put on the horizon, and then we took it by force when we got there because that's what we agreed on.
People want to write revisionist history. Some folks want to downplay the facts; others want to play them up until we're looking back on gloating, horned demons. The truth is somewhere in the middle--but not right in the middle, like the "fair and balanced" advocates want you to believe. Averaging the wrong views doesn't get you the right view; it's usually off-center.
This is why I haven't opened any video game projects yet: until I have art and some kind of video to show, it's not worth trying to get money to hire artists to create the graphics. Just a plea of "I know how to make this work, but I'm not an artist or musician" and a picture of XKCD Adventures that demonstrates nothing isn't a good way to beg for cash. Credibility isn't returning actual results; it's convincing people you can return results eventually.
It's a venture with risks; you took the gamble. When banks do this, they want a market analysis, a comprehensive business plan, timeline projections; when people play on Kickstarter, they just throw money in and ignore the disclaimer of no responsibility. I can speak the language of comprehensive project plans and market projections; most folks can't, and wouldn't understand it if you put it in front of them, so what do you want?
The lower-regulation space allows fools to part with their money, and it brings the advantage of funding people whose vision stares down the longest barrel of hell--or just picks up on things the usual suspects can't grasp. You want those advantages, you allow that sphere, and you warn the players this is the nondescript poker table where we don't check too close for credentials; you might meet a few card mechanics who can shuffle four times and put the cards in any exact order they desire, but they're mostly decent people trying to play fair. You want it both ways, you set up two tables, and let the players pick where they want to sit.
I did figure out how to solve poverty. I found politics to be a hindrance, though, so maybe not so great; people are more concerned with inflicting harm on those who don't fit their ideals than with efficiency.
Push deadlines. Achieve milestones. Progress timelines. Pick one, but whatever the terminology, no matter what nonsense systems engineering metaphors you use, none of these is a scrum masters responsibility.
Those things are the ultimate responsibility of the Scrum Master. The Scrum Master's responsibility is that of a project manager, scheduling, budgeting, managing human resources, handling stakeholder engagement, improving organizational processes, archiving project information.
You may as well say a.NET developer's responsibility isn't application architecture, and that designing applications should be left to a computer programmer.
By your definitions in a "weak-matrix" organisation, such as a software development team, a scrum master may eat the project managers lunch, though in a "balanced matrix" organisation the project manager is essentially redundant to all intents and purposes for software development as your department head, VP of engineering, whatever may essentially drive a scrum team directly and the team itself assume the remaining responsibilities.
That makes no sense.
In a weak matrix organization, a project manager would run a waterfall, iterative, or agile (scrum) project. He would manage the planning and communication, but continuously go back to functional managers, department heads, and the project sponsor with "I need Jason to do this" and "We need to schedule a meeting with our Engineers and our Finance head." On a Scrum project, he'd handle all the Scrum meetings and do all the tracking; it'd be different documentation than with a Waterfall project.
In a balanced matrix organization, the project manager would have a Project Charter listing his authority to acquire resources. Money, human resources, people he can schedule into meetings, the like. He'd do the same thing as in a weak matrix, but without running back to the sponsor to ask permission for every little thing.
A Scrum Master running a Scrum project would handle a project charter, project documents, budget projections, scheduling, a work breakdown structure, procurements, stakeholders, reporting, collection of work performance information, and so forth. Just as a C# Web application programmer would use C#.NET Web namespace classes while a Python Web application programmer would use CherryPy and Moko, a Scrum Master running a Scrum project would handle project activities by having Scrum meetings and distributing tasks among a project team who is estimating essentially just-in-time, while he would instead break out what tasks he can and schedule them in the Project Schedule Network in waterfall.
You seem to keep falling back on this idea that project managers do nothing. They do quite a lot. Scrum may have some interesting lifecycle diagrams, and they're derived from familiar industry standards. PDCA is ultimately derived from ISO 50001, which is ultimately derived from PMI, where Monitoring and Controlling is the Check and Act part, and Planning and Execution are obvious.
The fact of the matter is the larger framework Scrum masters follow is the same framework as change management and planning cycle in PMI, because it's only another tool swapped on top; Scrum does not bring its own methodologies for procurements, resource management, or larger planning. All of that stuff comes from PMI, while Scrum prescribes how to handle monitoring and controlling.
That's hilarious. I've seen multiple companies fire backup administrators for the same shit--looking to see if the backup process ran, but not if it completed. 40-hour back-up process terminates in 3 hours because you need to back up other shit? Never completes.
Just about anyone can fuck up by the numbers. We have Git and such today, so your QA manager can accurately monitor such things. There should be a change review board and a senior programmer involved, with each hotfix or other update going into its own branch; that way you can code them, test them, justify them, and merge them in independent of any review process. Much more flexible than getting authorization and giving explanation as to why you did each little thing before you can actually get on with your work.
Project management integrates pretty well with Scrum. You still carry out your risk planning, human resources acquisition, and work breakdowns; Scrum passes work packages down to the team to break out into activities and tasks, and so forth. The burden of estimation moves around a little, and the process rolls changes together more rapidly, and you continue on with all those things you usually do anyway.
It's like when you used to run old real-mode programs, and the scripts would load a program into memory, execute it to end, then load the next, halting on errors. Modern cooperative multi-tasking runs for short time slices, then checks priorities and reschedules CPU resources; programs will halt and wait for interrupts, and then regain control when IO requests are complete or new events come down.
Scrum assumes a *lot* of changes due to projects being too complex to plan in the long term; if your project is straight-forward and you can plan it with reasonable accuracy out to its completion, you should use waterfall, or at least an iterative or incremental cycle based in rolling-wave planning. Constantly interrupting your project to ask what's happening and decide if you need to rearrange work is a waste of time. If this happens a *lot*, planning for it is more efficient than assuming it's never going to happen, and so Scrum becomes faster; if it happens almost never, plan for the eventuality and execute as if everything's going to run perfectly until it doesn't.
Functional (run by department heads), matrix (weak matrix, balanced matrix, strong matrix), and projectized.
In weak-matrix organizations, the project manager is often a facilitator. Balanced-matrix departments start defining the project manager's level of authority, giving him the explicit right to requisition resources under the sponsor's authority: your VP of Engineering gives you the authority to requisition 4 engineers for 16 hours per week from the Engineering departments under him, to communicate with other departments to gather requirements and interface with stakeholders, and to spend money within a given budget, all tied to the scope of the project.
The project manager's job still remains the same in all cases: find the most efficient way to plan and execute the project. If he has no power, he has to take it back to department heads and VPs--to the sponsor--to lay out recommendations for action. That includes who to hire, what to buy, how to schedule, and so forth. The decisions are ultimately made by whoever has the vested authority to make them, which may not be the PM.
This should be obvious, considering "push deadlines" is a meaningless phrase essentially expressing "I don't know what I'm talking about".
"Certified" is used in some titles. You get "Project Management Professional" (which is a certification requiring actual experience), but also "CISCO Certified Network Engineer" or "Certified SCRUM Master" or "Microsoft Certified Professional". It's a credential thing.
When I ask them what they could have done better in hindsight after a project, you get a cornucopia of ideas. That person is hired!
Project Managers are supposed to constantly collect and file Lessons Learned as part of historical information for a project. This is continuous: work performance information, risks, project document updates, and lessons learned constantly pile up as you do anything; all of that gets filed as it comes, and the Project Close phase explicitly includes filing all Project Documents and Lessons Learned before the project is officially finished. In future projects, you refer to this stuff to make sure you've thought of everything your organization's collective experience is capable of.
Project management also involves a lot of engagement with subject matter experts in the planning phase. A lot of old-school managers like to command from on-high with their own experience; that tends to exclude a large chunk of the organization's collective expertise, since they never bother to ask anyone else what they think.
developers don't like "processes" that are forced on them from higher management, but they are willing to embrace anything that makes their job easier.
Project management tools are selected carefully by the project manager, if he's competent. You pretty much always want a requirements document and work breakdown structure; you don't always need the full gambit of human resources management, risk management, time management, scheduling, and so forth to actually manage time, risk, or whatever. It depends on the size and scope of the project. You still do all that stuff, but in a faster and less-formal way; risk management can come down to "what could possibly go wrong?" and whatever anyone can think up in a short meeting instead of a process of identifying risks, qualitatively analyzing them, quantitatively analyzing them, formalizing risk response documentation, adjusting the project plan to avoid any risks not acceptable, and so forth.... if you're building a mainframe, you do all that long, drawn-out bullshit before you start engineering the damn thing.
If the parts of the process you select are appropriate, then your developers will have greater peace of mind. They might complain at first: the brain hates new things, and has to expend excess energy to change its habitual behaviors; but the brain also recognizes when previous routine energy expenditures go away, and any process that actually produces positive results will become critical to a person trying to cut down their workload. If you try to tack a bunch of weighty bullshit onto a small project that's going to take three people two days, they're going to recognize it for what it is: a load of unnecessary crap you should have shoveled into the garden instead.
Miscommunication. You should have told him you can make a working prototype in a day, but it will require a *lot* of trade-offs, will be of low quality, and will need following-up to shape it into something actually reasonable. If he needs a crutch to lean on for 4 or 5 days while you deliver a viable product, you can get him that; but you can't get a finished product in one day.
Communication is the responsibility of the sender.
The official role of a project manager is specifically to guide the process of completing a project. The project manager's job is called "integration", and it involves integrating scope management, time management, budget management, quality assurance, human resources management, communications management, risk management, and stakeholder management into a complete process to ensure the measurable success of a project.
All project management has its uses. I work in a shop where I see the perfect place for waterfall, for iterative and incremental, and for scrum management techniques. I've seen projects which should have been broken into phases managed by each of these various techniques, or a combination thereof. I'm always looking at projects and whittling away the tools from some, or piling them on for others: you really do not want to use every last project management process on every project all the time.
I work with a few certified SCRUM Masters, and their shops are straight SCRUM due to the nature of their work: distributed among many developers, short deadlines, lots of maintenance, and constant changes. When you can get five new requirements in three days and your work is on-going adaptation of existing systems to new needs, traditional project management doesn't work. In most shops, you want to curb that behavior; in shops tied to politics or media production, that's the nature of the business in entire, and so you find a way to do it effectively. The CSMs are very good at their jobs.
I asked them once how that crap works at all. They went over a number of interesting points with me; one I'll never forget is the impact of people's self-expectations on their work. In a SCRUM shop, you have to keep an eye out for burn-out: people will estimate work incorrectly, promising it can be done by the end of the day; then they'll work 14 hour days trying to meet their estimates, instead of coming back the next day and admitting they can't do it that fast. Do this long enough and your whole team runs for about 8 months, everyone excited to be in such a dynamic and high-pace environment; then they all burn out, become miserable, develop severe psychiatric disturbances, and stop working entirely. The revolving door gets itself moving, and you find yourself facing high turn-over and low productivity.
You have to remind people that proper, correct, accurate estimation is one of the lessons we learn along the way. We'll estimate that we need 2 days to do something and do it in 2 hours; we'll estimate that we need 1 day to do something and do it in a week. We learn. We don't need to burn ourselves out trying to meet unrealistic deadlines we've called out for ourselves; the work either gets done or it doesn't.
People like this unrealistic ideal that anyone they don't like is some kind of irredeemable demon whose entire life revolves around punching babies and kicking puppies by pure reflex. The truth is people largely fall into groups, march with the group mentality, and develop fears and prejudices and all kinds of other things revolving around their sense of security--including their sense of entitlement, whereby they feel others are attacking them by not giving them what they rightly deserve.
You hear a good many vocal Americans talking about how we need to kill all the Muslims, or how anyone brown is a terrorist, or whatnot. If you really look around you, you realize Hitler was just your every-day dude; he happened to gain power over a country and its military.
That's like saying if my mother had wheels, she'd be a car. The fact is, it doesn't take as much labor.
That was exactly the point.
The simple fact is, more automation means less price, at every step of the way.
Less *cost*. Labor cost is labor price times labor hours; if it costs $500 to produce a thing, you can't sell it for $450 and profit. Lowering these costs to $200 lets you sell it for less and still profit. Price comes down due to many factors, but those factors either pressure you to lower profits or to bankruptcy.
Competition assures that prices will more or less represent the value-add of labor at each stage (including design, marketing, etc) with a margin that is competitive with the competition.
Complicated.
Direct competition is fast at reducing prices; while indirect competition is less-fast. For example: Crocs, once all the rage, have become boring; now it's iPhones, and the shoes have to compete with iPhones for limited consumer money.
As well, you have capability. If you own the best coal mines, the next mining company can't dig coal out of the ground and sell it below the inflated price you're charging. You get 100% anthracite out of a 100 cubic meter block for 10 labor-hours, he gets 25% anthracite and 75% rocks and dirt out of a 100 cubic meter block for 10 labor-hours, you charge 4 times as much and he can't undercut your prices. If that guy invents a way to do it in 5 labor-hours, you'll have to bring your massive inflated prices down, at least long enough to undercut him and drive him out of business so you can buy his mine and his patents.
Inflation also tends to push prices down. You have 10% inflation, but consumers hate rising prices, and so you have to stay competitive by only raising your prices 8%.
Neither inflation nor deflation is directly linked to labor.
The buying power of a unit currency follows the total income divided by the total production. Lower the labor required for production and you increase the ability to produce, as well as allow for lower prices. Production is influenced by labor requirements, which are influenced entirely by technology--do we have assembly lines or artisans? Power tools or hand tools?--and thus labor can impact inflation or deflation. If labor efficiency--productivity--increases without an increase in per-capita income, you get deflation, as the competition pressure actually pushes prices down in an absolute sense, rather than simply in the sense of percent of total buying power.
There are a lot of interactions predicated on other interactions.
The value of a unit of currency, physical or virtual, is a function of the nation's total wealth (usually measured by GDP) and the total amount of that currency. It doesn't matter where it is or if it moves. That has no effect whatsoever on it's purchasing power.
So. The rich have $33.6 trillion sitting in accounts doing nothing. Am I to believe that they can spend all that money by January and have zero impact on America's economy and the global economy in general? No inflation as a result of massive expense? No shortages of goods? That raising the total income of America's economy from its current $12.6 trillion to $46.2 trillion will do absolutely nothing?
That is your assertion.
If you're so interested in economics, study it. You'll be amazed by how old your ideas are.
The framework is old. The ideal that all production costs are labor--that even the liberation of coal from the ground rather than its production from chemical methods is simply an available lower-labor means of producing coal--is fairly classical. Many of those specific points you claim are wrong, however, are radically different from anything I've seen. You're using the claim that money supply divided by GDP defines money's value as a way to show that my claim that total income--total money spent on goods--divided by total production--total purchased goods and services produced--indicates the purchasing power of a unit of currency is not new.
There's a big difference: I don't pretend that money that's supposedly out there somewhere doing nothing is part of the economy; you do. I also don't purport to measure GDP by measuring money; I don't really measure GDP at all, except to say in the relative sense that the same labor-hours produce more goods, and the same goods are produced by fewer labor hours, and that this is a trend which has specific implications for the economy. At current, I don't see a good way to measure productivity: the practical implications of reduced labor for goods go far beyond the relative labor costs and associated purchasing power paid for those goods. Small changes in productivity can have dramatic impacts on quality-of-life or on population growth; they can also have nearly no impact, just getting shinier toys into people's hands.
Think about the invention of cheap steel processes and the sudden ability to create affordable railroads, compared to the dramatic miniaturization of computer hardware and the ability to create smart phones: the cultural and economic impact of smart phones over cell phones is actually tiny compared to the cultural impact of railroads. Money doesn't come from railroads; it has to be printed and produced. All you'd get is lower costs, lower prices, and the same total income--the same amount of money spent on everything, and no increase in GDP even though production and productivity both increase dramatically.
By the by, how do you measure a nation's total wealth? A nation of 5 million population with the productive output of America's 320 million citizens would have *quite* a high standard of living, you know. Doesn't it seem obvious that a nation's wealth is a function of per-capita production, equal to per-capita buying power? A nation can't be wealthy if it produces only enough to feed and clothe half its citizens, no matter if that nation produces a hundred times more than the next small nation-state whose citizens all have fine silk gowns and plasma TVs.
We should NOT reduce the cost of labour, if anything labour costs should be a higher portion of the cost of a product.
That leads to poverty. It leads to making the poor poorer. It leads to starving children, homeless men, unemployment, the slow growth of jobs, the reduction of product available to the common man.
The cost of a product--the minimum price--*is* the price of labor. It takes man-hours to harvest oil, man-hours to transport steel, man-hours to refine parts, man-hours to assemble, man-hours to sell, man-hours to process credit, man-hours to manage. Make those man-hours more expensive and the product actually costs $10,000 to make, and you have to sell it for more than that to make a profit. Make those man-hours less expensive and the product only costs $2,000 to make, and can be sold for cheap.
If the consumer has $600 available to spend and you have a new product to sell for $400, you can sell that product. You'll have to employ man-hours of a total cost per unit lower than $400, and the consumer will be able to afford your product. If those same man-hours required to build your product cost $800, then you don't have a market; you can't sell your product, and you don't create jobs. Those laborers stay unemployed.
You have ideals which wrench the heart from the common man and hold it bleeding and still beating above his lifeless body.
Slashdot Mirror
Then it's a good thing we have a platform that lets you and a million others pitch a few dollars at a high-risk venture, instead of begging banks for the payoff.
That's all true, but they weren't exactly lauded kings. They were treated like slaves, and people have to take that out to absurd conclusions: the occasional beating, the rape, the right to just kill them for looking at you wrong, it all translates to evil men satisfying their sadistic bloodlust at all hours of the day.
It's really the kind of mistake fiction writers frequently make: the bad guy doesn't have motivations; he's just evil. He stomps on children and kicks puppies so he can gloat about how deliciously evil he is. Even Holt Fasner and Vladimir Harkonen weren't like that; Fasner only cared about himself, and Vladimir *was* a sadistic ass, but neither of them were evil just to be evil. Even Vladimir Harkonen believed what he did was creating progress, bringing order to a universe fraught with the weak and the unstructured, an untamed wilderness that needed to be paved over and modernized into a giant industrial machine where men labored for more progress; his sadism was a personality quirk, not a big red sign to show that he was evil embodied.
To give slave owners motivations is to make them human; and to make them human is to admit you have the same motivations. Slaves would be useful, and the fruit of slave labor would be desirable; and you reject slavery because it's wrong, and so you try to strangle off that recognition that it would be useful. Most people can't fathom the act of taking the correct course because the things you'd like are simply morally wrong; you're only a good person if you find those things undesirable and have no interest at all. If you simply turn away from the temptation and stand fast to what you believe is right, you're just a black-hearted devil dressed up like a white knight.
Nobody wants to admit that Adolf Hitler was the logical conclusion of every-day human thinking.
Oh, I don't know ... because worker seems to imply they had some choice in this instead of being property.
Slave labor is still labor. They're still workers, and they still need to get paid. The difference is we pay them what we want, not what they want; sometimes we don't pay them enough, and they starve, and it's expensive.
That's something a lot of people miss: there's all kinds of novels written in worlds where they reference some backwards nation or evil corporation using slave labor and thus having infinite resources because it's free. Problem is you have to feed your slaves or they die; you have to give them medical care or they don't produce as good a rate of return; and somebody has to make that shit. Slaves are farming food? That's great. You can take, say, 90% of it, and the other 10% is their pay because they need to not die or you'll need to spend 60 times their monthly budget on a new slave to replace them. Think about how useless an 8 year old is as a worker; do you want to sink all that slave labor into building a new slave, 8 or 10 or 14 years before it's even useful? Maybe you can get a better deal paying sailors for 10 months of their time sailing to another country, abducting people, and sailing back with their catch.
Slave labor wasn't as bad as people believe... if you lived long enough to be slave labor. Getting abducted from your home, dragged packed like sardines in the ship, more than half your comrades dying of disease and malnutrition, poked, prodded, sold, screamed at... if you made it, what you got was a shitty life akin to poverty in prison. People imagine slave masters constantly beating slaves while smiling wickedly with demon fangs poking out of their mouths; in reality, the actual labor wasn't too bad, just everything else about life sucked--particularly the part about being property, confined to a barn like some sort of mule, and occasionally raped.
What it was was inefficient, expensive, and nationally embarrassing. It was so embarrassing we instituted a compromise in the Union whereby half of all states would be slave states for some 50 years, after which the Federal Government was allowed to legislate slavery away. Then we got in a war with ourselves about the whole thing. The end of slavery was put on the horizon, and then we took it by force when we got there because that's what we agreed on.
People want to write revisionist history. Some folks want to downplay the facts; others want to play them up until we're looking back on gloating, horned demons. The truth is somewhere in the middle--but not right in the middle, like the "fair and balanced" advocates want you to believe. Averaging the wrong views doesn't get you the right view; it's usually off-center.
Encryption isn't a major economic factor in this context.
I'm not sure why people think these are risk free.
Because the world is fair and movies are technically accurate.
Business impact: damages brand reputation. Business profit source: Nearly 100% contingent on brand reputation, 100% reliant on technological platform.
This is why I haven't opened any video game projects yet: until I have art and some kind of video to show, it's not worth trying to get money to hire artists to create the graphics. Just a plea of "I know how to make this work, but I'm not an artist or musician" and a picture of XKCD Adventures that demonstrates nothing isn't a good way to beg for cash. Credibility isn't returning actual results; it's convincing people you can return results eventually.
It's a venture with risks; you took the gamble. When banks do this, they want a market analysis, a comprehensive business plan, timeline projections; when people play on Kickstarter, they just throw money in and ignore the disclaimer of no responsibility. I can speak the language of comprehensive project plans and market projections; most folks can't, and wouldn't understand it if you put it in front of them, so what do you want?
The lower-regulation space allows fools to part with their money, and it brings the advantage of funding people whose vision stares down the longest barrel of hell--or just picks up on things the usual suspects can't grasp. You want those advantages, you allow that sphere, and you warn the players this is the nondescript poker table where we don't check too close for credentials; you might meet a few card mechanics who can shuffle four times and put the cards in any exact order they desire, but they're mostly decent people trying to play fair. You want it both ways, you set up two tables, and let the players pick where they want to sit.
I did figure out how to solve poverty. I found politics to be a hindrance, though, so maybe not so great; people are more concerned with inflicting harm on those who don't fit their ideals than with efficiency.
Push deadlines. Achieve milestones. Progress timelines. Pick one, but whatever the terminology, no matter what nonsense systems engineering metaphors you use, none of these is a scrum masters responsibility.
Those things are the ultimate responsibility of the Scrum Master. The Scrum Master's responsibility is that of a project manager, scheduling, budgeting, managing human resources, handling stakeholder engagement, improving organizational processes, archiving project information.
You may as well say a .NET developer's responsibility isn't application architecture, and that designing applications should be left to a computer programmer.
By your definitions in a "weak-matrix" organisation, such as a software development team, a scrum master may eat the project managers lunch, though in a "balanced matrix" organisation the project manager is essentially redundant to all intents and purposes for software development as your department head, VP of engineering, whatever may essentially drive a scrum team directly and the team itself assume the remaining responsibilities.
That makes no sense.
In a weak matrix organization, a project manager would run a waterfall, iterative, or agile (scrum) project. He would manage the planning and communication, but continuously go back to functional managers, department heads, and the project sponsor with "I need Jason to do this" and "We need to schedule a meeting with our Engineers and our Finance head." On a Scrum project, he'd handle all the Scrum meetings and do all the tracking; it'd be different documentation than with a Waterfall project.
In a balanced matrix organization, the project manager would have a Project Charter listing his authority to acquire resources. Money, human resources, people he can schedule into meetings, the like. He'd do the same thing as in a weak matrix, but without running back to the sponsor to ask permission for every little thing.
A Scrum Master running a Scrum project would handle a project charter, project documents, budget projections, scheduling, a work breakdown structure, procurements, stakeholders, reporting, collection of work performance information, and so forth. Just as a C# Web application programmer would use C#.NET Web namespace classes while a Python Web application programmer would use CherryPy and Moko, a Scrum Master running a Scrum project would handle project activities by having Scrum meetings and distributing tasks among a project team who is estimating essentially just-in-time, while he would instead break out what tasks he can and schedule them in the Project Schedule Network in waterfall.
You seem to keep falling back on this idea that project managers do nothing. They do quite a lot. Scrum may have some interesting lifecycle diagrams, and they're derived from familiar industry standards. PDCA is ultimately derived from ISO 50001, which is ultimately derived from PMI, where Monitoring and Controlling is the Check and Act part, and Planning and Execution are obvious.
The fact of the matter is the larger framework Scrum masters follow is the same framework as change management and planning cycle in PMI, because it's only another tool swapped on top; Scrum does not bring its own methodologies for procurements, resource management, or larger planning. All of that stuff comes from PMI, while Scrum prescribes how to handle monitoring and controlling.
That's hilarious. I've seen multiple companies fire backup administrators for the same shit--looking to see if the backup process ran, but not if it completed. 40-hour back-up process terminates in 3 hours because you need to back up other shit? Never completes.
Just about anyone can fuck up by the numbers. We have Git and such today, so your QA manager can accurately monitor such things. There should be a change review board and a senior programmer involved, with each hotfix or other update going into its own branch; that way you can code them, test them, justify them, and merge them in independent of any review process. Much more flexible than getting authorization and giving explanation as to why you did each little thing before you can actually get on with your work.
Project management integrates pretty well with Scrum. You still carry out your risk planning, human resources acquisition, and work breakdowns; Scrum passes work packages down to the team to break out into activities and tasks, and so forth. The burden of estimation moves around a little, and the process rolls changes together more rapidly, and you continue on with all those things you usually do anyway.
It's like when you used to run old real-mode programs, and the scripts would load a program into memory, execute it to end, then load the next, halting on errors. Modern cooperative multi-tasking runs for short time slices, then checks priorities and reschedules CPU resources; programs will halt and wait for interrupts, and then regain control when IO requests are complete or new events come down.
Scrum assumes a *lot* of changes due to projects being too complex to plan in the long term; if your project is straight-forward and you can plan it with reasonable accuracy out to its completion, you should use waterfall, or at least an iterative or incremental cycle based in rolling-wave planning. Constantly interrupting your project to ask what's happening and decide if you need to rearrange work is a waste of time. If this happens a *lot*, planning for it is more efficient than assuming it's never going to happen, and so Scrum becomes faster; if it happens almost never, plan for the eventuality and execute as if everything's going to run perfectly until it doesn't.
Functional (run by department heads), matrix (weak matrix, balanced matrix, strong matrix), and projectized.
In weak-matrix organizations, the project manager is often a facilitator. Balanced-matrix departments start defining the project manager's level of authority, giving him the explicit right to requisition resources under the sponsor's authority: your VP of Engineering gives you the authority to requisition 4 engineers for 16 hours per week from the Engineering departments under him, to communicate with other departments to gather requirements and interface with stakeholders, and to spend money within a given budget, all tied to the scope of the project.
The project manager's job still remains the same in all cases: find the most efficient way to plan and execute the project. If he has no power, he has to take it back to department heads and VPs--to the sponsor--to lay out recommendations for action. That includes who to hire, what to buy, how to schedule, and so forth. The decisions are ultimately made by whoever has the vested authority to make them, which may not be the PM.
This should be obvious, considering "push deadlines" is a meaningless phrase essentially expressing "I don't know what I'm talking about".
"Certified" is used in some titles. You get "Project Management Professional" (which is a certification requiring actual experience), but also "CISCO Certified Network Engineer" or "Certified SCRUM Master" or "Microsoft Certified Professional". It's a credential thing.
When I ask them what they could have done better in hindsight after a project, you get a cornucopia of ideas. That person is hired!
Project Managers are supposed to constantly collect and file Lessons Learned as part of historical information for a project. This is continuous: work performance information, risks, project document updates, and lessons learned constantly pile up as you do anything; all of that gets filed as it comes, and the Project Close phase explicitly includes filing all Project Documents and Lessons Learned before the project is officially finished. In future projects, you refer to this stuff to make sure you've thought of everything your organization's collective experience is capable of.
Project management also involves a lot of engagement with subject matter experts in the planning phase. A lot of old-school managers like to command from on-high with their own experience; that tends to exclude a large chunk of the organization's collective expertise, since they never bother to ask anyone else what they think.
developers don't like "processes" that are forced on them from higher management, but they are willing to embrace anything that makes their job easier.
Project management tools are selected carefully by the project manager, if he's competent. You pretty much always want a requirements document and work breakdown structure; you don't always need the full gambit of human resources management, risk management, time management, scheduling, and so forth to actually manage time, risk, or whatever. It depends on the size and scope of the project. You still do all that stuff, but in a faster and less-formal way; risk management can come down to "what could possibly go wrong?" and whatever anyone can think up in a short meeting instead of a process of identifying risks, qualitatively analyzing them, quantitatively analyzing them, formalizing risk response documentation, adjusting the project plan to avoid any risks not acceptable, and so forth. ... if you're building a mainframe, you do all that long, drawn-out bullshit before you start engineering the damn thing.
If the parts of the process you select are appropriate, then your developers will have greater peace of mind. They might complain at first: the brain hates new things, and has to expend excess energy to change its habitual behaviors; but the brain also recognizes when previous routine energy expenditures go away, and any process that actually produces positive results will become critical to a person trying to cut down their workload. If you try to tack a bunch of weighty bullshit onto a small project that's going to take three people two days, they're going to recognize it for what it is: a load of unnecessary crap you should have shoveled into the garden instead.
That doesn't scale very well.
I have A3, A4, and A5 paper in the US. I prefer A5 notebooks to A4 (approximately letter).
Only good management can cure bad management.
Miscommunication. You should have told him you can make a working prototype in a day, but it will require a *lot* of trade-offs, will be of low quality, and will need following-up to shape it into something actually reasonable. If he needs a crutch to lean on for 4 or 5 days while you deliver a viable product, you can get him that; but you can't get a finished product in one day.
Communication is the responsibility of the sender.
The official role of a project manager is specifically to guide the process of completing a project. The project manager's job is called "integration", and it involves integrating scope management, time management, budget management, quality assurance, human resources management, communications management, risk management, and stakeholder management into a complete process to ensure the measurable success of a project.
CAPM license #1870244 held in good standing.
All project management has its uses. I work in a shop where I see the perfect place for waterfall, for iterative and incremental, and for scrum management techniques. I've seen projects which should have been broken into phases managed by each of these various techniques, or a combination thereof. I'm always looking at projects and whittling away the tools from some, or piling them on for others: you really do not want to use every last project management process on every project all the time.
I work with a few certified SCRUM Masters, and their shops are straight SCRUM due to the nature of their work: distributed among many developers, short deadlines, lots of maintenance, and constant changes. When you can get five new requirements in three days and your work is on-going adaptation of existing systems to new needs, traditional project management doesn't work. In most shops, you want to curb that behavior; in shops tied to politics or media production, that's the nature of the business in entire, and so you find a way to do it effectively. The CSMs are very good at their jobs.
I asked them once how that crap works at all. They went over a number of interesting points with me; one I'll never forget is the impact of people's self-expectations on their work. In a SCRUM shop, you have to keep an eye out for burn-out: people will estimate work incorrectly, promising it can be done by the end of the day; then they'll work 14 hour days trying to meet their estimates, instead of coming back the next day and admitting they can't do it that fast. Do this long enough and your whole team runs for about 8 months, everyone excited to be in such a dynamic and high-pace environment; then they all burn out, become miserable, develop severe psychiatric disturbances, and stop working entirely. The revolving door gets itself moving, and you find yourself facing high turn-over and low productivity.
You have to remind people that proper, correct, accurate estimation is one of the lessons we learn along the way. We'll estimate that we need 2 days to do something and do it in 2 hours; we'll estimate that we need 1 day to do something and do it in a week. We learn. We don't need to burn ourselves out trying to meet unrealistic deadlines we've called out for ourselves; the work either gets done or it doesn't.
That's how you manage successfully, SCRUM or not.
Evil, not dangerous.
People like this unrealistic ideal that anyone they don't like is some kind of irredeemable demon whose entire life revolves around punching babies and kicking puppies by pure reflex. The truth is people largely fall into groups, march with the group mentality, and develop fears and prejudices and all kinds of other things revolving around their sense of security--including their sense of entitlement, whereby they feel others are attacking them by not giving them what they rightly deserve.
You hear a good many vocal Americans talking about how we need to kill all the Muslims, or how anyone brown is a terrorist, or whatnot. If you really look around you, you realize Hitler was just your every-day dude; he happened to gain power over a country and its military.
There are too many news articles about morons getting their panties in a twist over a Christmas sweater or a red cup.
That's like saying if my mother had wheels, she'd be a car. The fact is, it doesn't take as much labor.
That was exactly the point.
The simple fact is, more automation means less price, at every step of the way.
Less *cost*. Labor cost is labor price times labor hours; if it costs $500 to produce a thing, you can't sell it for $450 and profit. Lowering these costs to $200 lets you sell it for less and still profit. Price comes down due to many factors, but those factors either pressure you to lower profits or to bankruptcy.
Competition assures that prices will more or less represent the value-add of labor at each stage (including design, marketing, etc) with a margin that is competitive with the competition.
Complicated.
Direct competition is fast at reducing prices; while indirect competition is less-fast. For example: Crocs, once all the rage, have become boring; now it's iPhones, and the shoes have to compete with iPhones for limited consumer money.
As well, you have capability. If you own the best coal mines, the next mining company can't dig coal out of the ground and sell it below the inflated price you're charging. You get 100% anthracite out of a 100 cubic meter block for 10 labor-hours, he gets 25% anthracite and 75% rocks and dirt out of a 100 cubic meter block for 10 labor-hours, you charge 4 times as much and he can't undercut your prices. If that guy invents a way to do it in 5 labor-hours, you'll have to bring your massive inflated prices down, at least long enough to undercut him and drive him out of business so you can buy his mine and his patents.
Inflation also tends to push prices down. You have 10% inflation, but consumers hate rising prices, and so you have to stay competitive by only raising your prices 8%.
Neither inflation nor deflation is directly linked to labor.
The buying power of a unit currency follows the total income divided by the total production. Lower the labor required for production and you increase the ability to produce, as well as allow for lower prices. Production is influenced by labor requirements, which are influenced entirely by technology--do we have assembly lines or artisans? Power tools or hand tools?--and thus labor can impact inflation or deflation. If labor efficiency--productivity--increases without an increase in per-capita income, you get deflation, as the competition pressure actually pushes prices down in an absolute sense, rather than simply in the sense of percent of total buying power.
There are a lot of interactions predicated on other interactions.
The value of a unit of currency, physical or virtual, is a function of the nation's total wealth (usually measured by GDP) and the total amount of that currency. It doesn't matter where it is or if it moves. That has no effect whatsoever on it's purchasing power.
So. The rich have $33.6 trillion sitting in accounts doing nothing. Am I to believe that they can spend all that money by January and have zero impact on America's economy and the global economy in general? No inflation as a result of massive expense? No shortages of goods? That raising the total income of America's economy from its current $12.6 trillion to $46.2 trillion will do absolutely nothing?
That is your assertion.
If you're so interested in economics, study it. You'll be amazed by how old your ideas are.
The framework is old. The ideal that all production costs are labor--that even the liberation of coal from the ground rather than its production from chemical methods is simply an available lower-labor means of producing coal--is fairly classical. Many of those specific points you claim are wrong, however, are radically different from anything I've seen. You're using the claim that money supply divided by GDP defines money's value as a way to show that my claim that total income--total money spent on goods--divided by total production--total purchased goods and services produced--indicates the purchasing power of a unit of currency is not new.
There's a big difference: I don't pretend that money that's supposedly out there somewhere doing nothing is part of the economy; you do. I also don't purport to measure GDP by measuring money; I don't really measure GDP at all, except to say in the relative sense that the same labor-hours produce more goods, and the same goods are produced by fewer labor hours, and that this is a trend which has specific implications for the economy. At current, I don't see a good way to measure productivity: the practical implications of reduced labor for goods go far beyond the relative labor costs and associated purchasing power paid for those goods. Small changes in productivity can have dramatic impacts on quality-of-life or on population growth; they can also have nearly no impact, just getting shinier toys into people's hands.
Think about the invention of cheap steel processes and the sudden ability to create affordable railroads, compared to the dramatic miniaturization of computer hardware and the ability to create smart phones: the cultural and economic impact of smart phones over cell phones is actually tiny compared to the cultural impact of railroads. Money doesn't come from railroads; it has to be printed and produced. All you'd get is lower costs, lower prices, and the same total income--the same amount of money spent on everything, and no increase in GDP even though production and productivity both increase dramatically.
By the by, how do you measure a nation's total wealth? A nation of 5 million population with the productive output of America's 320 million citizens would have *quite* a high standard of living, you know. Doesn't it seem obvious that a nation's wealth is a function of per-capita production, equal to per-capita buying power? A nation can't be wealthy if it produces only enough to feed and clothe half its citizens, no matter if that nation produces a hundred times more than the next small nation-state whose citizens all have fine silk gowns and plasma TVs.
We should NOT reduce the cost of labour, if anything labour costs should be a higher portion of the cost of a product.
That leads to poverty. It leads to making the poor poorer. It leads to starving children, homeless men, unemployment, the slow growth of jobs, the reduction of product available to the common man.
The cost of a product--the minimum price--*is* the price of labor. It takes man-hours to harvest oil, man-hours to transport steel, man-hours to refine parts, man-hours to assemble, man-hours to sell, man-hours to process credit, man-hours to manage. Make those man-hours more expensive and the product actually costs $10,000 to make, and you have to sell it for more than that to make a profit. Make those man-hours less expensive and the product only costs $2,000 to make, and can be sold for cheap.
If the consumer has $600 available to spend and you have a new product to sell for $400, you can sell that product. You'll have to employ man-hours of a total cost per unit lower than $400, and the consumer will be able to afford your product. If those same man-hours required to build your product cost $800, then you don't have a market; you can't sell your product, and you don't create jobs. Those laborers stay unemployed.
You have ideals which wrench the heart from the common man and hold it bleeding and still beating above his lifeless body.