My team recently went through the process of laying out a nearly one year plan for our work. We separated the plan into three phases. Each phase will include a couple of launches.
I wonder, from an agile point of you, is this wrong? I think it's not a bad idea, because we haven't spent too much time on designing anything but the first few steps. It's possible for us to change direction. At the same time it's nice that we don't act with only the near term in sight.
Having a vision of where the project is to go is a Good ThingTM.
Believing that that is precisely what will happen is not.
“In preparing for battle I have always found that plans are useless, but planning is indispensable.”
-- Dwight D. Eisenhower
The approach Agile methodologies take is to break things down into digestible pieces, and re-adjust the vision after each piece has been digested.
That means that your ending point in a year from now is not going to be precisely what you now think it is. However, you should have tackled all the high value items on your list and have kept your stakeholders engaged and happy as you move forward.
OK, management has been presented with a myth to plan by. I hope, for your sake, that they don't hold you to it. Because, sight unseen, I am willing to bet money that your team won't accomplish anything like what that long-term plan says. In fact if you hit the industry average, you'll miss by about a factor of 2. And in most organizations an estimate, once given, becomes the club they are free to beat you with as much as they want.
You likely think that I am just being cynical. After all you just communicated vague times for unspecified sets of features that everyone knows could happen much slower or faster than projected, right? Sorry, most of that may be true, but that is not how people tend to hear those numbers. They have heard dates, and a date once spoken tends to heard as being more solid than you said it was. Furthermore if there is a chain of communication, it will become more solid still. And once external customers have been promised something by sales based on what you said, you'll suddenly find that there is a lot less flexibility in those numbers than there should be. And I guarantee that you've underestimated the time things will take.
With that obvious point out of the way, I'm going to recommend that you read Software Estimation to learn something about how software estimation should really be done. You'll learn a lot about what you did wrong, and how to do better next time. (In the process you'll learn why I am so confident that you over-estimated what you'll do.)
That said, agile is largely about reducing process to what is appropriate for a small team. Frequently a good way to reduce process is to try to cut down on big scale long-term planning in favor of planning smaller things in the short run. It also tends to be more honest - because you don't know what will happen in the future. However that often doesn't fit with larger business needs, and so, regardless of whether you declare yourself to be agile, you sometimes need to lay in longer plans.
With that said, I strongly advise you to discover a key fact about the dates you have communicated, which are unfortunately likely to come back as deadlines to bite you. And that fact is this. Which do people care about, the date, or the feature set? Here is what I mean by that. Frequently organizations have specific dates that matter. For instance get something done for a conference or before the holiday rush. In that case what matters is to release something, and not so much whether that something is complete. Other times there is a set of features that really needs to be released together, and completeness matters more than when exactly it happens. If you can discover which situation you are in, then your team will be in a much better position to plan how to handle the (almost) inevitable crunches that are coming.
It's fine to have a plan as long as you consider it work-in-progress and not something written in stone.
The key here is to make releases regularly (at least monthly), gather real feedback from your users and update your plan based on that feedback.
This means that your plan will change when the scope of the project changes. This is a good thing, because it means your users has learned more about what they want.
Assuming by project-management and agile you meant Scrum, this would not be the exact way to go.
In the Scrum perspective, if you got a one year plan, you should at least have as many Sprints as there are months in a year. Hence, your one year plan is getting more agile since it is changeable between two Sprints.
A Sprint can be no longer than a month, where the Team commits to bring the Sprint Backlog Items to the status of Done.
Done is an important word here, and each of the Scrum Team must have one definition of done, that is, where there is no work remaining to be done. When a Sprint Backlog Item is Done, this means that the analysis, architecture and technical documentation is written, and that the feature has been thoroughly tested (unit tests, integration tests, functional tests...).
Once the Product Backlog is in place, and the Items prioritized with less important features to the bottom, and the most important ones on top, the Team (of developers) determines how long should the development of each Product Backlog Item shall take based on their own experience. That is where you may determine that the project will require a full year of work. Consider that only the Product Owner shall prioritize the Items as it is he who is responsible for the return on investment, or else, knows what is the most important to the end-user. Plus, the Team shall evaluate the time required to fully develop a feature although there could be reusable pieces of code here and there that could suit the needs of this feature, that is, to avoid further complexity and be certain that an Item should take no longer than what the Team said it would require. The Product Backlog does not need to be perfect! The simple enumeration of user stories we can think of the system to develop is enough at that step of the process.
It is during the Sprint Planning Meeting that the Team shall commit on what will be develop for the next Sprint, hence creating the Sprint Backlog. The Sprint Backlog consists of a subset based on the Product Backlog Items that the Team commits to be done at the end of the Sprint. Considering for example a Product Backlog of 50 Items, and all the 50 Items shall require a year to be done, then the Team might want to select let's say 5 Items from the Product Backlog, and create the Sprint Backlog with these 5 Items. These same 5 Items may be expanded/exploded into multiple other Items when required, thus making the Team perhaps change their mind after revision and commit to do only 4 Items out of 5 previously selected Items from the Product Backlog.
Once the Sprint Planning Meeting is over, which can last no longer than 8 hours for a full month Sprint, within which the Team doesn't only commit to do the work for the selected Items, but plans on how it will get the job done so that everyone in the Team knows exactly what she/he has to do, the Sprint shall begin. It is important for the Team to be cross-functional for the project's sake.
That said, at the end of each Sprint, which lasts a month in the current situation, all of the Items that the Team committed to do shall be a deliverable piece of fully functional feature(s) targeting the Items selected from the Product Backlog. It has to be deliverable, but it is not obligatory that it is delivered if it does not make sense to do so according to the Product Owner.
It is during the Sprint Review Meeting where the Product Owner is required to be summoned that the Team demonstrates what was done during the Sprint, and where it needs to tell why it has not done, if applicable, all the work it committed to. The undone work is then put back in the Product Backlog and available for the next Sprint. Sure these undone Items shall be included in the next Sprint unless otherwise told by the Product Owner, in case that the objective had changed. But most importantly, though the objective of a system changed during a Sprint, don't interrupt it unless absolutely necessary. Only the Product Owner has the authority to interrupt the Sprint.
Once the Sprint Review Meeting is over, which should last no more than 4 hours for a monthly Sprint (if I remember correctly), it is time to get to the Sprint Retrospective Meeting. The Sprint Retrospective is required for the Team to occur so that it may discuss, in the presence of the Scrum Master and the Product Owner (optional) what went wrong, how the Scrum Team may improve its performance, etc. and bring adjustments accordingly.
When the time-box for the Sprint Retrospective is over, then the new Sprint Planning Meeting shall occur to plan the next Sprint and create the new Sprint Backlog.
Remember, the Team is responsible to maintain the Daily Scrum which is a 15 minutes stand-up meeting where every Team Member answers the three questions (not in that particular order):
The Scrum Master is not obliged to be there but is required to assure that the Team meets at the Daily Scrum and that the Members answer the three questions properly.
The Scrum Master is responsible for the respect of the Scrum Rules by the other Scrum Team Members (Scrum Master, Product Owner and Team).
In the end, following these simple rules, your development team will become agile. Agility is the capability to catch up on any change as fast as the Team can, that is, at the end of each Sprint, where it can get aware of the changes brought by the Product Owner to the Product Backlog. In case of total disaster and complete change of orientation, the maximum lost that the company has to absorb is a month of development, which is quite neglectable, considering that there are approximately only 20 working days in a month.
Should you require further detailed information about Scrum and Agile Software Development, please refer to Scrum.org and their Scrum Guide.
Well, that is quite an answer! I do hope this will at least help you through your project management.
EDIT #1
While you're planning to do three or four phases, as you call it, it is more likely that your Team will lose focus from the primary objective point of view. If you demonstrate after only the first quarter what you Team has done, there might be some important changes to bring that will require important redesign and rethinking on the architecture of your software, resuming it of perhaps more than 20 days of work lost. The principle of agility is to be able to catch up with the changes as soon as they occur, or as soon as it is possible within a reasonable amount of time, that is, for Scrum, the time-box of a Sprint.
I think you should have as many launches as you can. The only real feedback/ metric for progress in software development is code deployed in production. So whatever process you use, the more often you deploy live, the more agile you get. I.e., you get real feedback from real users earlier, and are able to adapt earlier.
While you shouldn't do Big Design Up Front, I think it's good to think about the big picture every time you're about to adjust and replenish the backlog, both for Scrum (for next sprint) and Kanban/ flow (when there's room in the WIP limit). If you consider the whole (product, service, etc), it's easier to consider what work items will get you more value next.
Be aware that the big picture changes. As often as you consider the backlog, adjusting priorities etc, also consider changes to the big picture. Things change over time, including needs of specific customers and even whole markets. Your big picture should reflect this so your priorities can be aligned with reality each time you replenish the backlog, and not only at the start when you make the plan.
In sum, I think you get more agile the more you inspect and adapt.
Big picture planning doesn't take that long, and it's crucial for big projects to have the big picture in mind when you define your sprints, else shortcuts taken in a sprint might create problems later on.
You should:
Have a master plan (preferably without deadlines attached), that will evolve as you go.
When you define a sprint, you make sure the sprint is consistent with the big picture. This doesn't always mean you change your idea of what is desired for the sprint. Sometimes you will discover, when defining a sprint, that your big picture should be adjusted. One way or another the big picture plan and the sprint should be consistent with each other going into the sprint.
The master plan should be adjusted as you go. You will learn things as you work. New opportunities will arise, points of conflict in the plan will emerge. You can adjust the master plan on the fly, as you go. But almost always you should revisit it between sprints -- to incorporate lessons from the last sprint, and to make sure the next sprint is in harmony with the big picture.
I think it's best if the backlog and the big project plan are separate structures. The big project owner keeps the master plan in a hierarchical outline format to maintain context, and then features/tasks can be pulled from it to feed the backlog, which will, in turn, feed the next sprint.
The backlog, unlike the master plan, can be added to by other team members. It's up to the main project owner to make sure the backlog items and the big picture plan stay in harmony -- sometimes adjusting the backlog item, and sometimes the big picture plan.
This method maintains the power of agile, and the power of aligning all the elements of your project the best you can at a given time through big picture planning.
Jim
I'll add the short form of my anti-Agile rant here.
Agile can be very destructive for large projects, especially when building libraries and frameworks that are going to be foundational to future development. A really important concern in the early phases is "will my design support the features we need to deliver over the next year?". Most Agile strategies don't allow for that kind of forward thinking, and thus project failure points are created.
I'm a bit sore on this point because I was just burned by this myself. We're rewriting some of our core libraries. The first phases were done and met the feature goals for their sprints. It's all very agile. Then, I was brought on board to add some dynamic loading features. However, I was stalled for about six weeks because what was written before assumed there would never be dynamic loading, I wasted a lot of time rewriting and working around what was already there. The worst part is, the dynamic loading was in the specs at the start; had the initial work kept in mind all the future requirements and done the 'big design work up front' that agile practices consider bad, I could have implemented my feature in a few days.
The lesson is, use agile for small things you're willing to throw away. It can be great sometimes. However, it's not the One True Software Development Way. When writing foundational code that is high risk or will have a long lifetime, do the big design.
