Special News
When to use Agile and Traditional Methodology for Projects
The following is the list of common concerns for people adopting Agile project management:● It won’t work for big, complex projects.
● It’s too open-ended. We can’t predict costs. It’s “sanctioned scope creep.”
● It sounds like “back of the napkin” design and planning.
● It’s too “techie” focused.
● Software developers don’t speak the same language as customers.
● Customers don’t have time to get involved in planning.
● We don’t want our customers to see our dirty laundry.
● This “teamwork” approach doesn’t sound practical.
● Daily meetings? Our employees will feel like they’re under a microscope.
● It’s too rigid and inhibits individual creativity.
The truth is that the above concerns are quite legitimate. A project team, whether it uses Agile or Waterfall, will fail if it doesn’t watch out for the above problems and find ways to resolve them.
Situations Should Use Agile
Team members never worked together before or have not receive sufficient training
Agile is a simpler methodology than any popular traditional methodologies in the sense that its rules are simpler and the rule compliance is much more explicit. The reason for using Agile in such situation isn’t for the benefit of saving training time but for the avoidance of the high possibility of training failure, which would result in project chaos.
Team not having a real-time-transactional project management tool that can protect project data integrity
Most project management tools on the market are non-real-time-transactional and can’t protect project data integrity. If the project team doesn’t even aware of the fact that it will need a powerful PM tool in order to use one of the traditional methodologies, it is better off to use Agile which is much less dependent on such a powerful tool.
Situations Should Use Traditional
The following is the description of the situations that Agile shouldn’t be used:
Projects that need requirements defined up front
Some initiatives, especially government initiatives, might need to have a project studying and defining the requirements upfront, a lot of approvals for a prolonged period of time after the requirements are defined and finally a separate project (often even a different team from the team for the requirement project) to develop and deliver what are being said in the requirements.
In this situation, you should not use the Agile approach because it is dependent on constant interactions and changing adaptation without clear documentation of the development process.
Customers or user groups are not generally available to participate
The biggest factor in project success is a steadfast executive sponsor or product owner. When customers are involved in setting requirements throughout the project, such as reviewing and prioritizing work, it means they are less likely to suddenly throw out requirements that are difficult to implement. Instead, they constantly incorporate business and user requirements into the process.
If customers are not engaged enough, without properly inputting their requirements into the process, and do not participate in the evolution of the idea, then the project needs to be frequently backtracked, leading to the waste of a lot of time. Therefore, it is not suitable for using the Agile method.
Team is too large to be effective at cross-communication (i.e. 200 people or more)
The Agile process requires team members to make many critical decisions during the project. If your team members are not experienced or responsible enough, they will probably ruin the whole project.
The Agile method needs constant interactions between all stakeholders (development team, testing department, management, and customers). If one of the teams is not performing well or there is poor communication across departments, it will certainly affect the overall performance. Using agile at this point can be counterproductive.
