This article is meant to explain how the properties of agile- mainly its flexibility, have an effect on the project schedule development. And how it contrasts with more traditional approaches to project schedule development. The first thing we must look at though is what it means when agile is referred to as flexible.
When someone refers to Agile as "flexible", they are most likely referencing the idea that Agile is not as strict as other methods like waterfall and allows for improvisation. You can see this in the previous two articles- The Agile Processes and Scope Management Processes in Agile.
Starting with the Agile Processes, I am specifically referencing the numbers two, eleven, and twelve. These processes are to be prepared for changed requirements no matter how far into a project, the best designs come from self-organizing teams, and the team decides how to improve and adjust at regular intervals, respectively. Change is something that is inherent to Agile, no matter how far along into a project you are- if a change is required, it will be made. The teams are self-organized and these self-organized teams decide for themselves how to improve or what to change in their work. Agile is more about letting people express themselves or do something their way than getting their creative process blocked by some guidelines. That is one of the reasons Agile is called flexible- it is flexible in the way that it allows for self-expression.
Scope management in Agile also helps to prove its flexibility. For example, in a traditional approach- there is a strict plan that is followed, and deviating from the plan is the last thing you would want to do. However in Agile, there is not really a set plan, instead, the scope is modified based on present needs. Documentation is also not as pertinent as it is in other methods, which allows more time to be used however needed.
Traditional Method- There are six main processes when it comes to project schedule management in a traditional method. There in order are planning schedule management, defining activities, sequencing activities, estimating activity durations, developing the schedule, and controlling the schedule. Below is a short description of each process.
Planning schedule management- This is the part where policies, procedures, and documentation will be used in relation to the schedule.
Defining Activities- In this part, certain tasks or activities that need to be done in order to produce a project or deliverable. For example, if a team is making a website, a login and register function is going to be identified as something that needs to be done, while something like setting profile pictures will not be identified as pertinent.
Sequencing Activities- This is essentially determining what order the activities are to be done in.
Estimating Activity Durations- Determining how long it will take to perform tasks/activities.
Developing the Schedule- This is just making the schedule based on the previous processes.
Controlling the Schedule- Making sure the schedule stays on track.
Agile Method- In Agile, as you can imagine, things are not as neatly laid out. An Agile project is made up of a series of sprints, sprints are a period of work for an iteration of a tangible product that will be delivered at the end. At the end of the sprint, there is a new, working feature that has been added to the product. There are usually four sprints and they can be a couple of days to a couple of weeks, it really depends on the project. This structure of Agile already sets a kind of schedule as you know what framework you are working in. Below is an image of what a series of sprints look like sequentially.
One of the key differences between the two is the flexibility of Agile and how it allows Agile to deal with change. In traditional methods, the goal is to set up a schedule and not change the schedule under any circumstances, there is a whole process detailed earlier just to make sure that everything stays on course- that process is controlling and monitoring the schedule. Agile is different in that changes are not only allowed but encouraged, the only strict rule is that sprints are still on time. Another difference is the lack and planning steps, this is because Agile already has a general framework for every project with sprints. Sprints still need to be decided by the team how long they are going to be, as stated earlier, the main factor in this is the size of the project. Another key difference is the importance of completion, in a traditional approach getting done by the completion date is a big success. This is not the case in Agile though, what is important is that the iterations being delivered meet the specifications of customers/sponsors.
To start off, the main thing that comes with Agile is its flexibility, so if you were to work on a project that does not have a very solid foundation and will probably need changes to the schedule, Agile is your way to go. It allows for much more adaptability than other methods. Because of this adaptability, there is also less risk in making changes. Agile also does not involve as much documentation or restrictions so you will not be too lost in the weeds. Also, the breaking down of a project into smaller and more manageable iterations is actually extremely helpful for large projects. An example is when the FBI switched to an Agile approach when developing a new infrastructure technology called Sentinel after previously struggling with other methods.
To conclude, the flexibility of Agile actually allows for there to be some big differences between traditional and Agile approaches when it comes to project schedule management. The big difference is that while a traditional approach is meant to block changes in the schedule, it is encouraged in Agile. The flexibility of Agile can actually lend itself in a way that makes it very beneficial to use it sometimes.