Please either name a single example of a semi-socialist European country with 70% of income going to taxes and un-restrained immigration or withdraw your statement.
You cannot "get it for free" by definition, anywhere. What you get is the right to post in a forum where posting is permitted only to paid-license holders in good standing.
Paying a door fee at a club gives you admittance to a group of people who also paid the door fee, and omits the people who were unable or unwilling to pay. A club with no door fee cannot provide the same good.
A twenty dollar annual fee limits the creation of accounts, or at least throttles them. The account provider knows that part of the value being offered is a non-gamed system, so a fee which covers the cost of reviewing applications should make for a self-sustaining business model.
One weakness of email IDs is that the cost of creating multiple email addresses is very low. A reputation-based scheme such as an auction feedback is of limited value when it is straightforward for a person to give himself thousands of positive feedbacks.
In the past year, I've seen perhaps twenty hours of movies where I bought a ticket to see that particular movie, perhaps sixty hours of episode television where I paid a monthly subscription fee for basic cable, and perhaps eighty hours of YouTube and Google Video where I paid a monthly internet access fee.
The business model of pay-per-particular-view loses.
"Precognition" and "mind reading" are phenomena where natural selection and supernatural design make different predictions. Precognition, even a minor ability to see thirty seconds into the futre, and mind reading, even a minor ability to sense which way a predator or prey animal will jump, would have an enormous selection advantage. A theory of natural selection over long periods predict that if these were possible, they would be nearly universal. The eye evolved several times. Any motile creature of more than a few hundred million cells that lives in the daylight has eyes. So, natural selection predicts that, since precognition and mind reading are not universal, they're impossible. A supernatural designer could add precognition and mind reading to any species ("kind") at any time. Thus, evidence for precognition or mind reading, given that they are nowhere near as universal as vision, falsifies natural selection.
I spoke precisely and expected people to ask questions if they wanted to know something I left out, rather than expecting them to fill in the missing pieces by reading between the lines.
It is good to have reasonable expectations. The Scrum process provides an explicit time and place every day where developers will speak precisely of what they did yesterday, what they plan to do today, and anything that is preventing them from getting their work done. Team members do not expect people to ask questions if they want to know something, because:
Team members respond to three questions only:
What have you done since the last Daily Scrum regarding this project?
What will you do between now and the next Daily Scrum meeting regarding this project?
What impedes you from performing your work as effectively as possible?
Team members should not digress beyond answering these three questions into issues, designs, discussion of problems, or gossip.
[Non-developers] are not allowed to talk with team members after the meeting for clarification or to provide advice or instructions.
Under these constraints, it is not reasonable to expect people to ask questions. A different style of precise speech is called for, where one says not "I fixed the fungMetric library" but "I completed the work on the fungMetric library specified in task #9."
The team commits to delivering the specified functionality. Those not on the team are permitted to see what the team is doing, and the team is required to maintain a public list of its self-assigned tasks visible to all. The reason this delivery is being controlled with as an empirical process rather than a defined process is that it is unpredictable. It is natural to think that the statement "All work on the fungMetric library is finished" would allow one to predict that no more work on the fungMetric library will be done, but it is not logical to make predictions for an unpredictable process, except perhaps stochastic ones: It would be logical, but unkind, for non-team-members to use the task list as an object upon which to place bets.
In the case of software, these skills are learned as part of a degree in software engineering.
Here's the model curriculum for software engineering at Rensselaer:
CSCI-1100 Computer Science I CSCI-2300 Data Structures and Algorithms ECSE-2610 Computer Components and Operations
ECSE-4500 Probability for Engineering Applications CSCI-4210 Operating Systems ECSE-4670 Computer Communications Networks ECSE-6620 Digital Signal Processing ECSE-6770 Software Engineering I ECSE-6780 Software Engineering II CISH-6050 Software Engineering Management CISH-6010 Object Oriented Programming and Design CISH-6320 GUI Building OR CISH-6510 Web Application Design and Development ECSE-6980 Engineering Project
That's only one semester of Software Engineering Management, and it's an elective: you can skip it altogether for, say, ECSE-7100 Real-Time Programming and Applications. There's no accounting, no small-group psychology.
Texas Tech offers a masters degree in systems and engineering management. Look at it's curriculum:
IE 5311 Principles of Optimization IE 5316 Simulation Models for Operations Analysis IE 5320 Systems Theory IE 5321 Decision Theory and Management Science IE 5323 The Engineering Management Environment IE 5325 Productivity and Performance Improvement in Organizations IE 5346 Total Quality Systems
Quite a contrast!
Obviously, time spent on Productivity and Performance Improvement in Organizations is time taken away from Parsing and Grammar, and all our compilers will get slower if we don't continue to have skilled people pushing the envelope of ambiguity-free expressions. Among the consequences is that conscientious practitioners sincerely believe that they dare not speak where stakeholders can hear them, lest the blunt, ambiguity-free expression necessary for success in programming, threaten their manager's career.
We're going to be stuck at the buzzword level as long as practitioners believe that all of a development management process can be effectively summarized in a single paragraph and detailed in a three-page appendix. Scrum represents an effort to get practitioners to devote two days to the topic, which is a huge percentage increase over skimming the abstract of an article while waiting for a rebuild to complete.
It doesn't have to be, it just turns out that way. Buzz is a natural-selection winner. Ideas linked with romantic terms are more fun to talk about than ideas linked with prosaic terms in every occuupation. People who talk about "Scrum" will get more attention than people who talk about "Empiric process control." Talk becomes more buzzy as people start repeating the words prior to having mastered the concepts. People can parrot "empiric process control," too, so it becomes a buzzword, just a more pompous one.
why can't they admit that the best way to do things is how everyone else has been doing them for years?
You can't admit what you don't know. Software developers have a lot of new material to master so time for examining the practices of the more established disciplines is limited. Most developers are skilled craftspeople building what the customer wants built in accordance with the workrules laid down by the general contractor. It's the contractor - the development manager - who has primary responsibility and commensurate authority to distinguish the routine from the unrepeatable processes and control them appropriately, but what institutions offer degrees in software management?
... the 'authors' of these processes simply ripped them off of the existing accepted engineering practices, published them as their own...
That seems a grossly unfair characterization of what Ken Schwaber has done. I have not seen him pretend to be anything but a popularizer. He leads off by writing about his asking industrial process engineers to review the way software practitioners have been going about managing complex processes, and their derisory laughter upon doing so. The "Resources" sections of his books direct the curious to the "real stuff."
Software practitioners have resisted the sort of discipline - licensing, state certification, personal liability - which give teeth to best practices. Perhaps, unlike medicine or law or bridge building, software practitioners will come to find a way to follow best practice rather than fashion without licensing, state certification, and personal liability. Until that halcyon day, expect there to be lots of buzzwords.
Do I really want to spend my time thinking about whether "refine the logging policy" or "missing compiler flag" send chills down the spine of a salesman?
The salesman's can warm his spine in the sprint's deliverables, which are expressed at a level of abstraction suitable to his needs.
Most likely we would become masters of a few safe phrases and move our real communications to another channel.
You will always have another channel, because the Scrum not a work meeting. It's purpose is not to facilitate "real communications" between developers, it's purpose is to make an unpredictable process visible, inspectable, and adaptable.
That visibility includes surfacing the fact that the fungMetric system is still being worked on and that the declaration that it was fixed was premature. Management is made up of imperfect human beings working with limited information under competitive pressure. Concealing information from management usually does not improve the quality of decisions management makes.
I'm still leery of the distorting effect of reporting, though.
I would appreciate an example of how saying what you did yesterday and how you plan to spend your time today has a distorting effect. Where do politics enter "yesterday I showed Merlin how to load and unload the fungMetric library and wrote test cases for the un-queue subsystem"?
You needn't fear a question like "how does the fungMetric library have anything to do with the new agent-based billing system I thought you guys were billing" because such a question will be ruled out of order (for the meeting) by the Scrum master, someone with political skills. During a sprint, the developers decide what to work on, in what sequence, and for what reasons, in order to achieve the functionality they committed to deliver for that sprint. If an urgent new functionality appears, the sprint is formally aborted and a new one, incorporating deliverables for the new functionality is begun.
What if you can't accomplish anything meaningful to the stakeholders in 24 hours? [...] If I reported anything else, I heard, "Why the hell are you reporting something to me that I don't understand?" [...] Alternatively, how do you persuade [nontechnical stakeholders] to show up every day just to hear Bob and Mary and I say "Important stuff, but nothing you'd understand" when they ask what we've accomplished?
The Scrum process requires meaningful-to-stakeholder progress every 30 days, not every 24 hours. The 30-day period is called a "sprint." What the stakeholders consider meaningful is completely up to them, so differences in the perceived value of fixing an awkward API in a library do not arise. Sounds like magic, but it's just process. The stakeholders and the development team agree before each sprint on what the increment of value (as measured by stakeholders) will be. For example, "we will achieve end to end throughput beginning with a 50 line dummy data input file and ending with three ugly but functional developer-specified reports. We will also meet with these end-users and prepare the first draft of their report requirements."
At the daily scrum, "why the hell are you reporting something to me that I don't understand" is out of order. The manager may ask only "What did you do, what are you going to do, and are there any impediments." These questions are to be addressed in concrete terms.
Dramatic simulation
Developer 1: "I reduced the argument count in the core library API and conformed the argument order and checked it into the mainline."
Manager: "From the looks on their faces, I believe other developers may have questions about that, so please have a work meeting after this scrum. Also, yesterday you said you were going to review the API, not change it. Please use these meetings to give advanced warning. Also, after the work meeting, will you please tell me what an API is?
Developer 2: "I created a warpo input file with known-bad items, including obsoletes, wrong currencies, randomly-scattered minus signs, a few 75,000 character fields and everything else my demented brain could come up with in an hour. By the way, the system now responds to negative zipcodes by rejecting them rather than freezing."
Manager: "Could you put that last sentence in correct form? We're trying to make the process visible, not just list benefits."
Developer: "Whoops, old habits die hard. 'I fed the warpo file to the system and observed the consequences, then changed the hyphen-parser logic in the zipcode field.' Today I will investigate why the system stopped compiling in my workspace after I integrated the latest changes from the mainline, starting with Mr. Speedy's core library changes. My impediment is that the security patch applied to the database server yesterday afternoon invalidated all the test passwords, and the system administrator is swamped with update requests."
Manager: "I will contact him and try to get you bumped to the head of the queue."
Finally, the only people permitted to speak at the daily meeting are the people who have committed to delivering. Others may attend, but must remain silent. The nontechnical stakeholders can satisfy themselves that their technical people are on speaking terms and possibly assist in removing impediments.
He was just misled by the conviction that developers should be able to report concrete (i.e., understandable to a non-techie) progress every day.
What you can report every day is your actions and your intended actions. "We drove 325 miles yesterday, 150 in the wrong direction, 150 back, then 25 ahead" is an action. Reporting that as "We progressed 25 miles yesterday," though less embarrassing, hides far too much. Checklist management - "what did you accomplish" - is appropriate for "defined control processes" such as taking inventory in a warehouse or assembling several floors fu
Bing! On that we're in agreement. Now, if only we could convince The Mgmt. about that.
Here is the project. I want you to achive mastery of the arguments in Ken Schwaber's "Agile Project Management with Scrum" to the degree that you could lead (for pay) a discussion on
defined process control
empirical process control
visibility, inspection, and adaptation
The audience members' exact IQ and education are unknown, but they may be presumed to be literate and sufficiently familiar with the larger world to know that goods such as automobiles and wooden tables are manufactured.
Before we begin, though, I have three questions. How long will this take you? Is the book in your local library? What is the local library's lending policy?
Note: the publishers have enabled Amazon's Search Inside This Book feature.
Is "Daily meetings are impeding me, wasting my time, breaking my concentration, and sapping my morale, indeed my very will to live" an allowed answer?
Of course it's allowed. If a fifteen minute daily meeting where you are required to report what you did yesterday, articulate what you plan to do today, and raise anything that is standing in your way is having such a deleterious effect, it is an obvious management concern.
"Unrelated to the goals?" From management's perspective - the perspective of the people paying for all this - at the moment knowing how long it's all going to take is the goal.
If that is goal, then the task is "develop an estimation process that gives correct answers in domains which lack repeatability." This task is better known as "the halting problem," and is known to be insoluable. It is poor form to solicit payment from people whose goal you know to have been proven insoluable.
In domains lacking repeatability, "How long is it going to take" does not have a bonafide answer. There is nothing mischievous about management wanting to know. There is nothing mischievous about wanting a cure for cancer or to have a highway in a remote location, but until the last unknown is resolved, a definite answer about how long it will take is show business, not engineering.
Not necessarily. I can eyeball distances to the nearest meter much more accurately than I can estimate them to the nearest millimeter, no matter how often I make such estimations.
Perhaps after 125 attempts at estimating a distance to the nearest millimeter, you would use something to augment your bare eyeballs?
If you're admiting that the "scrum" is inadequate for complex projects, what do you recommend instead?
Do not confuse complexity with unknowability. A sulfuric acid manufacturing plant is complex, but every part of the process is known, and is known to be repeatable; and thus it is reasonable to ask how long it will take to build a proposed sulfuric acid manufacturing plant and how much it will cost.
Scrum is a development method for nontrivial software projects with many unknowns and little repeatability. Such projects cannot be estimated as if they were complex-but-known, no matter how strongly the project sponsors wish they could. The best that can be achieved is to control risk with short timeframe subprojects (no more than thirty days) and daily formal sessions (no more than 15 minutes) where the developers (seven plus or minus two) address only what they did yesterday, what they plan to do today, and any impediments. The best the requesters can do is to know that the developers are following a procedure that will surface problems early, tend to build the most useful parts of the system early, and provide frequent opportunities for continue / discontinue decisions during the process.
Hmm, so every 24 hours you can tell them "don't know how long it will be"..."still don't know"..."nope, still don't know"...
Actually, although you can tell them "don't know how long it will be" every 24 hours, you will have to arrange your own time to do so. At a Scrum meeting, the only questions that may be asked are "What did you do yesterday," "What are you going to do today," and "Is there anything that is impeding you?" The Scrum master is responsible for logging the impediments raised, and to do so in such a way that all those with an interest in the outcome can see what is holding things up the moment it is known.
"My impediment is that the task is so ill-defined that I do not know what I am supposed to be doing today" is something stakeholders should here within 24 hours of it becoming apparent.
A stakeholder who wants to ask "How long do you think the whole project will take?" can do so at a working meeting; and "an impediment to my accomplishing what I have committed to accomplish during this sprint is the surfeit of working meetings where questions unrelated to the goals are bruited about" can be stated at the next day's scrum.
Hmm, so every 24 hours you can tell them "don't know how long it will be"..."still don't know"..."nope, still don't know"...
Every 24 hours you will tell them what it was, exactly, you were doing the previous 24 hours, what you plan to do the next 24 hours, and anything you have identified that is preventing you from making progress. Are the software projects you have worked on so hapless that day after day the developers have nothing to report except "we sat in our work areas shuddering at how vague things are, daring not to put fingers to keyboard lest we make things worse"?
"Ok, so, before we get started, send out any explorers or anything, we need you to tell us exactly how long this highway will take to build."
"We will commit only to delivering that portion of the highway project that we expect to be able to accomplish in thirty days. Precise full-task estimates are applicable to known repeatable undertakings; the highway project you have described fails to qualify. A different process is required for projects with many unknowns, which will give you, the highway-desirers, the best way to manage your investment and gauge progress. If working together we cannot identify something we can accomplish in thirty days that will have sufficient value to you, then the project should not be undertaken at all."
Take an antacid pill and stomach Scrum. You'll discover that the Scrum process would require you to surface the lack of secretarial support every single day it held you back. A process can't fix a lousy manager, but it can make the manager's failings manifest.
Slashdot Mirror
Potter's stand-out feature is bravery.
Please either name a single example of a semi-socialist European country with 70% of income going to taxes and un-restrained immigration or withdraw your statement.
You cannot "get it for free" by definition, anywhere. What you get is the right to post in a forum where posting is permitted only to paid-license holders in good standing.
Paying a door fee at a club gives you admittance to a group of people who also paid the door fee, and omits the people who were unable or unwilling to pay. A club with no door fee cannot provide the same good.
Collect a fee for a posting license. Suspend the licenses of those who misbehave. Cancel the licenses of those who post inappropriately.
Something Awful uses this straightforward technique.
Does that mean "visible to all" prevents deep sleep?
A twenty dollar annual fee limits the creation of accounts, or at least throttles them. The account provider knows that part of the value being offered is a non-gamed system, so a fee which covers the cost of reviewing applications should make for a self-sustaining business model.
One weakness of email IDs is that the cost of creating multiple email addresses is very low. A reputation-based scheme such as an auction feedback is of limited value when it is straightforward for a person to give himself thousands of positive feedbacks.
In the past year, I've seen perhaps twenty hours of movies where I bought a ticket to see that particular movie, perhaps sixty hours of episode television where I paid a monthly subscription fee for basic cable, and perhaps eighty hours of YouTube and Google Video where I paid a monthly internet access fee.
The business model of pay-per-particular-view loses.
Development time is the best metric only if you are using trivial amounts of hardware.
"Precognition" and "mind reading" are phenomena where natural selection and supernatural design make different predictions. Precognition, even a minor ability to see thirty seconds into the futre, and mind reading, even a minor ability to sense which way a predator or prey animal will jump, would have an enormous selection advantage. A theory of natural selection over long periods predict that if these were possible, they would be nearly universal. The eye evolved several times. Any motile creature of more than a few hundred million cells that lives in the daylight has eyes. So, natural selection predicts that, since precognition and mind reading are not universal, they're impossible. A supernatural designer could add precognition and mind reading to any species ("kind") at any time. Thus, evidence for precognition or mind reading, given that they are nowhere near as universal as vision, falsifies natural selection.
Here's the model curriculum for software engineering at Rensselaer:
CSCI-1100 Computer Science I
CSCI-2300 Data Structures and Algorithms
ECSE-2610 Computer Components and Operations
ECSE-4500 Probability for Engineering Applications
CSCI-4210 Operating Systems
ECSE-4670 Computer Communications Networks
ECSE-6620 Digital Signal Processing
ECSE-6770 Software Engineering I
ECSE-6780 Software Engineering II
CISH-6050 Software Engineering Management
CISH-6010 Object Oriented Programming and Design
CISH-6320 GUI Building
OR CISH-6510 Web Application Design and Development
ECSE-6980 Engineering Project
That's only one semester of Software Engineering Management, and it's an elective: you can skip it altogether for, say, ECSE-7100 Real-Time Programming and Applications. There's no accounting, no small-group psychology.
Texas Tech offers a masters degree in systems and engineering management. Look at it's curriculum:
IE 5311 Principles of Optimization
IE 5316 Simulation Models for Operations Analysis
IE 5320 Systems Theory
IE 5321 Decision Theory and Management Science
IE 5323 The Engineering Management Environment
IE 5325 Productivity and Performance Improvement in Organizations
IE 5346 Total Quality Systems
Quite a contrast!
Obviously, time spent on Productivity and Performance Improvement in Organizations is time taken away from Parsing and Grammar, and all our compilers will get slower if we don't continue to have skilled people pushing the envelope of ambiguity-free expressions. Among the consequences is that conscientious practitioners sincerely believe that they dare not speak where stakeholders can hear them, lest the blunt, ambiguity-free expression necessary for success in programming, threaten their manager's career.
We're going to be stuck at the buzzword level as long as practitioners believe that all of a development management process can be effectively summarized in a single paragraph and detailed in a three-page appendix. Scrum represents an effort to get practitioners to devote two days to the topic, which is a huge percentage increase over skimming the abstract of an article while waiting for a rebuild to complete.
It doesn't have to be, it just turns out that way. Buzz is a natural-selection winner. Ideas linked with romantic terms are more fun to talk about than ideas linked with prosaic terms in every occuupation. People who talk about "Scrum" will get more attention than people who talk about "Empiric process control." Talk becomes more buzzy as people start repeating the words prior to having mastered the concepts. People can parrot "empiric process control," too, so it becomes a buzzword, just a more pompous one.
You can't admit what you don't know. Software developers have a lot of new material to master so time for examining the practices of the more established disciplines is limited. Most developers are skilled craftspeople building what the customer wants built in accordance with the workrules laid down by the general contractor. It's the contractor - the development manager - who has primary responsibility and commensurate authority to distinguish the routine from the unrepeatable processes and control them appropriately, but what institutions offer degrees in software management?
That seems a grossly unfair characterization of what Ken Schwaber has done. I have not seen him pretend to be anything but a popularizer. He leads off by writing about his asking industrial process engineers to review the way software practitioners have been going about managing complex processes, and their derisory laughter upon doing so. The "Resources" sections of his books direct the curious to the "real stuff."
Software practitioners have resisted the sort of discipline - licensing, state certification, personal liability - which give teeth to best practices. Perhaps, unlike medicine or law or bridge building, software practitioners will come to find a way to follow best practice rather than fashion without licensing, state certification, and personal liability. Until that halcyon day, expect there to be lots of buzzwords.
That visibility includes surfacing the fact that the fungMetric system is still being worked on and that the declaration that it was fixed was premature. Management is made up of imperfect human beings working with limited information under competitive pressure. Concealing information from management usually does not improve the quality of decisions management makes.
You needn't fear a question like "how does the fungMetric library have anything to do with the new agent-based billing system I thought you guys were billing" because such a question will be ruled out of order (for the meeting) by the Scrum master, someone with political skills. During a sprint, the developers decide what to work on, in what sequence, and for what reasons, in order to achieve the functionality they committed to deliver for that sprint. If an urgent new functionality appears, the sprint is formally aborted and a new one, incorporating deliverables for the new functionality is begun.
The Scrum process requires meaningful-to-stakeholder progress every 30 days, not every 24 hours. The 30-day period is called a "sprint." What the stakeholders consider meaningful is completely up to them, so differences in the perceived value of fixing an awkward API in a library do not arise. Sounds like magic, but it's just process. The stakeholders and the development team agree before each sprint on what the increment of value (as measured by stakeholders) will be. For example, "we will achieve end to end throughput beginning with a 50 line dummy data input file and ending with three ugly but functional developer-specified reports. We will also meet with these end-users and prepare the first draft of their report requirements."
At the daily scrum, "why the hell are you reporting something to me that I don't understand" is out of order. The manager may ask only "What did you do, what are you going to do, and are there any impediments." These questions are to be addressed in concrete terms.
Dramatic simulation
Developer 1: "I reduced the argument count in the core library API and conformed the argument order and checked it into the mainline."
Manager: "From the looks on their faces, I believe other developers may have questions about that, so please have a work meeting after this scrum. Also, yesterday you said you were going to review the API, not change it. Please use these meetings to give advanced warning. Also, after the work meeting, will you please tell me what an API is?
Developer 2: "I created a warpo input file with known-bad items, including obsoletes, wrong currencies, randomly-scattered minus signs, a few 75,000 character fields and everything else my demented brain could come up with in an hour. By the way, the system now responds to negative zipcodes by rejecting them rather than freezing."
Manager: "Could you put that last sentence in correct form? We're trying to make the process visible, not just list benefits."
Developer: "Whoops, old habits die hard. 'I fed the warpo file to the system and observed the consequences, then changed the hyphen-parser logic in the zipcode field.' Today I will investigate why the system stopped compiling in my workspace after I integrated the latest changes from the mainline, starting with Mr. Speedy's core library changes. My impediment is that the security patch applied to the database server yesterday afternoon invalidated all the test passwords, and the system administrator is swamped with update requests."
Manager: "I will contact him and try to get you bumped to the head of the queue."
Finally, the only people permitted to speak at the daily meeting are the people who have committed to delivering. Others may attend, but must remain silent. The nontechnical stakeholders can satisfy themselves that their technical people are on speaking terms and possibly assist in removing impediments.
What you can report every day is your actions and your intended actions. "We drove 325 miles yesterday, 150 in the wrong direction, 150 back, then 25 ahead" is an action. Reporting that as "We progressed 25 miles yesterday," though less embarrassing, hides far too much. Checklist management - "what did you accomplish" - is appropriate for "defined control processes" such as taking inventory in a warehouse or assembling several floors fu
Here is the project. I want you to achive mastery of the arguments in Ken Schwaber's "Agile Project Management with Scrum" to the degree that you could lead (for pay) a discussion on
- defined process control
- empirical process control
- visibility, inspection, and adaptation
The audience members' exact IQ and education are unknown, but they may be presumed to be literate and sufficiently familiar with the larger world to know that goods such as automobiles and wooden tables are manufactured.Before we begin, though, I have three questions. How long will this take you? Is the book in your local library? What is the local library's lending policy?
Note: the publishers have enabled Amazon's Search Inside This Book feature.
If that is goal, then the task is "develop an estimation process that gives correct answers in domains which lack repeatability." This task is better known as "the halting problem," and is known to be insoluable. It is poor form to solicit payment from people whose goal you know to have been proven insoluable.
In domains lacking repeatability, "How long is it going to take" does not have a bonafide answer. There is nothing mischievous about management wanting to know. There is nothing mischievous about wanting a cure for cancer or to have a highway in a remote location, but until the last unknown is resolved, a definite answer about how long it will take is show business, not engineering.
Perhaps after 125 attempts at estimating a distance to the nearest millimeter, you would use something to augment your bare eyeballs?
Do not confuse complexity with unknowability. A sulfuric acid manufacturing plant is complex, but every part of the process is known, and is known to be repeatable; and thus it is reasonable to ask how long it will take to build a proposed sulfuric acid manufacturing plant and how much it will cost.
Scrum is a development method for nontrivial software projects with many unknowns and little repeatability. Such projects cannot be estimated as if they were complex-but-known, no matter how strongly the project sponsors wish they could. The best that can be achieved is to control risk with short timeframe subprojects (no more than thirty days) and daily formal sessions (no more than 15 minutes) where the developers (seven plus or minus two) address only what they did yesterday, what they plan to do today, and any impediments. The best the requesters can do is to know that the developers are following a procedure that will surface problems early, tend to build the most useful parts of the system early, and provide frequent opportunities for continue / discontinue decisions during the process.
Actually, although you can tell them "don't know how long it will be" every 24 hours, you will have to arrange your own time to do so. At a Scrum meeting, the only questions that may be asked are "What did you do yesterday," "What are you going to do today," and "Is there anything that is impeding you?" The Scrum master is responsible for logging the impediments raised, and to do so in such a way that all those with an interest in the outcome can see what is holding things up the moment it is known.
"My impediment is that the task is so ill-defined that I do not know what I am supposed to be doing today" is something stakeholders should here within 24 hours of it becoming apparent.
A stakeholder who wants to ask "How long do you think the whole project will take?" can do so at a working meeting; and "an impediment to my accomplishing what I have committed to accomplish during this sprint is the surfeit of working meetings where questions unrelated to the goals are bruited about" can be stated at the next day's scrum.
Every 24 hours you will tell them what it was, exactly, you were doing the previous 24 hours, what you plan to do the next 24 hours, and anything you have identified that is preventing you from making progress. Are the software projects you have worked on so hapless that day after day the developers have nothing to report except "we sat in our work areas shuddering at how vague things are, daring not to put fingers to keyboard lest we make things worse"?
"We will commit only to delivering that portion of the highway project that we expect to be able to accomplish in thirty days. Precise full-task estimates are applicable to known repeatable undertakings; the highway project you have described fails to qualify. A different process is required for projects with many unknowns, which will give you, the highway-desirers, the best way to manage your investment and gauge progress. If working together we cannot identify something we can accomplish in thirty days that will have sufficient value to you, then the project should not be undertaken at all."
Take an antacid pill and stomach Scrum. You'll discover that the Scrum process would require you to surface the lack of secretarial support every single day it held you back. A process can't fix a lousy manager, but it can make the manager's failings manifest.