Please login or join to subscribe to this thread
Often this is done with an overall predictive schedule laying out major milestones and tasks and functional "swim lanes", where agile approaches are focused on specific deliverables.
For example, you might need to plan when hardware is available to support integration activities, but the integration activities themselves can be planned as sprints. For hardware, you really need to think through what can be done iteratively/incrementally, and what needs to be done once at the right time.
This is the realm of so-called "hybrid" approaches. The reality is very few projects are 100% predictive or 100% adaptive - most fall somewhere in the middle.
If there are specific scope elements which lend themselves to one delivery approach or another, use the right approach for the right scope element. From an overall planning & reporting perspective, you'd need to identify the appropriate practices, tools & techniques to use which will support consolidation across the elements.
What problem(s) are you trying to solve? There's more than one approach to applying agile principles and practices at the project level, and more than one approach to scaling agile across multiple projects and organizations.
The rest of this is going to be something of a brain dump, so proceed at your own risk. Bear in mind that I work for a company that does internal software development, but is not a software development company.
If you're trying to use the same work tracking tools as agile development teams, you might run into adoption issues with non-developers. Reporting will involve more work - predictive work usually involves different reporting than iterative work.
My hybrid projects that involve development are typically predictive for everything except development, and often have predictive work (requirements, process changes, training...) running in parallel with iterative development work, with everything coming back together for UAT/E2E testing and implementation.
When I have projects that don't involve development, I still use principles from the agile manifesto, as appropriate, and the work can appear iterative (think rolling wave planning and progressive elaboration), but we don't use sprints for changing business processes.
In my experience, it helps to have a release manager. When you have multiple teams delivering work even if they're not working on the same systems, they can be affecting the same people. More coordination is needed between the IT and Business when change is coming at the business from different directions and/or multiple changes to the same system(s) at the same time.
Thanks for bearing with me. That's a lot of possibly irrelevant information just to circle back to my original question - what problem(s) are you trying to solve? There's a lot to track and plenty of people to keep updated whether you're running agile, hybrid, or predictive. What are the pain points you need to overcome? How would you describe the outcome you are looking for?
The point is: Agile is an approach. Waterfall is a life cycle. Then, you can use Waterfall life cycle with Agile approach. And both are not tied to a domain, software, non-software, etc. The same with Lean. In fact, before software exists all this stuff was used in Ford motor company for example in 1913 and taken by Toyota before the world war. But returning to your point, the best piece of advaice I can give you and I can justify by academic and practice is: 1-if you like to migrate from waterfall based life cycles to iterative/iterative-incremental see Tom Glib´s EVO model. But this is not enough to put Agile in place (neither Lean). 2-if you like to incorporate Lean or Agile without change the life cycle then use DA without doubt. And I am not saying this because it becomes the new "revealed truth" after was adquired by the PMI due to I am using it from the time Scott Ambler created it time ago. On the other side Crystal Clear which belongs to Allistar Cockburn is a must but this was mostly forgotten.
Please login or join to reply