Implications of Adopting

AGILE Processes

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

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)

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" ?

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.

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

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.

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 wellimplemented 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).

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 ?