Please login or join to subscribe to this thread
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
Already noted, but what I always say, right tool for the right job. As we learn more, we can apply those learnings in subsequent projects. There's a reason there's more that one type of hammer. Of course, there is also consideration in maturity of the organization and/or stakeholders. All in all, learning/maturing process.
Even fixed bid, waterfall-style projects can benefit from Lean, Agile, and Scrum practices like user stories, Scrum boards, daily stand-ups, frequent retrospectives, and colocation. Just because a project can be effectively implemented without these, doesn't mean it can't be done even better with them.
In my opinion first, we change the game a little (which is what most software development organizations do) by defining our own process. Let say, it’s called our Process Framework, and it’s a variation on the traditional Waterfall methodology. Our modifications include use of prototyping where possible to provide the customer with a better view of their finished product early in the design/development cycle. This helps to improve the team’s understanding of requirements and communication with the customer. After the primary framework of the application is completed per high-level requirements, we continue to develop and also to reach out to the customer for refinement of requirements. In this way, we strive to be as iterative as possible without compromising our overall system architecture. We consider the following factors when considering which methodology to use & project treat/ factor, such as customer availability, scope/ features, feature prioritization, team, funding & summary. They are not equally weighted, each is assessed depending on the individual project and circumstances.
Depends on your previous experience implementing a project using these methodologies and the lessons learned from them. Everyone will have an opinion on what methodology you should use on XYZ project but ultimately the best fit for the project may not be the best fit for the project manager. Some projects lend naturally to a waterfall methodology such as in the public sector when a predictable deliverable known well in advanced by all stakeholders is the preferred approach. In the private sector a agile methodology is sometimes the preferred approach as competitors, strict budgets and managing resources requires Project Managers to be flexible and deliver incremental continuous deliverables at regular interval. A hybrid approach as a methodology is used in more mature organisations were the timescales for deliverables is pushed out to ensure larger incremental deliverable that involves all stakeholders that have been tested completely to ensure integrity of systems.
Hybrid projects are not new in IT, In small organisations Agile is the norm for over 20 years. Most IT projects that have a software deliverable used alsp Agile.
The challenge is when non technical people try to use Agile in Business Projects because all the known Agile frameworks are developed by software practitioners or even worst consultants that never delivered a real project,
There is no magic checklist because Agile is by definition adaptive.
In a sort of paradox scaling Agile is going backwards to Lean, an approach that in manufacturing triggered the development of Agile in late century (70's-80's). Teams discover that at the enterprise level most of Agile 'metrics' make no sense. Story points, velocity, burn-down charts don't have any value. Kanban, SAFe (defined as a Lean Agile oxymoron) and DevOps are Lean rather than Agile.
One of the root causes of the Agile going backwards is that it is promoted by people (coaches and trainers) without practical experience. With all due respect an empirical approach can't be learned in the classroom and to teach Agile you need to have past experience as responsible for delivering a project or a product.
Avoiding the PM -speak is best approach and deliver based on the objectives of the projects. My experience has been that the business community is not interested in any methodology.
An experienced project manager will use acquired expertise to deliver the "project" regardless of the methodology. Have we ever asked McDonald which method they use to harvest their potatoes? But I can assure you the french fries are the best. Focus on the objectives of the project and use your knowledge to intelligently deliver the project.
Agile and Hybrid were whitewater rafting one day (on a bonding excursion) when they noticed a sign stating “Danger: Waterfall Ahead.” Agile, recognizing a teachable moment, told Hybrid that the rigid structure of the upcoming Waterfall posed an extreme danger to the general public, but that they had full indemnification from injury due to their flexibility.
Hybrid, recognizing Agile’s emotionally driven statement, expressed the risk-outcome this opinion would have on their immediate wellbeing. Undeterred, Agile (still in the teachable moment) insisted that they accept this risk and move forward, while Hybrid - hearing a rumbling in the distance, recommended an immediate strategy of avoidance.
How does this story end? ;)
Agile purists (as a whole) view waterfall approaches as the epitome of project evil and immediately take the contra view on a given subject if they sense anything that gives validity to a waterfall (e.g., a sign stating - waterfall ahead) – oh, now I get it.
The views stated in this thread are excellent (some of which are - excuse the paraphrasing):
- Agile is a mindset, behavior and/or a way of thinking (Kiron and Sergio)
- Agile can be used on any type of life-cycle (Sergio)
- Waterfall projects can benefit from Lean, Agile, and Scrum practices (Eric).
- It’s about using the right tool for the right job (Katie, Dora, Anton, Andrew)
- If you don’t use the word Agile, your approach is considered less than optimal (although Sergio used more descriptive terms).
- I recommend you avoid words like; waterfall, agile or hybrid (Wade, Jose)
- Change the game a little, call it “Your Process Framework.” (Muhammad)
- Ultimately, the best fit for the project may not be the best fit for the project manager (Daire).
- Agile is the norm is small organizations but doesn’t necessarily scale well for the enterprise – speaking to the metrics (Stelian).
- An experienced project manager will use acquired expertise to deliver the "project" regardless of the methodology (Jerry)
- All projects use a Hybrid approach (Jose)
To Aaron’s question: I believe (along with many on this thread) that there is NO pure Agile or Waterfall project. Instead, projects are by nature Hybrid (being a generic term) as that is our mandate as a project manager - to pull together that which is necessary from a process and practice perspective to meet the specific needs of our project/product.
Thank you Aaron for a great question!
Please login or join to reply