Agile/Scrum Driven Feature Knowledge Collapse
Agile has been here for 20 years. As an agile evangelist (since 2003), my experience with agile is mixed (contradictory, rather negative than positive).
Join the DZone community and get the full member experience.Join For Free
Agile has been here for 20 years and what’s the result? A 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 that).
In a short-term context, and at first sight at the integration of the agile practices agile methodology, there 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) and its lack of clearly defined methodological rules. In a long-term context and based on experience, it turns out to be useless.
From an 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 is 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 are listed 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, the decision is mostly delegated to ad hoc team events, which makes the decision processes slower and unpredictable.
- Loss of critical engineering thinking: Agile splits the 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 is driven by inexperienced persons: If a nontechnical scrum master is onboard, read some details under Don’t call me Scrum Master; this role is really a weird practice. If the scrum master does not understand what he is organizing in detail, then what’s the quality of such an organization?
- Miserable quality and stability of written task definitions: In Scrum teams, there are product owners on one side and developers on the other side. Either of these groups uses different languages and holds a different set of information. Before that, a System Analyst was a regular role in the team as a bridge between business and development. Agile expects that engineers gather all requirements and consequences together. This fact leads to different and incoherent styles 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 an 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 solutions from a mid-term or long-term perspective. From the developer's perspective, it has a 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 lead to the low priority of technical debts. Agile project loses the balance between the engineering quality and realization of the features.
- Communication overhead: 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 the need for communication and repeating adaptations. Ignoring 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. Is iterative and incremental development with a little bit of common sense not enough to achieve real agility?
Opinions expressed by DZone contributors are their own.