Adopting agile processes could lead to several long-term negative outcomes if not implemented carefully, including having no coherent application design, unclear leadership and responsibility, a lack of thorough analysis, a contractor "bug-fix" culture, and loss of innovation. While agile aims to enable flexibility and quick response to change, over-reliance on processes and meetings could undermine quality, ownership, and creativity.

1. Implications of Adopting
AGILE Processes

2. Disclaimer
● There are always benefits (and drawbacks) for any decision one makes.
● The focus of this document is to highlight long-term expected outcomes once the
decision of going the Agile route has been made.
● The analysis is done by addressing the major drivers of Agile ( concepts, ideas,
methods) and by projecting their impact on the behavior and evolution of the
software development teams, and of their products as well.
● The ideas expressed here are my own and do not illustrate the position of my
employer on this topic

3. 1. Agile Concept:
Design Flexibility
● Intended to make an application future-proof by adapting easily to changes in
requirements
● Usually translates into postponing many significant decisions on application scope,
structure, and optimal implementation choice
● Leads to shallowness in approaching the application design/architecture
● Long term, with all decisions postponed, the (design) outcome is a crudely
suboptimal, somewhat messy and non-maintainable application/system.
● Fear: Ends up in No Application Design (a.k.a patchwork)

4. Implications
of Design
Flexibility:
Group (Ad-Hoc)
Design
● Intended to have everyone knowledgeable about and invested (actively participating)
in the project decision making.
● Usually translates into decisions being made on sub-problems, with multiple voices
throwing in opinions, and summing up the ideas in the end.
● Leads to fragmented logical and structural outcome, with no understanding of the
impact of the "design" decisions on the overall ecosystem.
● Long term, the ownership of the work (both successes and failures) is eliminated
from the individuals, and associated with the team. Results in loss of
individualism/specialization/career outlook - pretty much a consultant-culture.
● Fear: Who is "driving the ship" ?

5. 2. Agile Concept:
Iteration Driven
Execution
● Intended to have a shorter interval for feedback, leading to fewer delivery failures
due to miscommunication.
● Usually translates into unnecessary fragmentation and additional overhead mainly
due to over-reliance on process rules instead of the natural logic of the problem at
hand.Task and Story replace application Components and Interfaces design and
execution.
● Leads to micro-contract-based deliveries, which diminishes the developer's duties,
as some of the (big picture) responsibilities got transferred over to the process.
● Long term, the execution will end up being judged in a more shallow way, by the
progress of the iterations. This eliminates the need for overall understanding of the
product (as the process is in charge), and that lowers the quality of the team.
● Fear: Contractor (bug-fix) culture takes over.

6. Iteration-Approach
Outcome:
Meetings replace
Analysis
● (Meetings) Intended to accommodate new requirements, have everyone on the
same page.
● Usually translate into discussions being used as a "discovery" technique for the
requirements and the associated tasks/stories.
● Leads to inefficient use of the time (only one person talking), and sub-optimal
requirements collection and decision making (no time for in-depth analysis).
● Long term, a "culture of meetings" will lead to ad-hoc decision making with little
reliance on previous research and analysis
● Fear: Solid analysis will disappear from the process

7. 3. Agile Approach:
Progress through
Process
● Intended for optimizing/regularizing the pace at which a project moves ahead.
● Usually translates into "process junkies" replacing common sense and domain
knowledge on tracking and policing of the progress and delivery.
● Leads to "process owners" (i.e. agile coaches) becoming "surogate" drivers, even as
they lack domain knowledge (both in the problem requirements and development
arena).
● Long term, a reverted hierarchy emerges: non-specialists driving/owning the act of
creating/building of applications, with expected quality decrease.
● Fear: Innovation/Creativity disappears. Mechanical work settles in.

8. Agile-Process
Implementation
Result:
Lockstep
Coordination
● Intended to manage progress, coordinate across dependencies
● Usually translates into forcing a rhythm to delivering tasks (measured via burn
charts)
● Leads to artificial fragmentation of the application logic, and measuring progress
by number of tasks (or estimated effort-units-of-time)
● Long term, false sense of coordination leads to less integrated and less well-
implemented systems.
● Fear: teams will adapt to the measuring stick (iteration/task effort) and ignore the
bigger picture (the end goal, why the system is delivered).

9. The sum
of all fears:
● No Application Design (patchwork)
● No Leadership: Who is "driving the ship" ?
● No Understanding: Solid analysis will disappear from the process
● No Involvement: Contractor (bug-fix) culture takes over.
● No Innovation/Creativity
Bad: a degradation in quality of the products and teams.
Good: are able to respond quickly to change (whatever the reason of change). Speed of
delivery and Assembly-line automation are keywords here.
IS IT WORTH IT ?