Agile has been here for 20 years and what’s the result?
Higher reactivity of decisions aiming to fulfill the requirements of our customers. Adoption of agility is greatest in development of the software products.
Adoption of agile methodology has gone through various phases and a long-term experience that allows an evaluation. As an agile evangelist (since 2003), my experience with agile is mixed (contradictory, rather negative than positive).
Agility brought a broader dialogue between customer and supplier of the software solution, it emphasized a dialogue both within the team and outward and taught all participants to plan in shorter time periods, the realization of the customer requirements improved from a customer’s subjective viewpoint, however, an objective improvement is highly individual.
Agility adoption not only influences the supplier’s image from the customer’s perspective, but has a significant impact on the internal functioning of the development teams, their internal structure, mutual relationships in the team, work organization, planning and the realization itself. And last but not least the patterns and psyche of the team members. (Some good reading here about)
In a short-term context and at first sight at the integration of the agile practices agile methodology appears to be a solution for many problems, however, its application in real life encounters inaccuracy of its own definition (scrum does not even have one), lack of clearly defined methodological rules. In a long-term context and based on experience it turns out to be useless.
From internal point of view after a long-term experience I identified negative consequences of agile application in real projects as follows:
• lack of organizational hierarchy and decision ability
• loss of critical engineering thinking
• project organization driven by inexperienced persons (if scrum master onboard)
• miserable quality & stability of written task definitions
• lack of midterm and long-term planning
• ignorance of engineering consequences
• communication overhead
• feature knowledge collapse
Some explanations below..
Lack of organizational hierarchy and focused responsibility
There are no clearly defined roles in development roles – read details in Collective responsibility, ask the team. If no clear responsibilities are defined, decision is mostly delegated to ad hoc team events, which makes the decision processes slower and unpredictable.
Loss of critical engineering thinking
Agile splits development planning process into time periods (in Scrum called “Sprints” – imagine that medical doctor works in “sprints”), it creates indirect pressure to deliver solutions in time. The consequence is that technical & architecture talks are often suppressed or ignored.
Project organization driven by inexperienced persons
If nontechnical scrum master is onboard, read some details under Don’t call me Scrum Master … this role is really a weird practice. If scrum master does not understand what he is organizing in detail – what’s the quality of such organization?
Miserable quality & stability of written task definitions
In Scrum teams there are on one side Product Owners and on other side Developers. Either of these groups uses different languages and holds different set of information. Before that a System Analyst was a regular role in team as a bridge between business & development. Agile expects that engineers gather all requirements and consequences together. This fact leads to different and incoherent style and low quality of task definition.
Lack of midterm and long-term planning
Sprints is a time period of 2-3 weeks and the sprint is what the team members are mainly focusing on. That is a mistake – 2 weeks is extremely short time period and it leads to losing a mid-term and long-term project context by team members. They are pushed through “scrum ceremonies” (to name organization events as “ceremonies” is terrible) to deliver planned scope fast & in time and do not discuss about solutions from mid-term or long-term perspective. From the developers perspective it has negative mental health impact on them. Generally, to call a planning time period “Sprint” is a mistake and it makes the scrum terminology a kind of bad joke.
Ignorance of engineering consequences
Time pressure and customer request-driven approach leads to low priority of technical debts. Agile project loses balance between the engineering quality and realization of the features.
This is just a consequence of the points above. Miserable quality & stability of written tasks leads to the situation that implementations are improper, or team members do not have enough details to deliver a solution, which results in need of communication and repeating adaptations. Ignoring of engineering consequences leads to disaster situations, which again raises communication. Unneeded communication costs time and time is money.
Feature knowledge collapse
This is the most negative impact of agile ever. Lack of person who controls the flow of the changes and understands the technical background of the project – project organization driven by inexperienced persons together with lack of mid-term and long-term planning and ignorance of engineering consequences lead to feature knowledge collapse. It’s a phenomenon that the team members are not able to answer the question “what system does” and are not able to distinguish expected and unexpected system behavior.
If this instability is “agility” pure, then something is going definitely wrong and needs to be changed.
Iterative and incremental development with little bit of common sense is not enough to achieve real agility ?