As a program advisory I need to schedule 5 projects in the next year but one of them will be agile (the first in our business).
All of the projects that are waterfall are easy to schedule: Authorisation/architecture/development/tests/delivery
How do I schedule a 2 years project from a high level management perspective, using the Agile methodology? What are the main phases of agile development?
Thank you
Identify the minimum viable product (MVP) that you can roll out to the end users (or a subset of end users) that makes business sense. Working with the team you can get a forecast (not a commitment) of when this can be accomplished. Let us say that this will take 6 months.
Keep in mind though that your team doesn't have any experience with agile development. So, you will have to forecast this very conservatively. My recommendation is that you should form a team and run at least 3 sprints before you can get a reasonable idea of velocity that can be used for forecasting.
From there identify the business goal milestones that you want to accomplish until you reach your 1.0 release of the software. This can be a quarterly goal, for example.
These business goals are what you schedule from a high level management perspective, not functional phases.
Keep in mind though that you will learn things about the product from stakeholders viewing the working code at the end of each sprint as well as from end user feedback after you roll out the MVP. Also the development team will learn more about the technology the more they work on it. And based on all this feedback be prepared to revise your business goals. When you reach the end of those two years the 1.0 release may look very different from how you visualize it today. But it is guaranteed to be a much better fit for the purpose.
You don't is the simple answer. There are no phases. There is already an assumption that the project is two years. This is incorrect, you should only recognize that you have 2 years of budget to fund a project.
Agile scrum teams schedule 5 things: standups, plannings, reviews, retrospectives, and iterations. You could schedule a scrum team with 2 week iterations to have about 50 iterations over 2 years.
Realistically, the project schedule is unknown to you. Fund the team that will work on the project. Assuming it is a scrum team, the product owner, working directly with the customer, is responsible for generating the product backlog and prioritizing it. This will result in an initial product roadmap that identifies in which order business valuable features will be iteratively delivered to the customer. The initial roadmap will not tell you the duration of the project.
As mentioned in another post, fund the team's operation for around 3 iterations to establish an initial velocity. Using the team velocity it is possible to start generating a very rough forecast of the project duration assuming the backlog is fully built out and all items are roughly estimated. In this instance, if the forecast is +/- 6 months of the 2 years of budget thats pretty healthy. If not, this is your first hint that its time to start doing some expectation management or risk mitigation. This is when Agile stakeholders also learn that Agile project "schedules" are living documents that should change frequently.
So this is the project "schedule." It should now communicate the order and rough timing in which the team thinks it can deliver value.
This Agile "schedule" is not a commitment. It is a forecast and the customer/stakeholders should understand the assumptions and variability in the forecast.
The concept of a Waterfall project schedule is gone, since it is unrealistic to think that a 2 year plan will materialize as planned two years down the road.
Iterative delivery, smaller feedback loops, and building customer trust replace the project schedule on truly Agile teams.
"But wait! My two years is based on a fixed scope/budget agreement with the customer!" Its time to recognize the risk that the rest of your organization is still operating in a waterfall mindset and the friction between the two methodologies will probably produce mediocre results.
For Agile methodologies like scrum to provide maximum benefit, they need to be adopted throughout the org, not just at the delivery team level.
