Mixing
Does Scrum create additional overhead for projects where requirements don't change?
I'm reading the Scrum - A Pocket Guide by Gunther Verheyen and it says:
The Chaos report of 2011 by the Standish Group marks a turning point. Extensive research was done in comparing traditional projects with projects that used Agile methods. The report shows that an Agile approach to software development results in a much higher yield, even against the old expectations that software must be delivered on time, on budget and with all the promised scope. The report shows that the Agile projects were three times as successful, and there were three times fewer failed Agile projects compared with traditional projects.
So I have an argument with one of my colleagues who says that for some projects (like medicine/military where the requirements don't change), Agile (and, particularly, Scrum) is overhead with all of the meetings etc and it's more logical to use waterfall, for example.
My point of view is that Scrum should be adopted in such projects because it will make the process more transparent and increase the productivity of a team. I also think that Scrum events won't take much time if it's not needed because we don't need to sit the whole 8 hours in Sprint Planning for 1 month sprint. We can spare 5 minutes just to be sure that we are all on the same page and start working.
So, will Scrum create additional overhead for a project where requirements don't change?
agile project-management scrum methodology
edited Jan 22 at 14:19
Thomas Owens♦
60.2k13146232
asked Jan 22 at 10:34
Artem MalchenkoArtem Malchenko
24626
|
show 15 more comments
I'm reading the Scrum - A Pocket Guide by Gunther Verheyen and it says:
The Chaos report of 2011 by the Standish Group marks a turning point. Extensive research was done in comparing traditional projects with projects that used Agile methods. The report shows that an Agile approach to software development results in a much higher yield, even against the old expectations that software must be delivered on time, on budget and with all the promised scope. The report shows that the Agile projects were three times as successful, and there were three times fewer failed Agile projects compared with traditional projects.
So I have an argument with one of my colleagues who says that for some projects (like medicine/military where the requirements don't change), Agile (and, particularly, Scrum) is overhead with all of the meetings etc and it's more logical to use waterfall, for example.
My point of view is that Scrum should be adopted in such projects because it will make the process more transparent and increase the productivity of a team. I also think that Scrum events won't take much time if it's not needed because we don't need to sit the whole 8 hours in Sprint Planning for 1 month sprint. We can spare 5 minutes just to be sure that we are all on the same page and start working.
So, will Scrum create additional overhead for a project where requirements don't change?
agile project-management scrum methodology
edited Jan 22 at 14:19
Thomas Owens♦
60.2k13146232
asked Jan 22 at 10:34
Artem MalchenkoArtem Malchenko
24626
50
Military project requirements change constantly - which is how they end up massively over budget and delayed
– HorusKol
Jan 22 at 10:44
26
The only projects where requirements don't change are cancelled or terminated projects. It might be that in some industries the cycle from idea to deployed product is longer than in other industries, but that doesn't change the fact that ideas/requirements change constantly.
– Bart van Ingen Schenau
Jan 22 at 11:39
24
I've been involved with military projects where the requirements "didn't change" because they were so vague as to be useless. For example, the performance requirements for a fighter aircraft engine: "The engine will perform satisfactorily over the full flight envelope of the aircraft". That one sentence was the entire spec. The reply to a request for more details was "Well, we don't know what the full flight envelope will be until we have test flown the prototype aircraft". And no, I'm not making this stuff up.
– alephzero
Jan 22 at 14:37
7
The CHAOS reports have issues - see, for example few.vu.nl/~x/chaos/chaos.pdf - and while, on balance, research into the effectiveness of agile and Scrum methods shows a positive effect, there are systematic problems with the comparator groups since "non-agile" is less well defined than what it is being compared to.
– Jack Aidley
Jan 22 at 16:03
8
@senseiwu the idea that an engineer is "forced to explain their work every day to a non tech" suggests that you've never done anything resembling what the Scrum Guide talks about. Which, sadly, is pretty common among people who claim to have done Scrum.
– Erik
Jan 23 at 10:07
|
show 15 more comments
I'm reading the Scrum - A Pocket Guide by Gunther Verheyen and it says:
The Chaos report of 2011 by the Standish Group marks a turning point. Extensive research was done in comparing traditional projects with projects that used Agile methods. The report shows that an Agile approach to software development results in a much higher yield, even against the old expectations that software must be delivered on time, on budget and with all the promised scope. The report shows that the Agile projects were three times as successful, and there were three times fewer failed Agile projects compared with traditional projects.
So I have an argument with one of my colleagues who says that for some projects (like medicine/military where the requirements don't change), Agile (and, particularly, Scrum) is overhead with all of the meetings etc and it's more logical to use waterfall, for example.
My point of view is that Scrum should be adopted in such projects because it will make the process more transparent and increase the productivity of a team. I also think that Scrum events won't take much time if it's not needed because we don't need to sit the whole 8 hours in Sprint Planning for 1 month sprint. We can spare 5 minutes just to be sure that we are all on the same page and start working.
So, will Scrum create additional overhead for a project where requirements don't change?
agile project-management scrum methodology
edited Jan 22 at 14:19
Thomas Owens♦
60.2k13146232
asked Jan 22 at 10:34
Artem MalchenkoArtem Malchenko
24626
I'm reading the Scrum - A Pocket Guide by Gunther Verheyen and it says:
The Chaos report of 2011 by the Standish Group marks a turning point. Extensive research was done in comparing traditional projects with projects that used Agile methods. The report shows that an Agile approach to software development results in a much higher yield, even against the old expectations that software must be delivered on time, on budget and with all the promised scope. The report shows that the Agile projects were three times as successful, and there were three times fewer failed Agile projects compared with traditional projects.
So I have an argument with one of my colleagues who says that for some projects (like medicine/military where the requirements don't change), Agile (and, particularly, Scrum) is overhead with all of the meetings etc and it's more logical to use waterfall, for example.
My point of view is that Scrum should be adopted in such projects because it will make the process more transparent and increase the productivity of a team. I also think that Scrum events won't take much time if it's not needed because we don't need to sit the whole 8 hours in Sprint Planning for 1 month sprint. We can spare 5 minutes just to be sure that we are all on the same page and start working.
So, will Scrum create additional overhead for a project where requirements don't change?
agile project-management scrum methodology
agile project-management scrum methodology
edited Jan 22 at 14:19
Thomas Owens♦
60.2k13146232
asked Jan 22 at 10:34
Artem MalchenkoArtem Malchenko
24626
edited Jan 22 at 14:19
Thomas Owens♦
60.2k13146232
asked Jan 22 at 10:34
Artem MalchenkoArtem Malchenko
24626
edited Jan 22 at 14:19
Thomas Owens♦
60.2k13146232
edited Jan 22 at 14:19
Thomas Owens♦
60.2k13146232
edited Jan 22 at 14:19
Thomas Owens♦
60.2k13146232
60.2k13146232
asked Jan 22 at 10:34
Artem MalchenkoArtem Malchenko
24626
asked Jan 22 at 10:34
Artem MalchenkoArtem Malchenko
24626
asked Jan 22 at 10:34
Artem MalchenkoArtem Malchenko
24626
24626
50
Military project requirements change constantly - which is how they end up massively over budget and delayed
– HorusKol
Jan 22 at 10:44
26
The only projects where requirements don't change are cancelled or terminated projects. It might be that in some industries the cycle from idea to deployed product is longer than in other industries, but that doesn't change the fact that ideas/requirements change constantly.
– Bart van Ingen Schenau
Jan 22 at 11:39
24
I've been involved with military projects where the requirements "didn't change" because they were so vague as to be useless. For example, the performance requirements for a fighter aircraft engine: "The engine will perform satisfactorily over the full flight envelope of the aircraft". That one sentence was the entire spec. The reply to a request for more details was "Well, we don't know what the full flight envelope will be until we have test flown the prototype aircraft". And no, I'm not making this stuff up.
– alephzero
Jan 22 at 14:37
7
The CHAOS reports have issues - see, for example few.vu.nl/~x/chaos/chaos.pdf - and while, on balance, research into the effectiveness of agile and Scrum methods shows a positive effect, there are systematic problems with the comparator groups since "non-agile" is less well defined than what it is being compared to.
– Jack Aidley
Jan 22 at 16:03
8
@senseiwu the idea that an engineer is "forced to explain their work every day to a non tech" suggests that you've never done anything resembling what the Scrum Guide talks about. Which, sadly, is pretty common among people who claim to have done Scrum.
– Erik
Jan 23 at 10:07
|
show 15 more comments
50
Military project requirements change constantly - which is how they end up massively over budget and delayed
– HorusKol
Jan 22 at 10:44
26
The only projects where requirements don't change are cancelled or terminated projects. It might be that in some industries the cycle from idea to deployed product is longer than in other industries, but that doesn't change the fact that ideas/requirements change constantly.
– Bart van Ingen Schenau
Jan 22 at 11:39
24
I've been involved with military projects where the requirements "didn't change" because they were so vague as to be useless. For example, the performance requirements for a fighter aircraft engine: "The engine will perform satisfactorily over the full flight envelope of the aircraft". That one sentence was the entire spec. The reply to a request for more details was "Well, we don't know what the full flight envelope will be until we have test flown the prototype aircraft". And no, I'm not making this stuff up.
– alephzero
Jan 22 at 14:37
7
The CHAOS reports have issues - see, for example few.vu.nl/~x/chaos/chaos.pdf - and while, on balance, research into the effectiveness of agile and Scrum methods shows a positive effect, there are systematic problems with the comparator groups since "non-agile" is less well defined than what it is being compared to.
– Jack Aidley
Jan 22 at 16:03
8
@senseiwu the idea that an engineer is "forced to explain their work every day to a non tech" suggests that you've never done anything resembling what the Scrum Guide talks about. Which, sadly, is pretty common among people who claim to have done Scrum.
– Erik
Jan 23 at 10:07
50
50
Military project requirements change constantly - which is how they end up massively over budget and delayed
– HorusKol
Jan 22 at 10:44
Military project requirements change constantly - which is how they end up massively over budget and delayed
– HorusKol
Jan 22 at 10:44
26
26
The only projects where requirements don't change are cancelled or terminated projects. It might be that in some industries the cycle from idea to deployed product is longer than in other industries, but that doesn't change the fact that ideas/requirements change constantly.
– Bart van Ingen Schenau
Jan 22 at 11:39
The only projects where requirements don't change are cancelled or terminated projects. It might be that in some industries the cycle from idea to deployed product is longer than in other industries, but that doesn't change the fact that ideas/requirements change constantly.
– Bart van Ingen Schenau
Jan 22 at 11:39
24
24
I've been involved with military projects where the requirements "didn't change" because they were so vague as to be useless. For example, the performance requirements for a fighter aircraft engine: "The engine will perform satisfactorily over the full flight envelope of the aircraft". That one sentence was the entire spec. The reply to a request for more details was "Well, we don't know what the full flight envelope will be until we have test flown the prototype aircraft". And no, I'm not making this stuff up.
– alephzero
Jan 22 at 14:37
I've been involved with military projects where the requirements "didn't change" because they were so vague as to be useless. For example, the performance requirements for a fighter aircraft engine: "The engine will perform satisfactorily over the full flight envelope of the aircraft". That one sentence was the entire spec. The reply to a request for more details was "Well, we don't know what the full flight envelope will be until we have test flown the prototype aircraft". And no, I'm not making this stuff up.
– alephzero
Jan 22 at 14:37
7
7
The CHAOS reports have issues - see, for example few.vu.nl/~x/chaos/chaos.pdf - and while, on balance, research into the effectiveness of agile and Scrum methods shows a positive effect, there are systematic problems with the comparator groups since "non-agile" is less well defined than what it is being compared to.
– Jack Aidley
Jan 22 at 16:03
The CHAOS reports have issues - see, for example few.vu.nl/~x/chaos/chaos.pdf - and while, on balance, research into the effectiveness of agile and Scrum methods shows a positive effect, there are systematic problems with the comparator groups since "non-agile" is less well defined than what it is being compared to.
– Jack Aidley
Jan 22 at 16:03
8
8
@senseiwu the idea that an engineer is "forced to explain their work every day to a non tech" suggests that you've never done anything resembling what the Scrum Guide talks about. Which, sadly, is pretty common among people who claim to have done Scrum.
– Erik
Jan 23 at 10:07
@senseiwu the idea that an engineer is "forced to explain their work every day to a non tech" suggests that you've never done anything resembling what the Scrum Guide talks about. Which, sadly, is pretty common among people who claim to have done Scrum.
– Erik
Jan 23 at 10:07
|
show 15 more comments
6 Answers
6
active
oldest
votes
I believe that it's a faulty assumption to say that there are projects where the requirements don't change. Having worked in both the defense industry and the pharmaceutical industry making software, I can tell you that once software ends up in the hands of subject matter experts (either internal or external), there is feedback. Sometimes, this feedback is on the way the requirement was satisfied and in other cases it's actually on the requirements themselves being wrong or incomplete.
Agility is about reducing that feedback cycle and getting working software into someone's hands faster, getting that feedback, and deciding what the next step should be to make sure that what is delivered adds value when the customer decides to accept the software. Even in realms like embedded systems with custom hardware (like you may find in domains like aerospace, automotive, or medical devices), delivering thin slices of functionality quickly to integrate and prototype with can help make sure that the software and hardware system is going to work as intended and in a way that will help the end user.
The reduction in the length of the feedback cycle is a huge factor in risk reduction. From the project management perspective, if you fund a project for 2-4 weeks and get regular visibility into progress, that assures you that you are on track. By being able to deliver thin slices of functionality, you incrementally work toward the target state and can begin to forecast when you will get there. If time becomes a constraint, you can descope the lower value functions since the work done first should either be a high value function or an enabler for a high value function. At any point, you can decide if it's worth continuing to fund the effort or go in a different direction and stop a project before it's too late.
answered Jan 22 at 10:52
Thomas Owens♦Thomas Owens
60.2k13146232
1
Further reading about the impact of feedback cycle lengths blog.codinghorror.com/boyds-law-of-iteration
– StuperUser
Jan 22 at 16:40
Sorry to be the (one) randon downvoter, but to me this answer doesn't actually answer the question. It's just a statement of how you think things ought to be.
– Simon B
Jan 23 at 12:42
add a comment |
The very short answer is that yes, Scrum is by design a more expensive approach, but if you're calling it a project, it almost certainly doesn't matter and in the end will almost certainly always result in a better ROI.
The more complete answer is this:
Generally speaking there are three forms of process control: Defined Process Control, Statistical Process Control, and Emperical Process Control. Defined Process Control is by far the cheapest. This is possible with frequently-repeatable work has been refined over time to find the "best" way to do the work. CI/CD in software development falls into this category. You don't want variation in your build process so you standardize the process, adjust until you're happy with it, then automate it. That automated process is obviously far less expensive to run through than manually fighting through a deploy.
Statistical Process Control is the next least expensive, but it accounts for variations in a known process. Medical procedures that go according to plan fall into this category. I don't want to reinvent a bypass surgery each time. I follow the basic process and adjust for variation. This has a relatively low cognitive load and a fairly high rate of success.
Next is Empirical Process Control, which is by far the most expensive because you have to discover the process as you go. Learning is incredibly high, but at the price of productivity and efficiency. However, nearly all project work requires this because few project have been done before. There are, of course, exceptions. Setting up a large active directory environment is more Statistical because you work from some tried-and-true instructions that you deviate from slightly as circumstances require. But unless you're project is to do the exact work that has been done before, it almost certainly requires Emperical Process Control.
To bring it back to Scrum, Scrum is designed to solve problems with Emperical Process control. Therefor, yes, it has more overhead than other approaches. However, since most projects require this approach, it's a moot argument.
To the counterpoint about medicine and military projects, it sounds like flawed logic. If you are fulfilling an order for 500 airplanes, then yes, you are recreating something exactly and Scrum is probably not beneficial. If you are building a new plane and your requirements never change, I wouldn't fly that plane.
answered Jan 22 at 11:47
DanielDaniel
1,274310
add a comment |
Sure, if you have a project where you have crystal clear requirements up front, then you could waterfallishly dump them in front of developers and come back two years later to meet the software of your dreams.
But the vast majority of software projects is not like this.
Usually, the customer doesn't know what they need. They are unable to provide complete and specific requirements. Iterative approaches help here: build a small thing, then ask the customer for feedback. Yes, this "wastes" time on demos and planning the next iteration. But building the wrong thing for one sprint and then quickly correcting the requirements is a lot better than building the wrong thing for the entirety of the project. I.e. while requirements up front may allow for more efficient development, iterative approaches will be more effective.
Developers must understand the requirements correctly if they are to build useful software. What is a good way to discover misunderstandings before it is too late? Again, iterative approaches can help. But it is also important that developers themselves collaborate with the customer instead of only getting filtered information through a requirements document author.
Finally, the world doesn't stand still during the project. External systems change, priorities change, people change. Pretending that the requirements of a software project won't change is a bad idea, except for short projects.
All of these process-level benefits miss the big day to day advantage of agile approaches: if done correctly, agile makes everyone happier. The biggest one of these is that agile techniques focus on providing real value over short time frames. That brings visibility into the development process, gives stakeholders a reasonable level of control over the project, and is much more motivating than working towards a distant goal. Related to this is the idea that agile teams will be largely self-organizing. Feeling in control over their day to day work makes people feel valued, and therefore more likely to give their best.
Your colleague is not wrong that waterfall style projects can have their place. And you are not wrong that some agile-ish practices can be time-wasting rituals. But it is completely foolish to ignore the benefits of agile and iterative approaches, especially better risk management and respect for individuals. These are things you want in every project. If necessary a team can try to implement some of this internally, but processes work better when everyone is on board.
answered Jan 22 at 11:42
amonamon
88.5k21168258
add a comment |
I think this may well be paraphrasing what @Cort Ammon is saying, but here is my take:
The external requirements (describing the "deliverables") aren't the only requirements in a project. Even if the external requirements don't change, the "internal" requirements will change, or need to be allowed to change, as you work. Developers will discover obstacles or problems with an approach, and this will affect the work of the other people in the team. A daily stand-up will keep everyone up to date with these internal changes.
answered Jan 23 at 0:47
BeejaminBeejamin
1193
1
yes I have worked on waterfall projects where not a single requirement changed during build, but one person spent almost all day changing the project plan to allow for sickness, holidays, unforeseen technical problems.
– WendyG
Jan 23 at 10:05
add a comment |
Consider that:
Even with fixed functional requirements you need to traslate them into technical requirements. And this may be better done by iterations. You may discover better ways to solve the problem at the middle of the project.
Some requierements may be too generic or ambiguous: "be easy to use", "be secure". It is hard to analyze he security or usability of a system that it is not finished. Some may have hidden implications or may not be well understood.
Some requirements may be improved. Responding in 200ms may be good but 100 may be better. You may target the best possible result but sacrifice it if needed during the project.
You may discover some hidden requierement that won't be written on the contract but may change the project from failure to success. Even if you deliver the project the client may not be happy. May be they even need to change the contract to add (and charge) for new features that you may design in the project cheaper in the early stages.
You may discover that you can't fullfill your requirements in the given time. Is not as if software projects never got late. So delivering the best value will allow you to renegociate what features to drop.
Delivering something sooner will help integration and will show that this project can deliver results.
answered Jan 23 at 10:05
BorjabBorjab
826515
add a comment |
One can make the argument that if all requirements are laid out perfectly, then there exists a top down approach which achieves those requirements as fast as possible. However, if these are good requirements, they tell you what to make, not how to make it. If they tell you how to make it, I'd choose to call it "work instructions" instead of "requirements" and we'd be discussing a different sort of problem.
Accordingly, there is always a process of developing the "how" which is internal to the company or team implementing the requirements. Empirically speaking, we rely strongly on a hierarchical approach where a team of designers design the high level system to meet those requirements, and then use the specifics of that high level system to provide "requirements" to smaller teams which flesh our the details.
In the waterfall process, this can be seen in the one-way arrow between design and implementation. However, these requirements are not set in stone, like the customer provided ones were. These are internally defined and have room for the iterative process. In practice, we find designers either put considerable margin in the process to account for this lack of iteration or seek an iterative process.
SCRUM, and many other related agile methods, simply provide a rigorous framework within which to do this iterative process. A trademark of the agile approaches is that they consider optimizing this iterative pattern to be the core of the process, rather than focusing on the outer layer of hard requirements. As others have mentioned, actual fixed requirements are rare, but even in their presence, SCRUM uses the iterative approach as a methodology to control the contractual approach it fits inside of.
Whether it succeeds at doing this is a matter of open debate. Others have provided many metrics to this end. I will merely note that it is up to the strength of the leadership to make sure the iterations which occur below them dovetail correctly into the contractual system above. This is true with any approach to development, but it is more visible in agile approaches because we have been raised to assume the more top down approach is "normal" and trained leaders as such.
answered Jan 22 at 18:32
Cort AmmonCort Ammon
9,68131830
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "131"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: false,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsoftwareengineering.stackexchange.com%2fquestions%2f385926%2fdoes-scrum-create-additional-overhead-for-projects-where-requirements-dont-chan%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
StackExchange.ready(function () {
$("#show-editor-button input, #show-editor-button button").click(function () {
var showEditor = function() {
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
};
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True') {
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup({
url: '/post/self-answer-popup',
loaded: function(popup) {
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
}
})
} else{
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true) {
showEditor();
}
}
});
});
6 Answers
6
active
oldest
votes
6 Answers
6
active
oldest
votes
active
oldest
votes
active
oldest
votes
I believe that it's a faulty assumption to say that there are projects where the requirements don't change. Having worked in both the defense industry and the pharmaceutical industry making software, I can tell you that once software ends up in the hands of subject matter experts (either internal or external), there is feedback. Sometimes, this feedback is on the way the requirement was satisfied and in other cases it's actually on the requirements themselves being wrong or incomplete.
Agility is about reducing that feedback cycle and getting working software into someone's hands faster, getting that feedback, and deciding what the next step should be to make sure that what is delivered adds value when the customer decides to accept the software. Even in realms like embedded systems with custom hardware (like you may find in domains like aerospace, automotive, or medical devices), delivering thin slices of functionality quickly to integrate and prototype with can help make sure that the software and hardware system is going to work as intended and in a way that will help the end user.
The reduction in the length of the feedback cycle is a huge factor in risk reduction. From the project management perspective, if you fund a project for 2-4 weeks and get regular visibility into progress, that assures you that you are on track. By being able to deliver thin slices of functionality, you incrementally work toward the target state and can begin to forecast when you will get there. If time becomes a constraint, you can descope the lower value functions since the work done first should either be a high value function or an enabler for a high value function. At any point, you can decide if it's worth continuing to fund the effort or go in a different direction and stop a project before it's too late.
answered Jan 22 at 10:52
Thomas Owens♦Thomas Owens
60.2k13146232
1
Further reading about the impact of feedback cycle lengths blog.codinghorror.com/boyds-law-of-iteration
– StuperUser
Jan 22 at 16:40
Sorry to be the (one) randon downvoter, but to me this answer doesn't actually answer the question. It's just a statement of how you think things ought to be.
– Simon B
Jan 23 at 12:42
add a comment |
I believe that it's a faulty assumption to say that there are projects where the requirements don't change. Having worked in both the defense industry and the pharmaceutical industry making software, I can tell you that once software ends up in the hands of subject matter experts (either internal or external), there is feedback. Sometimes, this feedback is on the way the requirement was satisfied and in other cases it's actually on the requirements themselves being wrong or incomplete.
Agility is about reducing that feedback cycle and getting working software into someone's hands faster, getting that feedback, and deciding what the next step should be to make sure that what is delivered adds value when the customer decides to accept the software. Even in realms like embedded systems with custom hardware (like you may find in domains like aerospace, automotive, or medical devices), delivering thin slices of functionality quickly to integrate and prototype with can help make sure that the software and hardware system is going to work as intended and in a way that will help the end user.
The reduction in the length of the feedback cycle is a huge factor in risk reduction. From the project management perspective, if you fund a project for 2-4 weeks and get regular visibility into progress, that assures you that you are on track. By being able to deliver thin slices of functionality, you incrementally work toward the target state and can begin to forecast when you will get there. If time becomes a constraint, you can descope the lower value functions since the work done first should either be a high value function or an enabler for a high value function. At any point, you can decide if it's worth continuing to fund the effort or go in a different direction and stop a project before it's too late.
answered Jan 22 at 10:52
Thomas Owens♦Thomas Owens
60.2k13146232
1
Further reading about the impact of feedback cycle lengths blog.codinghorror.com/boyds-law-of-iteration
– StuperUser
Jan 22 at 16:40
Sorry to be the (one) randon downvoter, but to me this answer doesn't actually answer the question. It's just a statement of how you think things ought to be.
– Simon B
Jan 23 at 12:42
add a comment |
I believe that it's a faulty assumption to say that there are projects where the requirements don't change. Having worked in both the defense industry and the pharmaceutical industry making software, I can tell you that once software ends up in the hands of subject matter experts (either internal or external), there is feedback. Sometimes, this feedback is on the way the requirement was satisfied and in other cases it's actually on the requirements themselves being wrong or incomplete.
Agility is about reducing that feedback cycle and getting working software into someone's hands faster, getting that feedback, and deciding what the next step should be to make sure that what is delivered adds value when the customer decides to accept the software. Even in realms like embedded systems with custom hardware (like you may find in domains like aerospace, automotive, or medical devices), delivering thin slices of functionality quickly to integrate and prototype with can help make sure that the software and hardware system is going to work as intended and in a way that will help the end user.
The reduction in the length of the feedback cycle is a huge factor in risk reduction. From the project management perspective, if you fund a project for 2-4 weeks and get regular visibility into progress, that assures you that you are on track. By being able to deliver thin slices of functionality, you incrementally work toward the target state and can begin to forecast when you will get there. If time becomes a constraint, you can descope the lower value functions since the work done first should either be a high value function or an enabler for a high value function. At any point, you can decide if it's worth continuing to fund the effort or go in a different direction and stop a project before it's too late.
answered Jan 22 at 10:52
Thomas Owens♦Thomas Owens
60.2k13146232
I believe that it's a faulty assumption to say that there are projects where the requirements don't change. Having worked in both the defense industry and the pharmaceutical industry making software, I can tell you that once software ends up in the hands of subject matter experts (either internal or external), there is feedback. Sometimes, this feedback is on the way the requirement was satisfied and in other cases it's actually on the requirements themselves being wrong or incomplete.
Agility is about reducing that feedback cycle and getting working software into someone's hands faster, getting that feedback, and deciding what the next step should be to make sure that what is delivered adds value when the customer decides to accept the software. Even in realms like embedded systems with custom hardware (like you may find in domains like aerospace, automotive, or medical devices), delivering thin slices of functionality quickly to integrate and prototype with can help make sure that the software and hardware system is going to work as intended and in a way that will help the end user.
The reduction in the length of the feedback cycle is a huge factor in risk reduction. From the project management perspective, if you fund a project for 2-4 weeks and get regular visibility into progress, that assures you that you are on track. By being able to deliver thin slices of functionality, you incrementally work toward the target state and can begin to forecast when you will get there. If time becomes a constraint, you can descope the lower value functions since the work done first should either be a high value function or an enabler for a high value function. At any point, you can decide if it's worth continuing to fund the effort or go in a different direction and stop a project before it's too late.
answered Jan 22 at 10:52
Thomas Owens♦Thomas Owens
60.2k13146232
answered Jan 22 at 10:52
Thomas Owens♦Thomas Owens
60.2k13146232
answered Jan 22 at 10:52
Thomas Owens♦Thomas Owens
60.2k13146232
answered Jan 22 at 10:52
Thomas Owens♦Thomas Owens
60.2k13146232
60.2k13146232
1
Further reading about the impact of feedback cycle lengths blog.codinghorror.com/boyds-law-of-iteration
– StuperUser
Jan 22 at 16:40
Sorry to be the (one) randon downvoter, but to me this answer doesn't actually answer the question. It's just a statement of how you think things ought to be.
– Simon B
Jan 23 at 12:42
add a comment |
1
Further reading about the impact of feedback cycle lengths blog.codinghorror.com/boyds-law-of-iteration
– StuperUser
Jan 22 at 16:40
Sorry to be the (one) randon downvoter, but to me this answer doesn't actually answer the question. It's just a statement of how you think things ought to be.
– Simon B
Jan 23 at 12:42
1
1
Further reading about the impact of feedback cycle lengths blog.codinghorror.com/boyds-law-of-iteration
– StuperUser
Jan 22 at 16:40
Further reading about the impact of feedback cycle lengths blog.codinghorror.com/boyds-law-of-iteration
– StuperUser
Jan 22 at 16:40
Sorry to be the (one) randon downvoter, but to me this answer doesn't actually answer the question. It's just a statement of how you think things ought to be.
– Simon B
Jan 23 at 12:42
Sorry to be the (one) randon downvoter, but to me this answer doesn't actually answer the question. It's just a statement of how you think things ought to be.
– Simon B
Jan 23 at 12:42
add a comment |
The very short answer is that yes, Scrum is by design a more expensive approach, but if you're calling it a project, it almost certainly doesn't matter and in the end will almost certainly always result in a better ROI.
The more complete answer is this:
Generally speaking there are three forms of process control: Defined Process Control, Statistical Process Control, and Emperical Process Control. Defined Process Control is by far the cheapest. This is possible with frequently-repeatable work has been refined over time to find the "best" way to do the work. CI/CD in software development falls into this category. You don't want variation in your build process so you standardize the process, adjust until you're happy with it, then automate it. That automated process is obviously far less expensive to run through than manually fighting through a deploy.
Statistical Process Control is the next least expensive, but it accounts for variations in a known process. Medical procedures that go according to plan fall into this category. I don't want to reinvent a bypass surgery each time. I follow the basic process and adjust for variation. This has a relatively low cognitive load and a fairly high rate of success.
Next is Empirical Process Control, which is by far the most expensive because you have to discover the process as you go. Learning is incredibly high, but at the price of productivity and efficiency. However, nearly all project work requires this because few project have been done before. There are, of course, exceptions. Setting up a large active directory environment is more Statistical because you work from some tried-and-true instructions that you deviate from slightly as circumstances require. But unless you're project is to do the exact work that has been done before, it almost certainly requires Emperical Process Control.
To bring it back to Scrum, Scrum is designed to solve problems with Emperical Process control. Therefor, yes, it has more overhead than other approaches. However, since most projects require this approach, it's a moot argument.
To the counterpoint about medicine and military projects, it sounds like flawed logic. If you are fulfilling an order for 500 airplanes, then yes, you are recreating something exactly and Scrum is probably not beneficial. If you are building a new plane and your requirements never change, I wouldn't fly that plane.
answered Jan 22 at 11:47
DanielDaniel
1,274310
add a comment |
The very short answer is that yes, Scrum is by design a more expensive approach, but if you're calling it a project, it almost certainly doesn't matter and in the end will almost certainly always result in a better ROI.
The more complete answer is this:
Generally speaking there are three forms of process control: Defined Process Control, Statistical Process Control, and Emperical Process Control. Defined Process Control is by far the cheapest. This is possible with frequently-repeatable work has been refined over time to find the "best" way to do the work. CI/CD in software development falls into this category. You don't want variation in your build process so you standardize the process, adjust until you're happy with it, then automate it. That automated process is obviously far less expensive to run through than manually fighting through a deploy.
Statistical Process Control is the next least expensive, but it accounts for variations in a known process. Medical procedures that go according to plan fall into this category. I don't want to reinvent a bypass surgery each time. I follow the basic process and adjust for variation. This has a relatively low cognitive load and a fairly high rate of success.
Next is Empirical Process Control, which is by far the most expensive because you have to discover the process as you go. Learning is incredibly high, but at the price of productivity and efficiency. However, nearly all project work requires this because few project have been done before. There are, of course, exceptions. Setting up a large active directory environment is more Statistical because you work from some tried-and-true instructions that you deviate from slightly as circumstances require. But unless you're project is to do the exact work that has been done before, it almost certainly requires Emperical Process Control.
To bring it back to Scrum, Scrum is designed to solve problems with Emperical Process control. Therefor, yes, it has more overhead than other approaches. However, since most projects require this approach, it's a moot argument.
To the counterpoint about medicine and military projects, it sounds like flawed logic. If you are fulfilling an order for 500 airplanes, then yes, you are recreating something exactly and Scrum is probably not beneficial. If you are building a new plane and your requirements never change, I wouldn't fly that plane.
answered Jan 22 at 11:47
DanielDaniel
1,274310
add a comment |
The very short answer is that yes, Scrum is by design a more expensive approach, but if you're calling it a project, it almost certainly doesn't matter and in the end will almost certainly always result in a better ROI.
The more complete answer is this:
Generally speaking there are three forms of process control: Defined Process Control, Statistical Process Control, and Emperical Process Control. Defined Process Control is by far the cheapest. This is possible with frequently-repeatable work has been refined over time to find the "best" way to do the work. CI/CD in software development falls into this category. You don't want variation in your build process so you standardize the process, adjust until you're happy with it, then automate it. That automated process is obviously far less expensive to run through than manually fighting through a deploy.
Statistical Process Control is the next least expensive, but it accounts for variations in a known process. Medical procedures that go according to plan fall into this category. I don't want to reinvent a bypass surgery each time. I follow the basic process and adjust for variation. This has a relatively low cognitive load and a fairly high rate of success.
Next is Empirical Process Control, which is by far the most expensive because you have to discover the process as you go. Learning is incredibly high, but at the price of productivity and efficiency. However, nearly all project work requires this because few project have been done before. There are, of course, exceptions. Setting up a large active directory environment is more Statistical because you work from some tried-and-true instructions that you deviate from slightly as circumstances require. But unless you're project is to do the exact work that has been done before, it almost certainly requires Emperical Process Control.
To bring it back to Scrum, Scrum is designed to solve problems with Emperical Process control. Therefor, yes, it has more overhead than other approaches. However, since most projects require this approach, it's a moot argument.
To the counterpoint about medicine and military projects, it sounds like flawed logic. If you are fulfilling an order for 500 airplanes, then yes, you are recreating something exactly and Scrum is probably not beneficial. If you are building a new plane and your requirements never change, I wouldn't fly that plane.
answered Jan 22 at 11:47
DanielDaniel
1,274310
The very short answer is that yes, Scrum is by design a more expensive approach, but if you're calling it a project, it almost certainly doesn't matter and in the end will almost certainly always result in a better ROI.
The more complete answer is this:
Generally speaking there are three forms of process control: Defined Process Control, Statistical Process Control, and Emperical Process Control. Defined Process Control is by far the cheapest. This is possible with frequently-repeatable work has been refined over time to find the "best" way to do the work. CI/CD in software development falls into this category. You don't want variation in your build process so you standardize the process, adjust until you're happy with it, then automate it. That automated process is obviously far less expensive to run through than manually fighting through a deploy.
Statistical Process Control is the next least expensive, but it accounts for variations in a known process. Medical procedures that go according to plan fall into this category. I don't want to reinvent a bypass surgery each time. I follow the basic process and adjust for variation. This has a relatively low cognitive load and a fairly high rate of success.
Next is Empirical Process Control, which is by far the most expensive because you have to discover the process as you go. Learning is incredibly high, but at the price of productivity and efficiency. However, nearly all project work requires this because few project have been done before. There are, of course, exceptions. Setting up a large active directory environment is more Statistical because you work from some tried-and-true instructions that you deviate from slightly as circumstances require. But unless you're project is to do the exact work that has been done before, it almost certainly requires Emperical Process Control.
To bring it back to Scrum, Scrum is designed to solve problems with Emperical Process control. Therefor, yes, it has more overhead than other approaches. However, since most projects require this approach, it's a moot argument.
To the counterpoint about medicine and military projects, it sounds like flawed logic. If you are fulfilling an order for 500 airplanes, then yes, you are recreating something exactly and Scrum is probably not beneficial. If you are building a new plane and your requirements never change, I wouldn't fly that plane.
answered Jan 22 at 11:47
DanielDaniel
1,274310
answered Jan 22 at 11:47
DanielDaniel
1,274310
answered Jan 22 at 11:47
DanielDaniel
1,274310
answered Jan 22 at 11:47
DanielDaniel
1,274310
1,274310
add a comment |
add a comment |
Sure, if you have a project where you have crystal clear requirements up front, then you could waterfallishly dump them in front of developers and come back two years later to meet the software of your dreams.
But the vast majority of software projects is not like this.
Usually, the customer doesn't know what they need. They are unable to provide complete and specific requirements. Iterative approaches help here: build a small thing, then ask the customer for feedback. Yes, this "wastes" time on demos and planning the next iteration. But building the wrong thing for one sprint and then quickly correcting the requirements is a lot better than building the wrong thing for the entirety of the project. I.e. while requirements up front may allow for more efficient development, iterative approaches will be more effective.
Developers must understand the requirements correctly if they are to build useful software. What is a good way to discover misunderstandings before it is too late? Again, iterative approaches can help. But it is also important that developers themselves collaborate with the customer instead of only getting filtered information through a requirements document author.
Finally, the world doesn't stand still during the project. External systems change, priorities change, people change. Pretending that the requirements of a software project won't change is a bad idea, except for short projects.
All of these process-level benefits miss the big day to day advantage of agile approaches: if done correctly, agile makes everyone happier. The biggest one of these is that agile techniques focus on providing real value over short time frames. That brings visibility into the development process, gives stakeholders a reasonable level of control over the project, and is much more motivating than working towards a distant goal. Related to this is the idea that agile teams will be largely self-organizing. Feeling in control over their day to day work makes people feel valued, and therefore more likely to give their best.
Your colleague is not wrong that waterfall style projects can have their place. And you are not wrong that some agile-ish practices can be time-wasting rituals. But it is completely foolish to ignore the benefits of agile and iterative approaches, especially better risk management and respect for individuals. These are things you want in every project. If necessary a team can try to implement some of this internally, but processes work better when everyone is on board.
answered Jan 22 at 11:42
amonamon
88.5k21168258
add a comment |
Sure, if you have a project where you have crystal clear requirements up front, then you could waterfallishly dump them in front of developers and come back two years later to meet the software of your dreams.
But the vast majority of software projects is not like this.
Usually, the customer doesn't know what they need. They are unable to provide complete and specific requirements. Iterative approaches help here: build a small thing, then ask the customer for feedback. Yes, this "wastes" time on demos and planning the next iteration. But building the wrong thing for one sprint and then quickly correcting the requirements is a lot better than building the wrong thing for the entirety of the project. I.e. while requirements up front may allow for more efficient development, iterative approaches will be more effective.
Developers must understand the requirements correctly if they are to build useful software. What is a good way to discover misunderstandings before it is too late? Again, iterative approaches can help. But it is also important that developers themselves collaborate with the customer instead of only getting filtered information through a requirements document author.
Finally, the world doesn't stand still during the project. External systems change, priorities change, people change. Pretending that the requirements of a software project won't change is a bad idea, except for short projects.
All of these process-level benefits miss the big day to day advantage of agile approaches: if done correctly, agile makes everyone happier. The biggest one of these is that agile techniques focus on providing real value over short time frames. That brings visibility into the development process, gives stakeholders a reasonable level of control over the project, and is much more motivating than working towards a distant goal. Related to this is the idea that agile teams will be largely self-organizing. Feeling in control over their day to day work makes people feel valued, and therefore more likely to give their best.
Your colleague is not wrong that waterfall style projects can have their place. And you are not wrong that some agile-ish practices can be time-wasting rituals. But it is completely foolish to ignore the benefits of agile and iterative approaches, especially better risk management and respect for individuals. These are things you want in every project. If necessary a team can try to implement some of this internally, but processes work better when everyone is on board.
answered Jan 22 at 11:42
amonamon
88.5k21168258
add a comment |
Sure, if you have a project where you have crystal clear requirements up front, then you could waterfallishly dump them in front of developers and come back two years later to meet the software of your dreams.
But the vast majority of software projects is not like this.
Usually, the customer doesn't know what they need. They are unable to provide complete and specific requirements. Iterative approaches help here: build a small thing, then ask the customer for feedback. Yes, this "wastes" time on demos and planning the next iteration. But building the wrong thing for one sprint and then quickly correcting the requirements is a lot better than building the wrong thing for the entirety of the project. I.e. while requirements up front may allow for more efficient development, iterative approaches will be more effective.
Developers must understand the requirements correctly if they are to build useful software. What is a good way to discover misunderstandings before it is too late? Again, iterative approaches can help. But it is also important that developers themselves collaborate with the customer instead of only getting filtered information through a requirements document author.
Finally, the world doesn't stand still during the project. External systems change, priorities change, people change. Pretending that the requirements of a software project won't change is a bad idea, except for short projects.
All of these process-level benefits miss the big day to day advantage of agile approaches: if done correctly, agile makes everyone happier. The biggest one of these is that agile techniques focus on providing real value over short time frames. That brings visibility into the development process, gives stakeholders a reasonable level of control over the project, and is much more motivating than working towards a distant goal. Related to this is the idea that agile teams will be largely self-organizing. Feeling in control over their day to day work makes people feel valued, and therefore more likely to give their best.
Your colleague is not wrong that waterfall style projects can have their place. And you are not wrong that some agile-ish practices can be time-wasting rituals. But it is completely foolish to ignore the benefits of agile and iterative approaches, especially better risk management and respect for individuals. These are things you want in every project. If necessary a team can try to implement some of this internally, but processes work better when everyone is on board.
answered Jan 22 at 11:42
amonamon
88.5k21168258
Sure, if you have a project where you have crystal clear requirements up front, then you could waterfallishly dump them in front of developers and come back two years later to meet the software of your dreams.
But the vast majority of software projects is not like this.
Usually, the customer doesn't know what they need. They are unable to provide complete and specific requirements. Iterative approaches help here: build a small thing, then ask the customer for feedback. Yes, this "wastes" time on demos and planning the next iteration. But building the wrong thing for one sprint and then quickly correcting the requirements is a lot better than building the wrong thing for the entirety of the project. I.e. while requirements up front may allow for more efficient development, iterative approaches will be more effective.
Developers must understand the requirements correctly if they are to build useful software. What is a good way to discover misunderstandings before it is too late? Again, iterative approaches can help. But it is also important that developers themselves collaborate with the customer instead of only getting filtered information through a requirements document author.
Finally, the world doesn't stand still during the project. External systems change, priorities change, people change. Pretending that the requirements of a software project won't change is a bad idea, except for short projects.
All of these process-level benefits miss the big day to day advantage of agile approaches: if done correctly, agile makes everyone happier. The biggest one of these is that agile techniques focus on providing real value over short time frames. That brings visibility into the development process, gives stakeholders a reasonable level of control over the project, and is much more motivating than working towards a distant goal. Related to this is the idea that agile teams will be largely self-organizing. Feeling in control over their day to day work makes people feel valued, and therefore more likely to give their best.
Your colleague is not wrong that waterfall style projects can have their place. And you are not wrong that some agile-ish practices can be time-wasting rituals. But it is completely foolish to ignore the benefits of agile and iterative approaches, especially better risk management and respect for individuals. These are things you want in every project. If necessary a team can try to implement some of this internally, but processes work better when everyone is on board.
answered Jan 22 at 11:42
amonamon
88.5k21168258
answered Jan 22 at 11:42
amonamon
88.5k21168258
answered Jan 22 at 11:42
amonamon
88.5k21168258
answered Jan 22 at 11:42
amonamon
88.5k21168258
88.5k21168258
add a comment |
add a comment |
I think this may well be paraphrasing what @Cort Ammon is saying, but here is my take:
The external requirements (describing the "deliverables") aren't the only requirements in a project. Even if the external requirements don't change, the "internal" requirements will change, or need to be allowed to change, as you work. Developers will discover obstacles or problems with an approach, and this will affect the work of the other people in the team. A daily stand-up will keep everyone up to date with these internal changes.
answered Jan 23 at 0:47
BeejaminBeejamin
1193
1
yes I have worked on waterfall projects where not a single requirement changed during build, but one person spent almost all day changing the project plan to allow for sickness, holidays, unforeseen technical problems.
– WendyG
Jan 23 at 10:05
add a comment |
I think this may well be paraphrasing what @Cort Ammon is saying, but here is my take:
The external requirements (describing the "deliverables") aren't the only requirements in a project. Even if the external requirements don't change, the "internal" requirements will change, or need to be allowed to change, as you work. Developers will discover obstacles or problems with an approach, and this will affect the work of the other people in the team. A daily stand-up will keep everyone up to date with these internal changes.
answered Jan 23 at 0:47
BeejaminBeejamin
1193
1
yes I have worked on waterfall projects where not a single requirement changed during build, but one person spent almost all day changing the project plan to allow for sickness, holidays, unforeseen technical problems.
– WendyG
Jan 23 at 10:05
add a comment |
I think this may well be paraphrasing what @Cort Ammon is saying, but here is my take:
The external requirements (describing the "deliverables") aren't the only requirements in a project. Even if the external requirements don't change, the "internal" requirements will change, or need to be allowed to change, as you work. Developers will discover obstacles or problems with an approach, and this will affect the work of the other people in the team. A daily stand-up will keep everyone up to date with these internal changes.
answered Jan 23 at 0:47
BeejaminBeejamin
1193
I think this may well be paraphrasing what @Cort Ammon is saying, but here is my take:
The external requirements (describing the "deliverables") aren't the only requirements in a project. Even if the external requirements don't change, the "internal" requirements will change, or need to be allowed to change, as you work. Developers will discover obstacles or problems with an approach, and this will affect the work of the other people in the team. A daily stand-up will keep everyone up to date with these internal changes.
answered Jan 23 at 0:47
BeejaminBeejamin
1193
answered Jan 23 at 0:47
BeejaminBeejamin
1193
answered Jan 23 at 0:47
BeejaminBeejamin
1193
answered Jan 23 at 0:47
BeejaminBeejamin
1193
1193
1
yes I have worked on waterfall projects where not a single requirement changed during build, but one person spent almost all day changing the project plan to allow for sickness, holidays, unforeseen technical problems.
– WendyG
Jan 23 at 10:05
add a comment |
1
yes I have worked on waterfall projects where not a single requirement changed during build, but one person spent almost all day changing the project plan to allow for sickness, holidays, unforeseen technical problems.
– WendyG
Jan 23 at 10:05
1
1
yes I have worked on waterfall projects where not a single requirement changed during build, but one person spent almost all day changing the project plan to allow for sickness, holidays, unforeseen technical problems.
– WendyG
Jan 23 at 10:05
yes I have worked on waterfall projects where not a single requirement changed during build, but one person spent almost all day changing the project plan to allow for sickness, holidays, unforeseen technical problems.
– WendyG
Jan 23 at 10:05
add a comment |
Consider that:
Even with fixed functional requirements you need to traslate them into technical requirements. And this may be better done by iterations. You may discover better ways to solve the problem at the middle of the project.
Some requierements may be too generic or ambiguous: "be easy to use", "be secure". It is hard to analyze he security or usability of a system that it is not finished. Some may have hidden implications or may not be well understood.
Some requirements may be improved. Responding in 200ms may be good but 100 may be better. You may target the best possible result but sacrifice it if needed during the project.
You may discover some hidden requierement that won't be written on the contract but may change the project from failure to success. Even if you deliver the project the client may not be happy. May be they even need to change the contract to add (and charge) for new features that you may design in the project cheaper in the early stages.
You may discover that you can't fullfill your requirements in the given time. Is not as if software projects never got late. So delivering the best value will allow you to renegociate what features to drop.
Delivering something sooner will help integration and will show that this project can deliver results.
answered Jan 23 at 10:05
BorjabBorjab
826515
add a comment |
Consider that:
Even with fixed functional requirements you need to traslate them into technical requirements. And this may be better done by iterations. You may discover better ways to solve the problem at the middle of the project.
Some requierements may be too generic or ambiguous: "be easy to use", "be secure". It is hard to analyze he security or usability of a system that it is not finished. Some may have hidden implications or may not be well understood.
Some requirements may be improved. Responding in 200ms may be good but 100 may be better. You may target the best possible result but sacrifice it if needed during the project.
You may discover some hidden requierement that won't be written on the contract but may change the project from failure to success. Even if you deliver the project the client may not be happy. May be they even need to change the contract to add (and charge) for new features that you may design in the project cheaper in the early stages.
You may discover that you can't fullfill your requirements in the given time. Is not as if software projects never got late. So delivering the best value will allow you to renegociate what features to drop.
Delivering something sooner will help integration and will show that this project can deliver results.
answered Jan 23 at 10:05
BorjabBorjab
826515
add a comment |
Consider that:
Even with fixed functional requirements you need to traslate them into technical requirements. And this may be better done by iterations. You may discover better ways to solve the problem at the middle of the project.
Some requierements may be too generic or ambiguous: "be easy to use", "be secure". It is hard to analyze he security or usability of a system that it is not finished. Some may have hidden implications or may not be well understood.
Some requirements may be improved. Responding in 200ms may be good but 100 may be better. You may target the best possible result but sacrifice it if needed during the project.
You may discover some hidden requierement that won't be written on the contract but may change the project from failure to success. Even if you deliver the project the client may not be happy. May be they even need to change the contract to add (and charge) for new features that you may design in the project cheaper in the early stages.
You may discover that you can't fullfill your requirements in the given time. Is not as if software projects never got late. So delivering the best value will allow you to renegociate what features to drop.
Delivering something sooner will help integration and will show that this project can deliver results.
answered Jan 23 at 10:05
BorjabBorjab
826515
Consider that:
Even with fixed functional requirements you need to traslate them into technical requirements. And this may be better done by iterations. You may discover better ways to solve the problem at the middle of the project.
Some requierements may be too generic or ambiguous: "be easy to use", "be secure". It is hard to analyze he security or usability of a system that it is not finished. Some may have hidden implications or may not be well understood.
Some requirements may be improved. Responding in 200ms may be good but 100 may be better. You may target the best possible result but sacrifice it if needed during the project.
You may discover some hidden requierement that won't be written on the contract but may change the project from failure to success. Even if you deliver the project the client may not be happy. May be they even need to change the contract to add (and charge) for new features that you may design in the project cheaper in the early stages.
You may discover that you can't fullfill your requirements in the given time. Is not as if software projects never got late. So delivering the best value will allow you to renegociate what features to drop.
Delivering something sooner will help integration and will show that this project can deliver results.
answered Jan 23 at 10:05
BorjabBorjab
826515
answered Jan 23 at 10:05
BorjabBorjab
826515
answered Jan 23 at 10:05
BorjabBorjab
826515
answered Jan 23 at 10:05
BorjabBorjab
826515
826515
add a comment |
add a comment |
One can make the argument that if all requirements are laid out perfectly, then there exists a top down approach which achieves those requirements as fast as possible. However, if these are good requirements, they tell you what to make, not how to make it. If they tell you how to make it, I'd choose to call it "work instructions" instead of "requirements" and we'd be discussing a different sort of problem.
Accordingly, there is always a process of developing the "how" which is internal to the company or team implementing the requirements. Empirically speaking, we rely strongly on a hierarchical approach where a team of designers design the high level system to meet those requirements, and then use the specifics of that high level system to provide "requirements" to smaller teams which flesh our the details.
In the waterfall process, this can be seen in the one-way arrow between design and implementation. However, these requirements are not set in stone, like the customer provided ones were. These are internally defined and have room for the iterative process. In practice, we find designers either put considerable margin in the process to account for this lack of iteration or seek an iterative process.
SCRUM, and many other related agile methods, simply provide a rigorous framework within which to do this iterative process. A trademark of the agile approaches is that they consider optimizing this iterative pattern to be the core of the process, rather than focusing on the outer layer of hard requirements. As others have mentioned, actual fixed requirements are rare, but even in their presence, SCRUM uses the iterative approach as a methodology to control the contractual approach it fits inside of.
Whether it succeeds at doing this is a matter of open debate. Others have provided many metrics to this end. I will merely note that it is up to the strength of the leadership to make sure the iterations which occur below them dovetail correctly into the contractual system above. This is true with any approach to development, but it is more visible in agile approaches because we have been raised to assume the more top down approach is "normal" and trained leaders as such.
answered Jan 22 at 18:32
Cort AmmonCort Ammon
9,68131830
add a comment |
One can make the argument that if all requirements are laid out perfectly, then there exists a top down approach which achieves those requirements as fast as possible. However, if these are good requirements, they tell you what to make, not how to make it. If they tell you how to make it, I'd choose to call it "work instructions" instead of "requirements" and we'd be discussing a different sort of problem.
Accordingly, there is always a process of developing the "how" which is internal to the company or team implementing the requirements. Empirically speaking, we rely strongly on a hierarchical approach where a team of designers design the high level system to meet those requirements, and then use the specifics of that high level system to provide "requirements" to smaller teams which flesh our the details.
In the waterfall process, this can be seen in the one-way arrow between design and implementation. However, these requirements are not set in stone, like the customer provided ones were. These are internally defined and have room for the iterative process. In practice, we find designers either put considerable margin in the process to account for this lack of iteration or seek an iterative process.
SCRUM, and many other related agile methods, simply provide a rigorous framework within which to do this iterative process. A trademark of the agile approaches is that they consider optimizing this iterative pattern to be the core of the process, rather than focusing on the outer layer of hard requirements. As others have mentioned, actual fixed requirements are rare, but even in their presence, SCRUM uses the iterative approach as a methodology to control the contractual approach it fits inside of.
Whether it succeeds at doing this is a matter of open debate. Others have provided many metrics to this end. I will merely note that it is up to the strength of the leadership to make sure the iterations which occur below them dovetail correctly into the contractual system above. This is true with any approach to development, but it is more visible in agile approaches because we have been raised to assume the more top down approach is "normal" and trained leaders as such.
answered Jan 22 at 18:32
Cort AmmonCort Ammon
9,68131830
add a comment |
One can make the argument that if all requirements are laid out perfectly, then there exists a top down approach which achieves those requirements as fast as possible. However, if these are good requirements, they tell you what to make, not how to make it. If they tell you how to make it, I'd choose to call it "work instructions" instead of "requirements" and we'd be discussing a different sort of problem.
Accordingly, there is always a process of developing the "how" which is internal to the company or team implementing the requirements. Empirically speaking, we rely strongly on a hierarchical approach where a team of designers design the high level system to meet those requirements, and then use the specifics of that high level system to provide "requirements" to smaller teams which flesh our the details.
In the waterfall process, this can be seen in the one-way arrow between design and implementation. However, these requirements are not set in stone, like the customer provided ones were. These are internally defined and have room for the iterative process. In practice, we find designers either put considerable margin in the process to account for this lack of iteration or seek an iterative process.
SCRUM, and many other related agile methods, simply provide a rigorous framework within which to do this iterative process. A trademark of the agile approaches is that they consider optimizing this iterative pattern to be the core of the process, rather than focusing on the outer layer of hard requirements. As others have mentioned, actual fixed requirements are rare, but even in their presence, SCRUM uses the iterative approach as a methodology to control the contractual approach it fits inside of.
Whether it succeeds at doing this is a matter of open debate. Others have provided many metrics to this end. I will merely note that it is up to the strength of the leadership to make sure the iterations which occur below them dovetail correctly into the contractual system above. This is true with any approach to development, but it is more visible in agile approaches because we have been raised to assume the more top down approach is "normal" and trained leaders as such.
answered Jan 22 at 18:32
Cort AmmonCort Ammon
9,68131830
One can make the argument that if all requirements are laid out perfectly, then there exists a top down approach which achieves those requirements as fast as possible. However, if these are good requirements, they tell you what to make, not how to make it. If they tell you how to make it, I'd choose to call it "work instructions" instead of "requirements" and we'd be discussing a different sort of problem.
Accordingly, there is always a process of developing the "how" which is internal to the company or team implementing the requirements. Empirically speaking, we rely strongly on a hierarchical approach where a team of designers design the high level system to meet those requirements, and then use the specifics of that high level system to provide "requirements" to smaller teams which flesh our the details.
In the waterfall process, this can be seen in the one-way arrow between design and implementation. However, these requirements are not set in stone, like the customer provided ones were. These are internally defined and have room for the iterative process. In practice, we find designers either put considerable margin in the process to account for this lack of iteration or seek an iterative process.
SCRUM, and many other related agile methods, simply provide a rigorous framework within which to do this iterative process. A trademark of the agile approaches is that they consider optimizing this iterative pattern to be the core of the process, rather than focusing on the outer layer of hard requirements. As others have mentioned, actual fixed requirements are rare, but even in their presence, SCRUM uses the iterative approach as a methodology to control the contractual approach it fits inside of.
Whether it succeeds at doing this is a matter of open debate. Others have provided many metrics to this end. I will merely note that it is up to the strength of the leadership to make sure the iterations which occur below them dovetail correctly into the contractual system above. This is true with any approach to development, but it is more visible in agile approaches because we have been raised to assume the more top down approach is "normal" and trained leaders as such.
answered Jan 22 at 18:32
Cort AmmonCort Ammon
9,68131830
answered Jan 22 at 18:32
Cort AmmonCort Ammon
9,68131830
answered Jan 22 at 18:32
Cort AmmonCort Ammon
9,68131830
answered Jan 22 at 18:32
Cort AmmonCort Ammon
9,68131830
9,68131830
add a comment |
add a comment |
Thanks for contributing an answer to Software Engineering Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsoftwareengineering.stackexchange.com%2fquestions%2f385926%2fdoes-scrum-create-additional-overhead-for-projects-where-requirements-dont-chan%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
50
Military project requirements change constantly - which is how they end up massively over budget and delayed
– HorusKol
Jan 22 at 10:44
26
The only projects where requirements don't change are cancelled or terminated projects. It might be that in some industries the cycle from idea to deployed product is longer than in other industries, but that doesn't change the fact that ideas/requirements change constantly.
– Bart van Ingen Schenau
Jan 22 at 11:39
24
I've been involved with military projects where the requirements "didn't change" because they were so vague as to be useless. For example, the performance requirements for a fighter aircraft engine: "The engine will perform satisfactorily over the full flight envelope of the aircraft". That one sentence was the entire spec. The reply to a request for more details was "Well, we don't know what the full flight envelope will be until we have test flown the prototype aircraft". And no, I'm not making this stuff up.
– alephzero
Jan 22 at 14:37
7
The CHAOS reports have issues - see, for example few.vu.nl/~x/chaos/chaos.pdf - and while, on balance, research into the effectiveness of agile and Scrum methods shows a positive effect, there are systematic problems with the comparator groups since "non-agile" is less well defined than what it is being compared to.
– Jack Aidley
Jan 22 at 16:03
8
@senseiwu the idea that an engineer is "forced to explain their work every day to a non tech" suggests that you've never done anything resembling what the Scrum Guide talks about. Which, sadly, is pretty common among people who claim to have done Scrum.
– Erik
Jan 23 at 10:07