November 5, 2020, 8:30 a.m. to 6 p.m. EDT | November 6, 2020 – February 7, 2021, On-Demand | Online Conference
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...
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.
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.
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.
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:
How to define a solution (to use or not to use agile for example):
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.
Please login or join to reply