Voor degenen die geen lid zijn van deze groep (The Project Manager Network - #1 Group for Project Managers) volgt hier de discussie:
Agile Vs Waterfall Model
What do you
think is the key differentiator between Agile Vs waterfall model in project
management and what should be the criteria to choose one of the model for a
specific project?
Francisco Leo
• IMHO biggest
differentiator is the visibility the stakeholders get in the project and how
things interrelate, this of course from a software project point of view.
Andrea Stewart
• I agree with
Francisco. The biggest difference is the participation of the stakeholders. I
do think that the waterfall model still has its uses in a case that you are
providing a product that the end consumer does not know that they need. Even in
this case, you would still want some kind of end user feedback,
Sanjay Gupta, PMP • I agree with
you. Not so clear requirement and customer continues involved is key factor
which sought for Agile based implementation.
Waterfall model will not be able to effectively handle these changing requirement.
-Sanjay
Waterfall model will not be able to effectively handle these changing requirement.
-Sanjay
Manoj Vadakkan • Hello!
Francisco and Andrea pointed out the customer collaboration aspects. Sanjay, you are pointing out the responding to change aspect. There are two other major factors and all four of them are documented here :-)
http://agilemanifesto.org/
That is a good start.
Francisco and Andrea pointed out the customer collaboration aspects. Sanjay, you are pointing out the responding to change aspect. There are two other major factors and all four of them are documented here :-)
http://agilemanifesto.org/
That is a good start.
Frederick Ayala • Hi Sanjay,
The paper of Winston Royce is very interesting for the comparison that you are making. Also there is a lot of interesting papers at IEEE, PMI and articles in Scrum Alliance.
You can compare them in several ways such as: how the requirements specification, quality assurance, change management and maintenance processes are done. For instance, regarding to the requirements specification process:
Winston Royce expressed on his waterfall paper: “I believe in this concept, but the implementation described above is risky and invites failure”. The main reason of he said this is that excessive time and effort is dedicated for full detailed requirements specification on the very first stage but tested on one of the latest stages. [1]
On the other hand. User stories focus on customer value. They don’t just assume a looseness of specification; they actually encourage it in order to foster a higher level of collaboration between the stakeholders and the team. A user story is a metaphor for the work being done, not a full description of the work. The actual work being done is fleshed out via collaboration revolving around the user story as system development progresses. [2]
Kind regards,
Frederick Ayala
[1] Winston Royce, “Managing The Development Of Large Software Systems”, IEEE, 1970.
[2] William F. Nazzaro, “New to User Stories?”, Scrum Alliance, 2010.
The paper of Winston Royce is very interesting for the comparison that you are making. Also there is a lot of interesting papers at IEEE, PMI and articles in Scrum Alliance.
You can compare them in several ways such as: how the requirements specification, quality assurance, change management and maintenance processes are done. For instance, regarding to the requirements specification process:
Winston Royce expressed on his waterfall paper: “I believe in this concept, but the implementation described above is risky and invites failure”. The main reason of he said this is that excessive time and effort is dedicated for full detailed requirements specification on the very first stage but tested on one of the latest stages. [1]
On the other hand. User stories focus on customer value. They don’t just assume a looseness of specification; they actually encourage it in order to foster a higher level of collaboration between the stakeholders and the team. A user story is a metaphor for the work being done, not a full description of the work. The actual work being done is fleshed out via collaboration revolving around the user story as system development progresses. [2]
Kind regards,
Frederick Ayala
[1] Winston Royce, “Managing The Development Of Large Software Systems”, IEEE, 1970.
[2] William F. Nazzaro, “New to User Stories?”, Scrum Alliance, 2010.
Subbu Subramanian • I am not sure
if we can have such an open ended system design & architecture at the
beginning of the project to accommodate the frequent business/functional
changes that Agile methodology is advocating. I am not sure where one draws a
line between accepting functional changes Vs. design changes ( to accommodate
the functional requirements)
In a true agile process, can we execute a project on a fixed budget?
In a true agile process, can we execute a project on a fixed budget?
Rohit Gupta
• Good Observation
Subbu, biggest problem with Agile is fixed price project runaway cost and scope
creep.
I prefer to use Waterfall (Iterative mode) for requirement sign off, use Agile for development and QA. Any new request should be part of change control/scope change and should be treated differently.
I prefer to use Waterfall (Iterative mode) for requirement sign off, use Agile for development and QA. Any new request should be part of change control/scope change and should be treated differently.
Ivo Verus • @Subbu: In fixed budget
projects you can still use agile process but you take the risk of going over
budget and not having implemented all requirements by the deadline provided. The
reason is obvious, as client changes the requirements during implementation
frequently, you have to change the code and spend extra time/money.
I'd recommend to establish good relations with client and client to trust you. When that is achieved there is a space to offer time&material cooperation model and use agile methodologies. At the end both parties will be more satisfied compared to when using waterfall methodology and 'fight' for every change request.
I'd recommend to establish good relations with client and client to trust you. When that is achieved there is a space to offer time&material cooperation model and use agile methodologies. At the end both parties will be more satisfied compared to when using waterfall methodology and 'fight' for every change request.
Subbu Subramanian • Agreed Ivo,
T&M is the best option. Even if one follows component based design,
frequent requirement changes will affect my design , how can i protect my
design to avoid rework.
Axel Vanhooren
• Sanjay,
To check I understand your question correctly, the question is about the impact of Agile (a software development philosophy) and Waterfall (a type of software dev. methodology) on project management.
1) With waterfall projects:
The project manager has an overview over the whole plan of the project. Since the insight increases as the project progresses, the first rough estimations become more and more precise. Plans can be more detailed (rolling wave) but may also need to be adapted to the evolving situation. This is provides an overall structure and vision of the project process. Reporting and following the progress of the project is easier. It is also somewhat easier to manage the interactions and dependencies between projects. But we must be aware that without close involvement of business people, to them, the reported progress is rather abstract. It are only numbers in reports.
2) Agile
Agile (Scrum) works with iterations/sprint and a backlog of a few weeks to a couple of months. Only the current sprint is defined. Since Agile is open to changes in features, new demands and changes in priorities, it seems to me that the view one has on the project doesn't reach further than the current sprint.
Moreover, the product owner, (in Scrum) the scrum master and the self-managed team take a part of the project management tasks on their shoulders. Additionally, Agile is lightweight. So it reduces all the project administration. I wonder whether there is still a lot of work left for a project manager.
As I understand, the burn down chart, backlog and the story points allow to measure and communicate progress. Since there is a great involvment of business people and product owner, and with the short sprints and feedback short after the delivery at end of the sprints, I would expect that lesser "measuring" is demanded by the client/business people.
The question about criteria to choose for one or another type of approach is a tough one. Comparisons of Agile and Watefall presented by Agile proponents are not reliable. The present a completely distorted picture of Waterfall (and only presumed weaknesses, the worse this picture is the better) and presumed qualities of Agile. One need to understand the real strengths, weaknesses, limits, required contitions and risks of both. Then, of course, you need to understand your (future) project, the expectations in terms of control, reporting and formalism of the client, the capability of the resources to work in one or another way .. and finally there are the personal preferences. What is your team absolutely don't want to work in one or another way?
Hope this helps.
Axel.
To check I understand your question correctly, the question is about the impact of Agile (a software development philosophy) and Waterfall (a type of software dev. methodology) on project management.
1) With waterfall projects:
The project manager has an overview over the whole plan of the project. Since the insight increases as the project progresses, the first rough estimations become more and more precise. Plans can be more detailed (rolling wave) but may also need to be adapted to the evolving situation. This is provides an overall structure and vision of the project process. Reporting and following the progress of the project is easier. It is also somewhat easier to manage the interactions and dependencies between projects. But we must be aware that without close involvement of business people, to them, the reported progress is rather abstract. It are only numbers in reports.
2) Agile
Agile (Scrum) works with iterations/sprint and a backlog of a few weeks to a couple of months. Only the current sprint is defined. Since Agile is open to changes in features, new demands and changes in priorities, it seems to me that the view one has on the project doesn't reach further than the current sprint.
Moreover, the product owner, (in Scrum) the scrum master and the self-managed team take a part of the project management tasks on their shoulders. Additionally, Agile is lightweight. So it reduces all the project administration. I wonder whether there is still a lot of work left for a project manager.
As I understand, the burn down chart, backlog and the story points allow to measure and communicate progress. Since there is a great involvment of business people and product owner, and with the short sprints and feedback short after the delivery at end of the sprints, I would expect that lesser "measuring" is demanded by the client/business people.
The question about criteria to choose for one or another type of approach is a tough one. Comparisons of Agile and Watefall presented by Agile proponents are not reliable. The present a completely distorted picture of Waterfall (and only presumed weaknesses, the worse this picture is the better) and presumed qualities of Agile. One need to understand the real strengths, weaknesses, limits, required contitions and risks of both. Then, of course, you need to understand your (future) project, the expectations in terms of control, reporting and formalism of the client, the capability of the resources to work in one or another way .. and finally there are the personal preferences. What is your team absolutely don't want to work in one or another way?
Hope this helps.
Axel.
Ivo Verus • @Subbu: You shouldn't insist
to client that design has to be fixed. In reality actually rarely happens
design to remain as it was created at beginning. The main reason for that is
that client knows what he/she wants to achieve, but doesn't know exactly how to
achieve it. That is why there would be new requirements and changes of existing
requirements once client see part of application or/and start using it.
The point here is that you as project manager should work with client and make him/her understand that changes are expected but that those changes will have some impact on a project. The team will work to make the impact as low as possible and to answer on client's need as those needs are most probably the market needs and key factor of project success.
The point here is that you as project manager should work with client and make him/her understand that changes are expected but that those changes will have some impact on a project. The team will work to make the impact as low as possible and to answer on client's need as those needs are most probably the market needs and key factor of project success.
Daniel Cora, MBA • Triple
Constraint / Requirement(s)
Anastasia Chumakova • As Axel has
rightly said, here we compare philosophy (Agile) with methodology (Waterfall). I
wouldn't oppose them. I would just make another combination: i strongly believe
that Agile goes perfectly well with Management by Objectives (MBO).
True that when using Agile we risk to miss deadlines or go over the budget. When Agile is combined with MBO, we have all the chances to avoid this evil.
At the same time, speaking of start-up projects, I would also mention, that projects of this type will inevitably surpass the budget. In most project this or that deadline will be missed. I find it natural. Though, it's already off top.
True that when using Agile we risk to miss deadlines or go over the budget. When Agile is combined with MBO, we have all the chances to avoid this evil.
At the same time, speaking of start-up projects, I would also mention, that projects of this type will inevitably surpass the budget. In most project this or that deadline will be missed. I find it natural. Though, it's already off top.
Charles D Fain
• Axel Vanhooren and
Anastasia Chumakovo voiced very good points. Rolling Wave project management
overcomes the changes that occur during projects that need some flexibility. Agile
is meant for shorter projects (probably with a few team members) and is light
weight. They both have their purpose. I am finding that many companies are not
buying in to the Time and Material charges because they are becoming more
tarnished and knowledgable about development work. I like both models and feel
that at times a hybrid is needed. Every project is different and when you have
many stakeholders without close and direct colaboration or a few stakeholders
with close colaboration on a shorter project might be the difference in
management models. Just thinking out loud:)
Jack (Jeb) McIntyre • I don't see
either approach as mutually exclusive, nor do I see either as the ultimate. Each
has advantages and disadvantages, so I find a hybrid approach in which I pick
and chose elements of each depending upon the project constraints to be the
most productive.
One of my guiding principals is the smaller the project (limited scope, short time duration) the greater the probability of success. However some projects (or perhaps more correctly some environments) simply don't lend themselves to a pure "agile" approach. In those cases I use a waterfall approach for initially defining requirements and generating a master plan for the project (project roadmap). However within that master plan I typically make provision for a series of agile initiatives.
Note I make EXTENSIVE use of ASSUMPTIONS! This is one of the most critical aspects of project planning, and also one of the most overlooked.
I develop a project risk profile that identifies (to some extent) the confidence interval to apply against the project constraints (time, scope, budget). So, for example, in the end, if my assumptions are correct, I'm 90% confident of my time and expense estimates, but only 70% confident of my scope estimates (typical agile focus on fixed time, variable scope).
In my experience "pure" agile gives me the highest probability of success, but simply isn't viable in every environment or for every project. In those cases I resort to impure agile :)
One of my guiding principals is the smaller the project (limited scope, short time duration) the greater the probability of success. However some projects (or perhaps more correctly some environments) simply don't lend themselves to a pure "agile" approach. In those cases I use a waterfall approach for initially defining requirements and generating a master plan for the project (project roadmap). However within that master plan I typically make provision for a series of agile initiatives.
Note I make EXTENSIVE use of ASSUMPTIONS! This is one of the most critical aspects of project planning, and also one of the most overlooked.
I develop a project risk profile that identifies (to some extent) the confidence interval to apply against the project constraints (time, scope, budget). So, for example, in the end, if my assumptions are correct, I'm 90% confident of my time and expense estimates, but only 70% confident of my scope estimates (typical agile focus on fixed time, variable scope).
In my experience "pure" agile gives me the highest probability of success, but simply isn't viable in every environment or for every project. In those cases I resort to impure agile :)
Axel Vanhooren
• @ Frederick
Hello Frederick,
Actually, there are some important nuances to your writing. Since the Agile community very often refer to this document "to proof" how well Agile is, I will expand a little bit to what I also read from these other sources about Agile and Dr Royces document.
Dr Royce is an interesting paper, but it is most often wrongly understood by the Agile community.
First of all, Dr Royce's paper doesn't concern software development in general. His paper is about his experience on software development in the space industry. It's about the specific organisation he worked for.
Then, his paper is about LARGE software development projects. Logically, Agile should be more suitable for smaller projects since different principles and techniques used in Agile are not really suitable for larger projects.
I do not recall Dr Royce mentioned changing requirements as an issue in his paper. However I do recall he mentions issues related to his particular context, namely the fact that one department is in charge of elaborating a complex computation resulting in a few lines of codes. An error in this small piece of code can with a pure sequential process and in that organisation only be detected at the end of the project. This means that that department must then redo its work. He also mention an issue that is more linked to the seventies (or earlier). He also mention issues related to the availability of limited hardware capability (timing, data storage and data transfer). These issues should better be solved upfront. But in 1970 and before, the hardware wasn't as powerful as it is today.
These issues has thus nothing to do with the reasons the Agile community are talking about.
He starts with drawing a waterfall-like process consisting of the phases: system requirements, software requirements, analysis, program design, coding, testing and finally operations. What he says that this process is risky and invites failure. But he also states that he believes in the concept!! Then he goes on with improving this process to deal with the risks he mentioned.
It is interesting to note that Dr Royce in the waterfall already include jumps to earlier stages. This means that design or requirements are not for 100% frozen and can be adapted. He also advices to start with an overall architecture/design which can be based on the requirements gather by then even if they are incomplete requirements. Apparently, since 1970 the waterfall can thus work with incomplete and unstable requirements. This should be one more revelation for the Agile proponents ;-)
To avoid late testing, the IT community inventing concepts like prototyping, user stories, use cases, mock-up screens, proof of concept, the V and W-testing models, .. This means that the business community have tools to follow the whole software process and to discover what the software will look like as the project progresses. If they don't, then it is a human problem and not a problem linked to the waterfall.
Dr Royce says that the waterfall is a fundamentally sound process, but, to cope with the particular risks he mentioned he adds 5 improvements that should solve them.
Dr Royce paper is an interesting starting point, but we must take into account that it is written in 1970 and for a specific situation. Meanwhile, IT has evolved.
Best regards,
Axel.
Hello Frederick,
Actually, there are some important nuances to your writing. Since the Agile community very often refer to this document "to proof" how well Agile is, I will expand a little bit to what I also read from these other sources about Agile and Dr Royces document.
Dr Royce is an interesting paper, but it is most often wrongly understood by the Agile community.
First of all, Dr Royce's paper doesn't concern software development in general. His paper is about his experience on software development in the space industry. It's about the specific organisation he worked for.
Then, his paper is about LARGE software development projects. Logically, Agile should be more suitable for smaller projects since different principles and techniques used in Agile are not really suitable for larger projects.
I do not recall Dr Royce mentioned changing requirements as an issue in his paper. However I do recall he mentions issues related to his particular context, namely the fact that one department is in charge of elaborating a complex computation resulting in a few lines of codes. An error in this small piece of code can with a pure sequential process and in that organisation only be detected at the end of the project. This means that that department must then redo its work. He also mention an issue that is more linked to the seventies (or earlier). He also mention issues related to the availability of limited hardware capability (timing, data storage and data transfer). These issues should better be solved upfront. But in 1970 and before, the hardware wasn't as powerful as it is today.
These issues has thus nothing to do with the reasons the Agile community are talking about.
He starts with drawing a waterfall-like process consisting of the phases: system requirements, software requirements, analysis, program design, coding, testing and finally operations. What he says that this process is risky and invites failure. But he also states that he believes in the concept!! Then he goes on with improving this process to deal with the risks he mentioned.
It is interesting to note that Dr Royce in the waterfall already include jumps to earlier stages. This means that design or requirements are not for 100% frozen and can be adapted. He also advices to start with an overall architecture/design which can be based on the requirements gather by then even if they are incomplete requirements. Apparently, since 1970 the waterfall can thus work with incomplete and unstable requirements. This should be one more revelation for the Agile proponents ;-)
To avoid late testing, the IT community inventing concepts like prototyping, user stories, use cases, mock-up screens, proof of concept, the V and W-testing models, .. This means that the business community have tools to follow the whole software process and to discover what the software will look like as the project progresses. If they don't, then it is a human problem and not a problem linked to the waterfall.
Dr Royce says that the waterfall is a fundamentally sound process, but, to cope with the particular risks he mentioned he adds 5 improvements that should solve them.
Dr Royce paper is an interesting starting point, but we must take into account that it is written in 1970 and for a specific situation. Meanwhile, IT has evolved.
Best regards,
Axel.
Art Jones • The sweet spot draws on both
Agile and Waterfall. Anastasia, Axel and Charles, I agree. I like good
waterfall projects that build in flexibility and real life through modelling,
change control, and rolling wave. Boring meetings can be amped up by engaging
Agile/SCRUM methods too.
Too often, I see waterfall painted solely as a heartless machine with no suspension, bulldozing hills, filling voids, intolerant, and single minded as it rolls over people. Projects managed this way die or run people off.
Too often, I see waterfall painted solely as a heartless machine with no suspension, bulldozing hills, filling voids, intolerant, and single minded as it rolls over people. Projects managed this way die or run people off.
Axel Vanhooren
• The document the Agile
community often refer to is named "Managing the Development of Large
Software Systems" and written in 1970 by Dr Winston W. Royce.
By googling the title on the web you can easily find it (pdf-file).
By googling the title on the web you can easily find it (pdf-file).
John (Jack) Stewart • As indicated
earlier, I like Agile/Scrum since the small sprints help reduce the inadequacy
of requirements when you are "creating" something. Waterfall is
better when the outcome is known (equipment installation, building a house) and
more predictable
Frederick Ayala • Hello Axel, thanks for
your comments.
I'm in agree with you, the paper is misunderstood. I wrote the "Common view" of Waterfall but indeed, Dr Winston W. Royce. wrote about iterations on the software lifecycle. We can see this in the "Figure 7. Step 3: Attempt to do the job twice - the first result provides an early simulation of the final product." of the paper.
Dear all, take a look at this video, it's called "The Rise And Fall Of Waterfall"
http://www.youtube.com/watch?v=X1c2--sP3o0
Anyways, companies should evaluate the unique characteristics of the project in order to decide if they are taking Waterfall, SCRUM or a mix of both.
Kind regards,
Frederick Ayala
I'm in agree with you, the paper is misunderstood. I wrote the "Common view" of Waterfall but indeed, Dr Winston W. Royce. wrote about iterations on the software lifecycle. We can see this in the "Figure 7. Step 3: Attempt to do the job twice - the first result provides an early simulation of the final product." of the paper.
Dear all, take a look at this video, it's called "The Rise And Fall Of Waterfall"
http://www.youtube.com/watch?v=X1c2--sP3o0
Anyways, companies should evaluate the unique characteristics of the project in order to decide if they are taking Waterfall, SCRUM or a mix of both.
Kind regards,
Frederick Ayala
John M. Mereness, Esq. • Design the
system to match the needs of the project and the people involved. I see too
much "we are going to do it X way" and all that does is flounder.
Thierry Labriet, PMP & IPMA-B • Hello!
How is it possible to associate stakeholder involvement with Agile approach? Does that mean that stakeholders are not or merely involved in waterfall approaches? No at all (I hope for all of us!!!).
For me the key distinction is the stakeholder expectation:
1) My project clients have a very good and non-negociable (we can dream!) idea of what they want --> I go with a waterfall approach: The scope is a given and the cost and time can be derived from the expected scope. That works fine with FP contracts.
2) My project clients have strong constraints on time and/or budget and would like to have the most valuable scope delivered within these given constraints --> I go with an agile/iterative approach. This fits very well with unclear requirements in the R&D or many IT projects for instance.
That is my personal experience.
In the given feedback, I record many interesting learnings though!
Many fruitful projects to all of you in 2013!
Thierry.
How is it possible to associate stakeholder involvement with Agile approach? Does that mean that stakeholders are not or merely involved in waterfall approaches? No at all (I hope for all of us!!!).
For me the key distinction is the stakeholder expectation:
1) My project clients have a very good and non-negociable (we can dream!) idea of what they want --> I go with a waterfall approach: The scope is a given and the cost and time can be derived from the expected scope. That works fine with FP contracts.
2) My project clients have strong constraints on time and/or budget and would like to have the most valuable scope delivered within these given constraints --> I go with an agile/iterative approach. This fits very well with unclear requirements in the R&D or many IT projects for instance.
That is my personal experience.
In the given feedback, I record many interesting learnings though!
Many fruitful projects to all of you in 2013!
Thierry.
David Lahuerta Clemente, PMP • Hi all,
Just come from a training on PMI - ACP and I think there is a general mix (confusion) between project management and product development... and the use of lifecycles for them.
Key points for me on the discussion:
1.- Most of ideas behind Agile Manifesto are good ones and common sense, no one can deny, but...
2.- I agree Predictive and Adaptative PM are not mutually exclusive, Well managed waterfall can be as Agile as Scrum, and viceversa
3.- In Agile the less "sexy" subjects of Project Management are neglected (Communications, Risks, Financial aspects, etc) To me is synthom of poor Management
4.- I am not comfortable with the way Agile is presented "against" Predictive PM, it seems like there is no posibility to change at all in PMBoK... but what is change management for? Not all is written on stone ;-))
Finally, the point that makes me unsure about agile is the fact that, being so flexible with requirements, you might end up with something totally different to what is required.
This can be ok sometimes, but some others... if you want to build a plane, and you finish with a bridge, that's beyond project management... :)
Regards,
David
Just come from a training on PMI - ACP and I think there is a general mix (confusion) between project management and product development... and the use of lifecycles for them.
Key points for me on the discussion:
1.- Most of ideas behind Agile Manifesto are good ones and common sense, no one can deny, but...
2.- I agree Predictive and Adaptative PM are not mutually exclusive, Well managed waterfall can be as Agile as Scrum, and viceversa
3.- In Agile the less "sexy" subjects of Project Management are neglected (Communications, Risks, Financial aspects, etc) To me is synthom of poor Management
4.- I am not comfortable with the way Agile is presented "against" Predictive PM, it seems like there is no posibility to change at all in PMBoK... but what is change management for? Not all is written on stone ;-))
Finally, the point that makes me unsure about agile is the fact that, being so flexible with requirements, you might end up with something totally different to what is required.
This can be ok sometimes, but some others... if you want to build a plane, and you finish with a bridge, that's beyond project management... :)
Regards,
David
Paul Hulme •
Use something like the DSDM
questionnaire to help you decide (you can substitute "Agile" for DSDM
Atern in that questionnaire if not using DSDM).
http://www.dsdm.org/wp-content/uploads/2010/11/template_project_approach_questionnaire.xls
Cheers,
Paul.
http://www.dsdm.org/wp-content/uploads/2010/11/template_project_approach_questionnaire.xls
Cheers,
Paul.
Robert W. Cooper • Both the Waterfall
method and the Agile method of software development have their uses. Although
Agile arose as a reaction to the limitations imposed by the Waterfall method,
Waterfall still retains its relevance as a better method when the environment
is stable with no room for changes, when frequent interactions with ends users
and other stakeholders are not possible, or when there is a risk of key
developers quitting the project midway.
Agile is a lightweight method. As software developers focus on smaller work areas, overhead becomes less, and the project costs considerably less than when using the Waterfall method. When customer requirements are hazy, or the business environment is uncertain, Agile methods that allow making frequent changes, and testing during the construction stage remains the best choice. Successful execution of Agile projects nevertheless requires highly skilled and competent developers, and stakeholders who know what they want. With the scope to accommodate changes, an Agile project can easily lose its way.
http://www.brighthubpm.com/agile/50473-agile-vs-waterfall-is-there-a-real-winner/
Agile is a lightweight method. As software developers focus on smaller work areas, overhead becomes less, and the project costs considerably less than when using the Waterfall method. When customer requirements are hazy, or the business environment is uncertain, Agile methods that allow making frequent changes, and testing during the construction stage remains the best choice. Successful execution of Agile projects nevertheless requires highly skilled and competent developers, and stakeholders who know what they want. With the scope to accommodate changes, an Agile project can easily lose its way.
http://www.brighthubpm.com/agile/50473-agile-vs-waterfall-is-there-a-real-winner/
Manoj Vadakkan
• Hello David L,
I appreciate your comments and it sounds like you had some great discussions in the ACP training session ( btw, I also conduct ACP trainings :-)
I also use to be an Adaptive Project Manager before even discovering Agile.
Yes, I agree, there is Change Management, there is process for that when we need to change. To me, Agile says, there is going to be change for sure. So lets put the process together such a way that we welcome change. Feature Driven Development is helping us to do just that - or call that progressive elaboration.
The "less sexy subjects": If you take the case of Scrum. Yes, they are not explicitly prescribed in Scrum. That is to keep it simple and keep it in such a way that organizations can do whatever that fit within their organization, projects, and need.
Liked your analogy of starting with a Plane and ending with a bridge: :-) I see it as a good thing assuming it is the customer who was in control when changing the plan. I woud argue that if we are doing frequent delivery and have more involvement with the customer as Agile asks us to do, we will figure this out earlier than later.
Cheers!
Manoj
I appreciate your comments and it sounds like you had some great discussions in the ACP training session ( btw, I also conduct ACP trainings :-)
I also use to be an Adaptive Project Manager before even discovering Agile.
Yes, I agree, there is Change Management, there is process for that when we need to change. To me, Agile says, there is going to be change for sure. So lets put the process together such a way that we welcome change. Feature Driven Development is helping us to do just that - or call that progressive elaboration.
The "less sexy subjects": If you take the case of Scrum. Yes, they are not explicitly prescribed in Scrum. That is to keep it simple and keep it in such a way that organizations can do whatever that fit within their organization, projects, and need.
Liked your analogy of starting with a Plane and ending with a bridge: :-) I see it as a good thing assuming it is the customer who was in control when changing the plan. I woud argue that if we are doing frequent delivery and have more involvement with the customer as Agile asks us to do, we will figure this out earlier than later.
Cheers!
Manoj
Scott Albers
• #1 Rohit mentioned
Scope Creep as a weakness of Agile Scrum: It depends on the environment. I used
Scrum to protect AGAINST scope creep with a small firm's CEO who is an R&D
Neuro-Scientist: I defined sprints as "once in motion, nothing of the plan
changes" within that sprint. Which allowed at least a couple weeks to let
the "burning new idea" factor of a new change idea cool off and an
opportunity to collect and discuss the pros and cons of adding the change on
the next sprint. Imaginary boundary? Perhaps, but it was a key to that
project's success.
#2 This discussion is "Agile vs. Waterfall" - however I have yet to meet anyone who is actively using pure Scrum. Everyone does a hybrid, form-follows-funciton approach. And why not? As long as what parts of what are clearly understood by all parties and it serves to optimize the outcome.
Has anyone come across a archetypal hybrid that could be used as a template?
#2 This discussion is "Agile vs. Waterfall" - however I have yet to meet anyone who is actively using pure Scrum. Everyone does a hybrid, form-follows-funciton approach. And why not? As long as what parts of what are clearly understood by all parties and it serves to optimize the outcome.
Has anyone come across a archetypal hybrid that could be used as a template?
Sanjay Gupta, PMP • @Frederick
Ayala: You pointed out the key aspect of the Agile. Requirement begins with a
metaphor in the form of user stories and then design and development gets
completed for each sprint while rests of the stories are being evolved.
It gives customer enough flexibility to focus on key aspect immediately and working on less important one as time progress.
We can also compare it with Pareto analysis, which tells us that 80% of problems can be addressed if we focus on 20% of key issues and addressed them effectively. This principle can be used in Agile as well. If we focus on 20% key requirement at a time then we will be able to deliver maximum value to our customer.
-Sanjay
It gives customer enough flexibility to focus on key aspect immediately and working on less important one as time progress.
We can also compare it with Pareto analysis, which tells us that 80% of problems can be addressed if we focus on 20% of key issues and addressed them effectively. This principle can be used in Agile as well. If we focus on 20% key requirement at a time then we will be able to deliver maximum value to our customer.
-Sanjay
David Lahuerta Clemente, PMP • Manoj,
Thanks for your comments, this:
"lets put the process together such a way that we welcome change"
Is probably the most sensible explanation read so far. But then this:
[...] to keep it simple and keep it in such a way that organizations can do whatever that fit [...]
Takes me back to the idea that this is no mature project management... Kind of "as I do not like it, I forget about it" mindset. (I know, I am being a little provocative here...)
Scott:
You just highlighted one of the paradox I find in Agile... on one side, A. Manifesto says "we welcome changes" but then "once in motion, nothing of the plan changes"
So, not all changes all times (exactly as in traditional Project Management) To me, this is is perfect... but can be for an iteration in Scrum, or as well for one "fall" in waterfall... :) so then, what is really the diference?
Interesting post, thanks to all.
David
Thanks for your comments, this:
"lets put the process together such a way that we welcome change"
Is probably the most sensible explanation read so far. But then this:
[...] to keep it simple and keep it in such a way that organizations can do whatever that fit [...]
Takes me back to the idea that this is no mature project management... Kind of "as I do not like it, I forget about it" mindset. (I know, I am being a little provocative here...)
Scott:
You just highlighted one of the paradox I find in Agile... on one side, A. Manifesto says "we welcome changes" but then "once in motion, nothing of the plan changes"
So, not all changes all times (exactly as in traditional Project Management) To me, this is is perfect... but can be for an iteration in Scrum, or as well for one "fall" in waterfall... :) so then, what is really the diference?
Interesting post, thanks to all.
David
Sanjay Gupta, PMP • @Subbu: Your
point is valid and Ivo has responded very well to your query. Regarding design
change, Agile has one more principle of keeping the design simple and good
collaboration among designer and developer. Once initial framework is designed
then there is very less chance that any change in requirement will impact the
design heavily. It may be a slight change.
But, whatever is the impact, it needs to be implemented because delivering value i.e. customer requirement is the key behind the Agile methodology instead of resisting change due to design change or impact on schedule etc.
Since customer is involved very closely with the project hence all these aspect needs to be discussed with customer and make decision, which provides maximum value to customer.
- Sanjay
But, whatever is the impact, it needs to be implemented because delivering value i.e. customer requirement is the key behind the Agile methodology instead of resisting change due to design change or impact on schedule etc.
Since customer is involved very closely with the project hence all these aspect needs to be discussed with customer and make decision, which provides maximum value to customer.
- Sanjay
madhusudhanreddy yannakandla • waterfall
method stands for predictability, while Agile methodology spells adaptability. Agile
methods are good at reducing overheads, such as, rationale, justification,
documentation and meetings, keeping them as low as is possible. And, that is
why Agile methods benefit small teams with constantly changing requirements,
rather more than larger projects.
Once a stage is completed in the Waterfall method, there is no going back, since most software designed and implemented under the waterfall method is hard to change according to time and user needs. The problem can only be fixed by going back and designing an entirely new system, a very costly and inefficient method. Whereas, Agile methods adapt to change, as at the end of each stage, the logical programme, designed to cope and adapt to new ideas from the outset, allows changes to be made easily. With Agile, changes can be made if necessary without getting the entire programme rewritten. This approach not only reduces overheads, it also helps in the upgrading of programmes.
http://agileintro.wordpress.com/2008/01/04/waterfall-vs-agile-methodology/
go through above link get more information about to methods
--Y.Madhusudhan Reddy
Once a stage is completed in the Waterfall method, there is no going back, since most software designed and implemented under the waterfall method is hard to change according to time and user needs. The problem can only be fixed by going back and designing an entirely new system, a very costly and inefficient method. Whereas, Agile methods adapt to change, as at the end of each stage, the logical programme, designed to cope and adapt to new ideas from the outset, allows changes to be made easily. With Agile, changes can be made if necessary without getting the entire programme rewritten. This approach not only reduces overheads, it also helps in the upgrading of programmes.
http://agileintro.wordpress.com/2008/01/04/waterfall-vs-agile-methodology/
go through above link get more information about to methods
--Y.Madhusudhan Reddy
Manoj Vadakkan
• Hello David,
"[...] to keep it simple and keep it in such a way that organizations can do whatever that fit [...] " ....Takes me back to the idea that this is no mature project management..
Let me explain: I didn't mean to say that - people get to do whatever they want to do. What I meant to say is that, when speaking of Scrum, Scrum itself doesn't specify every details of every pieces of the process. For example, it doesn't tell the team to test the software. But Scrum is used more often for Software development. What that means is that Scrum doesn't prescribe all the details of everything. It keep it to the bare minimum.
It leaves it up to the organization to fill that gap. And that needs to be filed.
"[...] to keep it simple and keep it in such a way that organizations can do whatever that fit [...] " ....Takes me back to the idea that this is no mature project management..
Let me explain: I didn't mean to say that - people get to do whatever they want to do. What I meant to say is that, when speaking of Scrum, Scrum itself doesn't specify every details of every pieces of the process. For example, it doesn't tell the team to test the software. But Scrum is used more often for Software development. What that means is that Scrum doesn't prescribe all the details of everything. It keep it to the bare minimum.
It leaves it up to the organization to fill that gap. And that needs to be filed.
Manoj Vadakkan
• Interestingly, even
after a decade of defining Agile, we still have this discussion. More often
than not, it end up as a religious discussion of what is better? Have any one
seen this before ? :-)
To me, it is not a question of what is better or what is the difference. Being Agile is not even a goal for me. Being better organization that delight the customer ( and hopefully make a ton of money too in the process!) is a better goal. To that end, I would ask the question: is that current way of working, doing business, organizing teams, delivering products working? If it is, don't changing anything. On the other hand, if it is not working, if we do need to make some changes, well, then identify those changes. What are those results you are after? Ideas under the Agile umbrella might give you some tools and techniques to help you get there.
To me, it is not a question of what is better or what is the difference. Being Agile is not even a goal for me. Being better organization that delight the customer ( and hopefully make a ton of money too in the process!) is a better goal. To that end, I would ask the question: is that current way of working, doing business, organizing teams, delivering products working? If it is, don't changing anything. On the other hand, if it is not working, if we do need to make some changes, well, then identify those changes. What are those results you are after? Ideas under the Agile umbrella might give you some tools and techniques to help you get there.
Jeff Schreck
• Isnt saying
"Agile vs Waterall" like saying Chevrolet vs Samsung? Do the two
really apply in comparison? Waterfall is a fairly ridged and well defined
method. Requirement, Design, Implement, Verify, Maintain... or some variant of
that. Where Agile is a concept, not really a method.
That being said, I don't think either ideal exists in purity, nor do I think it is possible to execute either ideal... the kludge we get someplace in the middle is typically more effective.
That being said, I don't think either ideal exists in purity, nor do I think it is possible to execute either ideal... the kludge we get someplace in the middle is typically more effective.
Axel Vanhooren • Maybe I
would use Agile for small user-oriented software acting locally (eg personal
information managers, small social media apps, ...), or when there is a need to
enrich larger software systems with user-oriented features.
But I would definitely avoid it when it comes to more serious corporate IT systems or critical systems. Then a more systematic and structured approach is more appropriate.
But I would definitely avoid it when it comes to more serious corporate IT systems or critical systems. Then a more systematic and structured approach is more appropriate.
Johan Johansson • I think it's
important to consider budget relative to technical complexity (for software or
websites). I've written detailed specifications that were simply not read or
ignored by freelance developers because the project didn't have enough of a
budget for them to care. A few years ago I adopted an agile method for lower
budget projects with simpler requirements, and have seen marginal difference in
quality and turnaround time relative to using the waterfall method.
Neel Gautam PMP, CSSGB, ITIL V3, MCTS, MCAD, MCP • First of all, great question and awesome discussion so
far :). Obviously, these two are bound to cross boundaries and not mutually
exclusive per say. However, let’s assume (for the sake of responding to the
question) that they can be clearly separated and are mutually exclusive. Of
course, it is so tempting to use those two words “it depends”; yet I’ll take a
stab at it by sharing my 2 cents.
1) What do you think is the key differentiator between Agile Vs waterfall model in project management
-- Waterfall methodology to me is more targeted towards long term system/application stability whereas Agile philosophy seems more on setting things in motion, realizing faster Return On Investment.
-- Stakeholder buy-in and involvement.
2) What should be the criteria to choose one of the model for a specific project?
-- Choose Waterfall
* IMHO better for larger projects/releases or with a large team (I’d say over 15-20 resources).
* Better for really complex projects as requirements are clearly defined in one place. For large projects with complex requirements, agile seems to create confusion down the road (20 sprints later, no-one really knows the big picture as all requirements are broken into stories and use-cases).
* Generally better suited for start-up projects, big projects, global deployments, larger teams with multiple geographies.
* Better choice when you’ve room to build and develop the team and their skills.
* Clearly defined Gate (Entry/Exit) criteria.
-- Choose Agile
* Ideal for non-start up Project (incremental enhancement/operations releases).
* Ideal for smaller teams (up to 20 resources MAX).
* Better choice when team can work cohesively as efficient and effective unit (even better when team members have worked with each other for a bit).
* Works best when you have solid buy-ins from stakeholders and they are actively participating.
* Team needs to be highly skilled and there tend to be almost no time for learning curve in sprints.
It’s so dangerous to generalize particular methodology/philosophy to particular type of projects etc… but, having said all that; there; I’ve said what I wanted to on Agile v/s Waterfall! I’ll run for cover now!!!!
1) What do you think is the key differentiator between Agile Vs waterfall model in project management
-- Waterfall methodology to me is more targeted towards long term system/application stability whereas Agile philosophy seems more on setting things in motion, realizing faster Return On Investment.
-- Stakeholder buy-in and involvement.
2) What should be the criteria to choose one of the model for a specific project?
-- Choose Waterfall
* IMHO better for larger projects/releases or with a large team (I’d say over 15-20 resources).
* Better for really complex projects as requirements are clearly defined in one place. For large projects with complex requirements, agile seems to create confusion down the road (20 sprints later, no-one really knows the big picture as all requirements are broken into stories and use-cases).
* Generally better suited for start-up projects, big projects, global deployments, larger teams with multiple geographies.
* Better choice when you’ve room to build and develop the team and their skills.
* Clearly defined Gate (Entry/Exit) criteria.
-- Choose Agile
* Ideal for non-start up Project (incremental enhancement/operations releases).
* Ideal for smaller teams (up to 20 resources MAX).
* Better choice when team can work cohesively as efficient and effective unit (even better when team members have worked with each other for a bit).
* Works best when you have solid buy-ins from stakeholders and they are actively participating.
* Team needs to be highly skilled and there tend to be almost no time for learning curve in sprints.
It’s so dangerous to generalize particular methodology/philosophy to particular type of projects etc… but, having said all that; there; I’ve said what I wanted to on Agile v/s Waterfall! I’ll run for cover now!!!!
Art Jones • I associate rigidity and
adaptability with the person, not these tools. A grumpy purist PM can turn any
process or tool into some painful torture. "When all you have is a hammer,
everything looks like a nail." PMP, SDLC and Waterfall describe a shop
full of tools. Some projects require 1 or 2, and you are done. You seldom use
all of them. I like this description of a colleague in Jacksonville, John Watson. Agile and SCRUM
can easily become tools of torture as well. Been there, seen the pain too.
Unwittingly, I use Agile methods, I have conducted SCRUMs unknowingly to meet deadlines. Mind you it was not the SCRUM in a purist sense. AND some of my projects may not appear as SDLC by those purists as well.
Unwittingly, I use Agile methods, I have conducted SCRUMs unknowingly to meet deadlines. Mind you it was not the SCRUM in a purist sense. AND some of my projects may not appear as SDLC by those purists as well.
Shahbaz Khan
• In today's dynamic
world, static management approach brings staleness to the practice of project
development. While you cannot go about doing agile or prototype based
development in a construction project, projects within the IT, business,
process and research based programs are ideal. But the main issue is that at
what point will there be the acceptability or completion be ascertained? There
can be situation where endless changes may plague a project believing we are
always on a path to agility. Somewhere along the line is a need for vetting of
the fact that project has ended because primary goals and objectives of the
projects have been met. Another issue within agile approach is the level of
acceptance of disruption of normal operations when stakeholders are intimately
involved in a project utilizing agile methodology. Depending on type of
operations, not all stakeholders are a great fan of the approach.
Omar D'Angelo, P.Eng • I come from
the Aerospace sector and depending on the size of the project, either or both
could be used. For large projects with well defined SOW, I believe the
waterfall approach is better, particularly when dealing with your client. The
SOW is usually very well defined and key requirements should not be evolving
with the product; implementing Agile (in my opinion) would introduce unwanted
flexibility at this level. You could still implement an Agile methodology
internally once requirements are sufficiently broken down and prioritized (per
system, or other logical subdivision) to be managed as smaller, individual
projects. Later in the project Agile would be appropriate for managing
deficiencies where they can also be grouped and managed as small projects. For
other projects in which requirements are constantly being added (hopefully new
rather than changing), Agile is certainly an excellent approach.
Geen opmerkingen:
Een reactie posten