September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
There are infinite patterns for hybrid projects as it varies by domain and by what portions are adaptive and what portions are predictive.
Two common patterns are:
1. Specific sub-projects/workstreams are delivered in an agile manner whereas others are delivered in a waterfall manner with no/some/heavy integration between those.
2. Water-Scrum-Fall, Water-Scrum, Scrum-Fall - in all of these, the same set of requirements is partially delivered using agile approaches and partially delivered using traditional approaches.
On the continuum, very few projects outside of pure software development from the ground up are "full" agile.
In our Real Estate Development / Construction projects, we use Waterfall-Agile Hybrid Approach.
Our Agile portion of the hybrid approach is close to the DSDM framework and mostly applied during the design phase. The waterfall kicks-in heavily after breaking grounds.
There is Niagara-Fall too, have you heard of it ? :D
Hi Susan - I have used in system implementation projects a hybrid model with more traditional efforts to start and finish (discovery and UAT) while using Scrum in execution.
For many projects that had worked really well. Typically in two scenarios; one with an organization or department completely knew to a different approach, and two, as a vendor, having a repeatable approach across multiple clients and having enough up front planning to support an SOW and budget.
Susan, I do not advocate or follow any specific pattern because I strongly believe that we need to adopt an approach that works. You can apply the basic premise of "high uncertainty = adaptive, low uncertainty = predictive" to put you into the right space but then you need to understand the needs of your stakeholders and apply that when deciding how adaptive or predictive you should/can be. If you are working on a piece where there is little uncertainty and you have a stakeholder(group) who are not in the Agile boat it makes no sense trying to convert them because we need to demonstrate our command over the latest buzz. We tend to forget or ignore the needs of our stakeholders when deciding on an approach.
This is my situation from years including it I am in charge to define the whole ecosystem and process in my actual workplace (and before). I just writting it due to put an example of the degree of accountability I am facing. The ecosystem (the architecture) is componsed by (from bottom to top) approach/life cycle method/life cycle process/method-framework/tool. So, you are talking about tool which is the last layer inside the "pyramid". All the layers are derivated from the previous layer bottom to top. All layers are highly cohesive and low coupling so we can interchanges components inside the layer with no-impact. Today we are using MS-Project, Azure DevOps no matter the life cycle we are using. Just to comment: Agile and waterfall are not matter of comparision. Agile is an approach and waterfall is a life cycle process.
The Falls can also be used to illustrate what can happen with a poorly managed project. One knows what's going to happen upstream but it becomes significantly more noticeable as you approach and go over the edge.
I live twenty minutes away from the Falls and visit frequently. It does make an impression.
I've deviated from the topic but couldn't resist. Please forgive!
Some think that we can architecture the project's methodology into the company's structure.
Please login or join to reply