How do we integrate an adaptive agile project phase (development) with an traditional sequential Phase (eg Procurement)
alan rossneyProject Manager| jacobs EngineeringDublin, Dublin, Ireland
we have development teams developing complex products in an adaptive, or agile, mode while procurement and installation will be a more sequential model. How do we integrate these phases together to ensure activities are synchronized and that we are not enforcing sequential delivery on an iterative phase. Saving Changes...
simple answer - build your procurement and installation plans around delivery of functionality. Set the expectation that development and delivery will drive the dates, and that the dates may change as new things are learned.
We're trying to take a hybrid approach, but one of the challenges to doing it successfully is a date-driven mentality (wanting a hard date set early in the project that does note change) that ignores the learning process and sees changing dates as a failure.
There's more to it than this, but it is my current pain point. Consider all of the answers you'll get and use what makes sense for your circumstances. Saving Changes...
While I agree with Aaron, it might help if you provide more context around the specific nature of the procurement and installation activities you are referring to. For example, are these happening early in the life of the project/release to get things set up, or are these related to deployment of what the teams are building?
Kiron Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Agile is not about a life cycle. You can use Agile with waterfall life cycles (not with sequential, but sequential and waterfall are not the same not matter lot of people confuse them). So, you can use any type of approach (Agile, Lean, Six Sigma, etc) with any type of life cycle. The dichotomy between adaptive and predictive has no sense from long time ago. In fact, you can find lot of work that justifies it mainly works create for people that was "the fathers" of Agile. Why? Because the basement of iterative-incremental life cycles (not news, they exists from 1980 and before) which are more the life cycles where Agile based methods are based is knowledge and knowledge is taken to predict the new iteration. But returning to the point, I am working and I was working from long time ago in environments that you stated. The key of iterative-incremental is to deliver an slice of final product (increment) for each iteration. Then, thinking in architectural way, you can mix those things with other type of approaches by encapsulating them into the whole process. The key is gaining into cadence trying to align each related part into the iterations. Saving Changes...
You need to identify your timing constraints. Is your plan based on when you must deliver the product, or when you can deliver the product? Either way, you will have a milestone plan plus development cycles between milestones. The milestones may constrain the cycles, or the cycles may dictate the milestones.
If you have a fixed delivery date, you can work the schedule right-to-left and determine how much development time you have prior to procurement, and break that time up into smaller development cycles produce the functionality.
If you have the ability for late stage changes, you need to determine the necessary maturity level prior to procurement and prioritize the development of what can't change later. That may require reducing the scope to deliver on time.
If you don't have a fixed delivery date, you flow your schedule left-to-right to determine when you will be ready for procurement and installation based on the predicted amount of prior work required.
Usually you have constraints pushing both ways. You can't set an unrealistic delivery date, but you don't have the luxury of a no risk plan delivering far out in the future. That's where you have to challenge the constraints such as cycle time, cycle content, sequence of activities, delivery date, etc.
Although the milestone plan will look very familiar, the work between the milestones may not. Rather than a team having 4 months to complete their tasks from start to finish where they are off working alone, the time is broken down into smaller periods where you see the team moving through the cycles, rather than just spending budget. Saving Changes...
Community Champion
