Different project execution methodologies practice the same engineering activities of finding out requirements, converting them into design, coding and then testing. But how they go about doing that is what differentiates them from each other. So what differentiates agile from traditional project management. It is basically how the two methodologies view the project. While traditional project management treats a software project as predictive where what is to be done is clearly understood, agile treats a software project as adaptive, where little clarity exists about what is to be done, and it is only with time that clarity would emerge as a result of ongoing collaboration with the product owner and delivery of parts of software. So lets talk about these differences one by one.
- Big up front planning vs adaptive planning
Traditional projects create a project plan for the entire project. In agile, the complete project is not planned end-to-end, only those stories are planned for initial iterations which are high value and clearly understood. It is more like just-in-time planning with teams finalizing plans for the iteration they are to doing next. In traditional methodology big up-front planning gives a lot of comfort both to the management and the client, however short-lived that may be, due to visibility into future project execution. Whereas agile makes managements and clients who are new to agile somewhat uncomfortable due to lack of clearly laid out project execution plan.
2. Absolute vs relative project sizing
One of the key difference between traditional and agile projects is that the traditional model uses absolute sizing measures such as function points whereas agile follows relative sizing using story points, ideal days etc. Usage of relative sizing renders usage of project size for metrics comparison across projects useless, and hence cannot be used for creating organizational baselines either. So for agile projects it is not possible to say that the efficiency of one project is less than the other based on metrics such as Hours/Story points.
3. Collaboration with customer to get to the right product vs delivering as per contract
Agile is more suited to projects with evolving requirements as that is the premise that the approach works with. So there are better chances that you would get to the right product with agile vs using traditional methodologies.
4. Prioritizing and delivering vs delivering in bulk
While whatever needs the project has to fulfill have to be fulfilled whether you do it with agile or traditional ways, agile focuses on delivering the most valuable work first. This is taken care by following a process called backlog grooming where the most valuable stories are bubbled up in priority to be done first. In comparison, traditional methods do not have such focus on prioritizing, individual team may though make such plans.
5. Bare minimum ceremony vs following processes
Agile believes in delivering with bare minimum ceremony. Only as much as is really required would do. Agile teams would rather share the in iteration bugs by directly telling the developers than log them into defect database, if that would work. They would rather do rough sketches of design and convert them directly to code rather than create elaborate design documents. Agile teams prefer using simple means to achieving ends such as use of post-it notes to manage progress of an iteration.
6. Fewer metrics in agile
Traditional project management has a lot of metrics. Metrics such as Productivity (Hrs/Function point), Defects/FP, Functional and unit test cases/Function point are maintained among many others. It is believed you cannot improve what you cannot measure. Hours go into crunching these numbers. Auditors review these metrics and are used to feed the organizational baselines. So there is a full fledged industry around metrics.
Come agile, and lot of it is gone. Teams who move from traditional to agile projects go hunting for the metrics to be followed in agile as they start on new agile projects as many of the traditional project metrics are not relevant. Metrics are used to plan better and improve in traditional projects, whereas in agile, retrospectives and daily standups are used to improve planning and execution. This is not to say that there no metrics used in agile, there are just other ways plan and manage, and some metrics are certainly used as per teams needs.
7. Fixed scope and time vs Fixed time
In traditional projects both time and scope is fixed. Any change in either leads to re-planning. In agile projects the project timeline is chunked into equal time-boxed iterations, so time is fixed. What scope will get done in each iteration is finalized before starting the iteration. In case a certain committed story could not be done in the iteration, the iteration timelines are not revised and the story is moved to the next iteration.
8. Continuous delivery vs Staged delivery
While traditional methods move in a stage gated manner from one phase, to next phase and eventually delivering the software, agile focuses on delivering working software every iteration.
9. Command and control vs Self organizing team structure
Traditional project management runs using a command and control structure where decisions are taken in a more centralized fashion. In contrast agile lays focus on team based de-centralized decision making where the whole team decides and stands by their commitments. Roles such as scrum master are only meant to coach and remove any impediments hampering progress.
10. Customer participation
Traditional projects usually have high degree of customer interaction during certain stages such as requirements gathering and acceptance testing and to a much lesser degree otherwise. In agile however customer interaction is a uniformly spread across project timeline in the form of Product owner’s participation.
Agile may be frustrating initially as you transition from traditional. But with time and right guidance, teams can surely perform at their optimum levels. Both the methodologies are are good for different kinds of project, you just have to make the right choice for your project.