Should All Projects Be Done In Agile Way?

We all know, rapidly Agile methodologies are taking over the conventional waterfall project management approach in software industry. Now a day, it’s becoming normal phenomena to execute a given project in Agile way even if they really don’t suites to Agile approach; purely because Agile is buzzing around the corner rapidly. Clients are getting more and more Agile fashioned and wants to do every projects in Agile way. Service Providers have to showcase their Agile capability plus maturity to remain competitive in market for getting more business. Software Professionals (including Project Managers), seeing the Agile in demand; are also behind enriching their exposure and competencies by doing more and more Agile projects (even if that project may not be fitting to the style); just to get some experience and show Agile buzz-words in their resumes. Keeping the benefits and values obtained so far from Agile ways; these above factors are also pushing for the Agile acceptance and adaption across the IT industry to larger extent. It’s true that any projects can be done in Agile ways; but not all the projects are the right candidates to follow the Agile Methodologies, as not all values and principles can be fully adhered or realized completely. Do we all agree that Projects such as  – technology refresh or re-engineering projects where the requirements and budget are almost fixed and known; or product development for which time to market is fixed, and projects that need to be done completely by the shared pool of resources –  should be executed using Agile methodology? Before we deep dive into it, let’s review expert’s views –

Mike Cohen writes in his blog “Deciding what kind of projects are most suited for agile – “In my view, the most appropriate projects for agile are ones with aggressive deadlines, a high degree of complexity, and a high degree of novelty (uniqueness) to them. We want to use agile when we are doing something that is new, or at least new to the team building it. If it’s something the team has done before over and over then the team probably doesn’t need an agile approach.” He suggests to inspect projects on three factors–urgency, complexity, and novelty–mix before deciding to choose execution methodology.

Agile or waterfall approach should be considered for any given project prior to deciding the execution methodologies. There are many parameters that should be evaluated to decide the suitable approach for the project under consideration. Let’s look at some of the key factors along with their impacts…

1. Project Complexity

Highly complex projects that have complicated business rules, algorithmic procedures, robotics, hardware and/ or networking interfaces are the most suitable for Agile. This does not mean that complex projects cannot be done in conventional approach. If the projects have complex and evolutionary requirements than they are the ideal candidates and best to be executed in Agile way. Iteratively such project features development can follow the plan-build-test-improve cycle until done to desired level of completeness.

2. Project Budget

If the project budgets are fixed then following the Agile approach, business features with high values can be developed first before taking up subsequently lower value features. Arguably such most valuable features can be developed initially in waterfall model as well, but Agile gives advantage in terms of getting those developed features validated, reviewed and approved from business. Which is very important from business and end user perspectives to have high degrees of acceptance and satisfaction for the success of project.

3. Time to market

If product’s few of the priority features require early release to market for various reasons (like launching new products in market, getting market feedback on some product features, ascertain acceptability etc.) than Agile is the right choice. With small iterative development approach, high valued important features can be developed, tested and released continuously in increments to the markets without holding on until entire features set completion. If there is firm requirements on product being available within certain fixed time in future then going with iterative feedback approach would be the right way; as it reduces overall risks by having early success or failure sign based on users’ acceptance.

4. Customer Participation

Agile projects need customer’s active participation throughout the project life cycle. Customer need to engage suitable product owner and business users continuously to enable requirements elaboration, functional testing and provide continuous improvement feedback on product increments delivered. If customer cannot participate actively in the project then following the Agile practice would not be relevant because the key values and principles of Agile wouldn’t be fulfilled.

5. Functional Knowledge & Stability

In most of the cases there are evolving business requirements, that are not known upfront completely and they are very likely to be dynamic in nature which could change based on the user preference, feedbacks obtained based on reviews or uses, in such cases using the Agile methodologies iterative model for continuous frequent delivery works best.  But if the organization has already done similar projects, end products requirements are clear, complete and stable and project related efforts, cost and time can be easily estimated/forecasted then waterfall approach, which is plan-driven process should be the best suitable to adapt. In case if it’s opposite where there is high degree of uncertainty, unreliability and instability than approaching in Agile way make sense, because comparatively the degree of unpredictability and project risks are high. Project’s unpredictability and risks can be better mitigated through iterative frequent delivery and continuous testing and review feedbacks from customer.

Project Approach Selection
Project Execution Approach Selection

Following are some additional parameters which would drive the project methodology selection decision –

6. Executive Sponsorship

Project Sponsor and Senior management support is very critical to the success of the Agile projects. Such projects require flexibility on project scope, cost and time from both customer and delivery management side to shed their administrative mindset to become more adventurous. Both parties should firmly believe in the right spirit of evolution requirement, continuous frequent delivery and should be able to formulate and agree on contract that accommodates supportive service levels, commercial terms and structure.

7. Technology Complexity

Technically complex projects are not the right candidates for the Agile development. Such complex projects needs to be developed by special skilled and competent people not by having just cross-functional team. Such projects may require heavy R&D without knowledge to end-results. Normally in such kind of software development, many project related operations goes beyond software engineering to mechanical and/or electrical engineering. But if some projects requiring some elements of simple R&D and sample POCs; that can very well fit into the Agile.

8. Personnel Skill & Availability

It is suggested that the project team members are allocated to the project for the complete duration of the project and they have the required right skills that are needed for the project execution. But it does not required to have technology specialization. Even if some of the team member do not have the required skill, either technical or functional; one can be trained on the job easily to become productive. Because by having cross functional team, the team members can communicate, collaborate, share skill and experience to learn and pair-program together to develop the product in much faster pace.

9. Agile Competency

If the project team, customer and organization completely lacks competency in Agile methodology then applying the values, principles and practices would be difficult. In this case, Agile should not be the obvious choice for the complex projects, rather organization should build competency by training & coaching the people on Agile and start practice by executing the smaller and less complex projects. It is important to note that both customer and service organization need to build Agile competency for successful execution.

10. CI & CD Automation

Essentially Agile projects heavily really rely on continuous integration, automated testing and continues delivery. Achieving complete automation of CI & CD including the automation of unit testing and integration testing would be the right choice and ideal situation for an Agile project. If CI & CD cannot be automated, but rather performed manually; then the sole purpose of being Agile would be lost to great extent.

Conclusion: Selecting project methodology without consideration to influencing factors may lead to project failures. And project failures not only lead to loss of revenue and time but also have great implication on organization reputation, customer relation and business opportunities. Needless to say, project professional should weigh out various parameters appropriately before deciding on project execution approach.

3 thoughts on “Should All Projects Be Done In Agile Way?

  1. With all due respect, agile is not just a methodology that gets swapped in where “waterfall” doesn’t fit. It is cultural; it is a change in approaching how we interface with customers, focus on products, consume change at many different levels in the organization, and how we treat the very individuals that create value for us. My hope is that you have a great discovery of what it means to be agile! I have several clients that are agile organizations but use longer and more complex methods to accomplish success on initiatives or projects…


    1. Thanks Joshua. I agree most of the points. There is no silver bullet solution to every problems. All projects are different, situation and circumstances differs; so many ways to handle them tactfully. This article draw some on how to select methodology for executing projects in consideration to prevailing project specific parameters. Still waterfall suits better for some projects. But that doesn’t mean that such projects can not be done using agile methodology.


Leave a Reply to Vikash Karuna Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s