Project Management Central
|
Please login or join to subscribe to this thread
|
||||
|
||||
Mature organizations will have a project profiling capability to help teams determine an appropriate lifecycle based on the project's context as opposed to forcing teams to pick waterfall or agile as few projects are a perfect fit for either extreme.
Of course, an agile mindset should be applied to every project... Kiron
There is a problem here. Agile can be used with any type of life cycle. Waterfall for example. Agile like Lean are way of thinking and behavor. Waterfall is a life cycle. No matter that I know the PMI has introduced a life cycle called agile which is a iterative-incremental life cycle.
I would suggest to discuss about predictive, iteractive, incremental and Agile approaches. Agle approach is related to combine both (interactive + Incremental).
in my case I identified different factors to choose one approach or other. some key factors i use are: 1. The organizations related to the project. if I have an organization in agile and another in waterfall aproach and I need to mix both organizations In the same project I need to decide with them the project approach and most of the case ends in an hybrid model 2. the type of product I am producing in the project. some products are easier to cut in an interactive approach, others are more incremental and in some cases doing predictive approach is more effective and less risky 3. the teams involved. multicultural colocated, big teams are not easy to syncronize in short sprints. 4. the knowledge and experience that the organization has in the kind of project, new technologies and new scenarios are not easy to manage in predictive and experimental models that mix innovation techniques are more useful in those cases. ...
2 replies by Sergio Luis Conte and Stelian ROMAN
Jul 26, 2019 6:47 AM
Sergio Luis Conte
...
You put a great point on the table. The article said nothing (as usual) regarding the real key factors to decide about an approach: all you do inside an organization is about to solve a problem which emerges when organizational needs emerges because the need to put strategy on action. The approach must be defined with focus on that. So, if we like to put all these stuff in terms of PMI´s roles to do that belongs to Business Analysis and is called "needs analisys" inside the PMI standard. Key is to analyze the current situation plus the type of product/service/result to create. BUT mainly is to understand what Agile really is.
Here some articles I wrote and were published by the PMI and others and cited lot of times, the first one as "best practices for best business analysis". I am sharing them with the hope to receive feedback and improve myself. What agile really is: http://www.pmnetwork-digital.com/pmnetwork/april_2016?pg=73#pg73 How to define a solution (to use or not to use agile for example): https://www.projectmanagement.com/blog-pos...-right-solution Jul 28, 2019 3:37 AM
Stelian ROMAN
...
What is 'interactive'?
In the interview linked above, Katie Sierzego says, "It’s about using the right tool for the right job. I use waterfall processes when outcomes are predictable and uncertainties are at a minimum, like with server deployments or data center builds or expansions. I leverage agile for software development and building out capabilities incrementally—projects where I focus on tight feedback loops and where the enduser representatives are available and interested in being deeply involved in the product’s evolution. And sometimes we use a combination of both, like if we develop a base product using waterfall but then customize it using agile.
It’s imperative that our project delivery teams have a breadth of understanding of project delivery approaches so they can apply each one, or a hybrid of them, as appropriate. ...
1 reply by Lukas Dohnansky
Jul 29, 2019 9:11 AM
Lukas Dohnansky
...
Do you have an experience with the example at the end of your comment?
"And sometimes we use a combination of both, like if we develop a base product using waterfall but then customize it using agile." As we know some cons and pros of agile approach, then we should be aware to use agile along with the delivery contract, where deadline is specified. Usually when we see a deadline on the contract, its means a big NO to involve an agile tooling. But ... To stay solid,add a value and stay competitive there is always a place for some custom features developed for the customer. So we put it inside the scope to get a contract in a purpose to develop it in time. Could somebody share some experience with the waterfall project which include development (developed feature is in the scope)? As we well know, development always take some risks with the time and delivery estimation. In that case it could affect contract delivery term hardly. Could somebody describe this kind of hybrid approach? How do you react if development ruining your waterfall project plan? Specially in Europe, customers are not so open to do an IT solution delivery project with indistinct delivery term (not specified in contract).
Call it Agile, agile or banana if you want. The point being that as PM's we should all learn to use what works instead of spending hours, weeks, months or years deciding what it is or is not. I like what Katie says - use the right tool for the right job. Instead of fretting about what ceremonies I should be using to make it agile or not I look at the job and use whatever will get the job done efficiently. If it means that I have to SIT down for a meeting on an Agile project then that is what I do :) If it means that I need to write a user story on a waterfall project then I do.
...
1 reply by Sergio Luis Conte
Jul 26, 2019 6:52 AM
Sergio Luis Conte
...
You hit the mail @Anton. Unfortunatelly today if people do not use the word Agile what everything they said they are consider ugly, bad, dirty and our of fashion. This created a lot of missunderstanding outside there and jeopardizes the work of people like me that are using agile from 1995. For example, think that writing user stories is being agile is a big mistake. As you mentioned (and as I do in my actual work place) you can use it as a tool no matter the approach you are folllowing. Think that put a piece of paper with collorful posit is being agile is other missunderstanding. As we know, we have tools and techniques that we can use independently of the life cycle and approach we use.
Jul 25, 2019 10:08 PM
Replying to Dora Mejia
...
I would suggest to discuss about predictive, iteractive, incremental and Agile approaches. Agle approach is related to combine both (interactive + Incremental).
in my case I identified different factors to choose one approach or other. some key factors i use are: 1. The organizations related to the project. if I have an organization in agile and another in waterfall aproach and I need to mix both organizations In the same project I need to decide with them the project approach and most of the case ends in an hybrid model 2. the type of product I am producing in the project. some products are easier to cut in an interactive approach, others are more incremental and in some cases doing predictive approach is more effective and less risky 3. the teams involved. multicultural colocated, big teams are not easy to syncronize in short sprints. 4. the knowledge and experience that the organization has in the kind of project, new technologies and new scenarios are not easy to manage in predictive and experimental models that mix innovation techniques are more useful in those cases. Here some articles I wrote and were published by the PMI and others and cited lot of times, the first one as "best practices for best business analysis". I am sharing them with the hope to receive feedback and improve myself. What agile really is: http://www.pmnetwork-digital.com/pmnetwork/april_2016?pg=73#pg73 How to define a solution (to use or not to use agile for example): https://www.projectmanagement.com/blog-pos...-right-solution Jul 26, 2019 12:41 AM
Replying to Anton Oosthuizen
...
Call it Agile, agile or banana if you want. The point being that as PM's we should all learn to use what works instead of spending hours, weeks, months or years deciding what it is or is not. I like what Katie says - use the right tool for the right job. Instead of fretting about what ceremonies I should be using to make it agile or not I look at the job and use whatever will get the job done efficiently. If it means that I have to SIT down for a meeting on an Agile project then that is what I do :) If it means that I need to write a user story on a waterfall project then I do.
The PMI Agile Practice Guide, bundled with PMBoK ed 6, contains an Appendix A3 with Agile Suitability Filter Tools, looking at 9 criteria grouped into Team, Project, Culture sections.
It is based on work from DSDM/Crystal in the 1990s. ...
2 replies by Sergio Luis Conte and Stelian ROMAN
Jul 26, 2019 9:51 AM
Sergio Luis Conte
...
Crystal Clear is something deserves to be read and understanding in detail when people tried to use agile.
Jul 28, 2019 3:37 AM
Stelian ROMAN
...
One more reason to be updated,,,
Jul 26, 2019 8:09 AM
Replying to Thomas Walenta
...
The PMI Agile Practice Guide, bundled with PMBoK ed 6, contains an Appendix A3 with Agile Suitability Filter Tools, looking at 9 criteria grouped into Team, Project, Culture sections.
It is based on work from DSDM/Crystal in the 1990s.
Just to muddy the waters, let me add that a project manager may rarely have the authority to make these decisions independent of the organizational culture. You can't merely choose to "do Agile" if your company is not agile. You have to consult with your customer, your stakeholders, and your team when you establish the project. If you make these decisions independently from others, you'll likely fail.
Now to contradict myself: if you're a trusted project manager, you'll likely have some influence on your customer, stakeholders, and team. I'd recommend you avoid words like "waterfall," "agile," or "hybrid." Simply consider the requirements and the unknowns (risks) of your project, and recommend a pragmatic approach that best suits the situation. If you have a short duration project with relatively few unknowns, setup a predictive (waterfall) project and run with it. If you're dealing with a complex, long-term project with a large number of unknowns, then find a way to decompose your requirements so you can complete some work increments while you find answers. If you're in a volatile marketplace, you should established short duration iterations so you can react to changing conditions. Explain your recommendations like you're talking to a group of 3rd graders, and see if you can get some mutual consent from everyone involved. ...
1 reply by Jose Gonzalez
Jul 26, 2019 2:15 PM
Jose Gonzalez
...
Hi all.
I agree with Wade. Today I don't think you should ask what approach is used, but what tools we need considering two variables. 1. Knowledge of the requirements of the deliverables. The more details and certainty there is of the project deliverables, the more predictive approach should be used, but if it is not clear the project deliverables, the more adaptive approach should be used. 2. The technology to use. If it is a known technology, more cascade is used and the more unknown technology exists, more agile approaches and tools are used. I maintain that they are all tools that the PM and team must define which and at what time to use within the project life cycle. So for me all projects use a hybrid approach and tools according to need |
||||
Please login or join to reply
ADVERTISEMENTS
|
"A fanatic is one who can't change his mind and won't change the subject." - Winston Churchill |
