Agile's Prerequisites, Risks, Limitations and Weaknesses

Agile's Prerequisites, Risks, Limitations and Weaknesses

Often the question is asked when to use Agile and one or more Agile methodologies and methods.

To make this decision, it doesn't suffice to know the strengths of the Agile approach (philosophy, attitude, methodology, work environment, ..). It is essential to understand its prerequisites, its risks, its limitations and its weaknesses.

Let's get realistic. If the Agile approach is not a silver bullet, then they do exist. One size doesn't fit all.

However, these prerequisites limits, risks and weaknesses may depend of the chosen Agile methodology, the specific Agile implementation in organisation and of course the people themselves. Possible, local solutions can be found to circumvent the disadvantages.

This list is based on my experience, understanding and readings. It is perfectly possible that other people come to a different conclusion. This list is not exhaustive and is provided as is. It can serve as a starting point for further investigation.

1) Preconditions for an Agile approach

 

Budget

 

• ...

Client
 

• Availability: Daily involvement and face-to-face meeting (possibly through videoconference)
• Accepting not to know what will be delivered for a certain budget (although, most valuable and risky features are delivered first, but content of later sprints can change)
• Accepting a different way of following up the project progress
• Should provide a product owner (on business oriented software projects)
• ...

Team

• Team members be willing/motivated to adopt the Agile approach
• Must be highly skilled
• Must be disciplined and possessing the ability of self-management
• Must have a team spirit
• Must be able to work with the customer, end-user and other non-It people (interviews, workshops, ...)
• Project team must be Multi-disciplinary. ==> Programmers must possibly be trained if the "developer" combines the roles of analyst, software engineer, programmer and tester.
• Must master the Agile philosophy, the chosen Agile methodology and tools.
• ...

Organisation and Work environment

• Presence of a product owner who should be well-trained in informatics
• Presence of a Agile coach to facilitate collaboration and enforce the Agile philosophy and methodology
• Project Manager should accept his/her role has changed
• Analysts, if present, should accept his/her role has changed
• Place for daily stand-up meeting, possibly also for the daily meetings with business stakeholders
• ...

Project Type

• Smaller projects
• Frequently delivery must be possible (can be argued)
• Existing systems are more suitable than new systems.
• Local projects. Projects with ramifications accross the organisation should be avoided (uncontrolled impact elsewhere in the company).
• Projects with many different business stakeholders may be more difficult in Agile.
• Projects including different systems may lead to more than one product owner.
• Should have a stable, mature overall architecture and core of the system. The uncertainty about content and changes should (mainly) reside in the peripheral logic (detailed business logic, end-user features, outputs like screen and reports). For example: Through creativity end-users features can be adapted or created.
• ...

 
Product

• Must be deliverable in parts (eg separated features)
• Large business critical systems should be avoided
• ...

 

2) Limits of the Agile Approach

• Size of the team between approximately 5 to 15 persons
• Agile is difficult scalable. Most methods are oriented to small teams working fast. Larger projects will require an overall architecture and more planning. This may become lesser adaptable. This discussion is going on in the Agile world.

3) Risks of the Agile Approach

• An Agile approach is hard to implement
• It is very demanding of the team members (to reach quality and excellence)
• Since reuse is difficult, a same code may be developed accross the company. This reproduction of a same logic constitutes a risk of inconsistencies.
• Depending on the product owner, there might be a risk for suboptimisation.
• There is little control on the impact outside the scope of the system, elsewhere in the company.
• Team members leaving the company/organisation is a risk if too little documentation.
• Since each change is a cost, repeated or excessive changes may kill the recovery of the investment.
• If the Product Owner is a business person without sufficient competencies in informatics, he won't be able to make sure the software system produces business value. His decisions has a tremendous influences on the system and on the project and may then put the project in danger.
• ...

 

4) Weaknesses of the Agile Approach

• The Agile values can easily be abused for limiting or avoiding documenting, planning, respecting the contracts or for doing some administrative tasks.
• Since sprints are short and a frequent delivery is promissed to the customer, the danger exists that no time is left for decent analysis, thorough testing, appropriate documentation (which is lesser valued), refactoring (what the client doesn't see and from which he/she doesn't get benefit) and learning.
• If client the continuously changes his mind, there is a lot of rework and refactoring. Refactoring is a kind of rework that doesn't produce immediate/direct business value (client has to pay for it) but which is needed to keep the code well-organised, clean and clear.
• Testing thoroughly is difficult under an Agile approach.
• In larger companies, releases may be organised on a quarterly basis. This decreases the value of delivering early. Delivering frequently, however remains usefull to get faster feedback by using it as delivery of functioning software for a demo or user test.
• It is tempting to simply develop whatever the client asks for. This approach limits the usage of the full potential of IT.
• As Agile approaches are based on the business demand and on the instructions of the product owner, the approach is reactive in nature and increases the dependency of IT from the business community.
• Depending on who does the analysis/design, there might be a lack of innovation at conceptual level.
• It might be difficult to have enterprise-wide models if the product owner is responsible only for what happens within one/his department/organisational unit.
• The focus is on the business logic and on the feature of the software since this is what creates (immediate) business value. But how well does the Agile approach supports the needs and requirements of the IT departement. And how well attention got the non-functional requirements, the "ability"-qualities (= ISO9126, ISO/25010).
• Risk management is limited to the sprint, unless a broader and overall picture exists. 
• ...