Planning constraints in agile projects
Agile is an umbrella term used for denoting different software development models, such as Kanban, Scrum or XP. Managing agile projects are generally different from managing traditional - usually called waterfall or plan-based - projects. In shorty summarized, agile project management helps deliver the client's most important requirements within the budgeted cost and time while preserving the quality of the product. In this article, we compare the limiting constraints of traditional and agile project management.
Project constraints
Project constraints are limiting factors that can affect the execution of a project as per the PMBOK Guide. According to the Guide, six constraints can potentially derail any project (Scope, Time, Cost, Quality, Resources, Risks). In our comparison point of view, we only focus on the three classical ones (as our point of view the other are not so crucial):
- Scope (or Requirements): the work (e.g. features, functionalities) to be done to deliver a working product
- Time (or Schedule): the period (e.g. releases and milestones) when teams will deliver the working product to the customer/market
- Cost (or Resources): the expense (e.g. budget and team members workings) which occurs while delivering the working product
Time and costs are usually the most important stakeholder considerations: how long it will take and how much it will cost to deliver. As with time constraints, cost estimates need to be presented in a range usually. Cost and time management are not one-time project management activities but ongoing tasks: we need to stick very closely to the proposed schedule and budget while we are open about necessary changes. The third limiting factor is the scope. It is not an estimate but a set of deliverables that could be changed within stakeholder defined tolerance ranges. For example, some set of deliverables could be allocated on a wish list - if the time/cost constraints permit.
All three constraints is a vital measure of project success. Usually, the project success is defined by measuring the fulfilment of the above triple constraints.
Waterfall vs Agile project management model
The waterfall project management breaks down the project activities into sequential phases, where each phase depends on the deliverables of the previous one: the progress cascades down the stages, giving the model its name.
The waterfall project management originated in the manufacturing and construction industries. It works well for e.g. building construction where there is no way to go back when the foundation once given. Therefore, waterfall model work best in situations where software product requirements (or scope) is well-defined up-front with a high degree of certainty.
 |
| Figure 1: Waterfall vs. Agile model |
In contrast, agile project management is an iterative approach to software development that helps teams deliver value to their customers in small increments. Requirements are evaluated continuously so teams have a natural mechanism for responding to change quickly. The agile approach emphasizes on four core values described in the Agile manifesto.
- Individual and team interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The visual comparison of the two approaches could be seen in Fig. 1.
Traditional project constraints triangle
The beforementioned constraints are usually depicted in the classic constraints (or iron) triangle (proposed by Dr Martin Barnes in 1969) - see Fig. 2. In this classical view (waterfall approach to project management) the scope is fixed and the resources and time are derived values.
 |
| Figure 2: Traditional planning: create Cost and Schedule estimates from Scope |
The triangular form is not unintentional: all project constraints are interrelated, so a strain on one will impact one or two of the others. The purpose of the triangle form is to give teams the necessary decision support to make trade-offs that help the business.
In software teams, it means, the team defines the scope (a list of work items or requirements) heavily upfront and based on we predict the cost and time of the development. Therefore, the resources and schedule are variable and are predicted (or estimated) depending on the scope. This approach could be easily caught in the classical COCOMO (Constructive Cost Model) algorithmic cost and time estimation model by Boehm et. al.
In this approach, if the team - in the middle of the project - realizes that they are unable to deliver all the items of the initial scope, then there are two possible courses of action:
- proposing a later release date, or
- proposing adding additional people to the project
to the stakeholders - both of them increase the cost.
Agile project constraints triangle
Agile project management turns the triangle upside-down. Unlike traditional projects , in agile projects, the cost and the time are fixed and the scope is derived value - see Figure 3.
 |
| Figure 3: Comparison of the traditional and agile project constraints triangles |
In agile projects - considering the far most popular Scrum framework -, the size and the number of the teams are fixed (i.e. resources), the length of the iterations are also limited (i.e. schedule), therefore, what software to build and deliver (i.e. scope) varies. During the project, the project manager decides which work should be completed in the next iteration (Sprint) based on the result of the feedback from stakeholders (e.g. Sprint reviews).
In this approach, the focus is not on delivering all the predefined work items like in the waterfall approach but on delivering the most important ones. As a consequence, agile project management strives for minimizing waste by not implementing unimportant things and save energy for implementing future changes emanating e.g. from market conditions, customer feedback and changed business priorities. To select the most important work items, there are many prioritization techniques such KANO model, MOSCOW and Value vs Effort techniques.
As a remark, this planning attitude could be considered as the implementation of the third Agile manifesto principle: Customer collaboration over contract negotiation.
Spending priorities: Traditional vs. Agile
As it is presented, traditional and agile use different approaches to plan and execute projects. Proponents of the traditional approach believe that spending upfront to gather the information is the uttermost important - to be as informed as possible - to commit to a plan. This spending could be called as spending Money for Information (MFI).
While the proponents of the agile approach think that delivering the most important features, collecting feedback and modify it as they go is the uttermost important. This spending could be called as Money for Flexibility (MFF). The difference between the two approaches is depicted in the next Fig. 4.
 |
| Figure 4: Money for Information vs. Money for Flexibility |
Regardless of the differences between traditional (waterfall) and agile development, when using the iron triangle, there’s no right or wrong way - it is context-dependent. Although, in the most of the case the agile approach seems to be more rational on, in heavily regulated environments or in the public administration sector the traditional approach is prevailing.
