Why "agile" doesn't work that way?

Admittedly, I am a big fan of standardized processes - because they are mostly easy to learn, well documented and socially egalitarian. That makes communication and the development of e.g. software by humans theoretically simple - essentially we try to apply the clear structure of code and architecture to individuals in the hope of maximum efficiency and freedom from interference. But in practice there are many pitfalls and dead-ends that can neither be adequately described nor quite grasped according to agile-theoretical standards.

With great respect for the creators of #scrum, #kanban and other agile methodology, here are a few practical considerations as to why "agile" does not work properly and is essentially unpractical:

A scope for mistakes

In my experience, agile software experience in practice allows too much scope for technical and technical errors and allows inefficient development paths - and this is due to the fundamental understanding that the product develops almost successively on the basis of iteratively acquired knowledge and hands-on experience. However, what is lost is the early and ongoing assumption of responsibility by the product planners and developers: In an organic process of continuous improvement, a clear focus is extremely important. However, a process that tolerates continuous failure or non-compliance with time targets without consequence, softens the "big goal".

In particular, the difficult relationship between practical development work, stories, tasks, subtasks and their granularization always creates problems for conceptual designers and programmers. Not only that there is always disagreement about the manner of technical execution and programmatic implementation (topic: user stories and how they have to be written), the problem here lies in a contradiction: complex professionalism cannot always be "short and sweet" to be formulated in standardized sentences - clipping through the methodology, usually reinforced by poor tooling, limits the formulation of facts, requirements and tasks. Stories are not able to assign the interdisciplinary facts of complex software to multi-operative individuals - the consequences are: haphazard cutting of subtasks, wild assignment and rejection of tasks and, above all: the immediate loss of responsibility, due to the "de-lighting" of the respective task, that goes hand in hand with the desperate attempt to simplify tasks. The rule of thumb applies: the simpler the task, the less sponsorship it experiences.

Here, the striven-for minimalistically efficient management of complex processes meets with a bleak attempt to tear the cosmos of requirements into billions of "explainable" polygons. The additional administrative effort digests any sense.

Refactoring for the worse

The technical transformation around the software world of a standard company is so fast and noisy - the inclined architect is easily tempted to liquidate the current code base and pour it into new clothes. Sometimes it is sold as "necessary" refactoring, what actually is a from-scratch development. Agile manifestos stupidly create a framework for this hideous way. This is bad because very few companies can / should really raise money for such nonsense, and because it inevitably leads to a permanent feeling of uncertainty among those responsible: "Am I still up to date? Is our software bleeding-edge?" apart from security-related upgrades: Who cares? The main thing is that the horse runs, preferably docked and autonomous. And then just put your hands away!

Real refactoring - i.e. the requirement-sensitive updating or reorganization of inventory code - on the other hand, should not really be necessary in accordance with agile software development - unless the module / software / service in question has significant defects or missing functionality, which in turn is only due to the agile process were made possible :D If I want to build a unicycle and then try to develop a full-scale bike out if it, then I cannot ultimately rely on the initial blueprint of a unicycle - the subsequent refactoring towards the mutant-unicycle is an agile error that should not exist.

According to my taste, agile process management creates a basis for the aforementioned loss of responsibility under the premise of being able to improve without restriction at any time. But that is far from realistic and economically at least questionable.

No consideration for individual needs

A standardized process can only reflect the individual needs of its participants to a very limited extent. Even if there is an agreed framework for conflict management and communication in general, the "agile" practice clearly shows the communicative limits. It starts with chronically unpunctual colleagues, over meeting-haters, to sensitive programming souls who suffer psychologically from the agile game. Here too there is a mismatch between the theoretical simplicity of the methodology and the complexity of human emotions and needs. People cannot be agilized.

The well-known Scrum Manifesto does not provide guidelines for dealing with colleagues in relation to their human challenges. As a consequence, meticulously created user stories, definitions of done or even velocity determinations on the performance of the team are usually useless because the agile corset stresses and ultimately everyone maintains their individual style. This is also the reason why phenomena like hyperproductivity or hero-developers mostly do not occur in direct connection with agile methodology.

In theory, agile methods offer an idealised concept of ​​team leadership and responsibilities, but this is often far from reality.

Psychology of Failure

Here's a paradox: a failed sprint is a new sprint.
If at the time of my first occupation with programming (back in 2001) a developer failed to meet the imposed schedule three times in a row, he was usually fired or he / she took the hat out of shame. Scrum, in particular, now "allows" repeated non-compliance with agreed targets as part of the velocity determination. The psychological effect of permanent failure is actually noticeable and sometimes causes collective and individual depression. At the same time, "agile" gamification (e.g. story-point leader-boards) leads to systematic over-performance in the achievement of tasks, including quality issues, burn-out and all the addictive effects of other (gambling) games.

In addition, the introduction of agile methods creates a dangerous deprivation of personal responsibility in the development process, which is an urgently critical structuring part to being a human. An "irresponsible" person is increasingly losing identity, and this clearly not only damages his work performance.

The waiver of orderly, controlling supervision of human behavior in all agile manifestations known to me prepares the way for the establishment of mental illnesses and addictive behavior. That cannot be in the spirit of the inventor.

1001 tools

JIRA, Trello and you name it – all offer us excellent support for process management based on the textbooks. The high adaptability of most agile planning software also enables the display of the most complicated processes - and that is exactly the problem. In practice, there is hardly a company that does not integrate any special curl into the management of its processes. This ensures that the tools are perverted and the learning curve comes to a head. The sheer variety of software is already irritating - the possibilities of additional individualization based on pseudo-agile methodology are endless (unmanageable). Most of the agile methods are clear here, but the implementation of associated software already shows the need for "further" solutions, to the detriment of the agreed methodology.

Velocity vs. Time management

Probably the most annoying aspect for product managers in development planning is the inability to calculate the completion of software artifacts - especially in the agile way of working. Quite a few companies try to integrate agile software departments into an otherwise time-driven corporate culture. There is a conflict at the interface between the two worlds: The person responsible has to embed difficult-to-plan material in continuous time management. Especially in the constantly new composition of teams and the associated high variability of the velocity, a time-appropriate categorization of work units is not compatible with the desired agility.

Wherever there is a deadline, "agile" is probably a fairy tale - beautiful, but untrue.

Definition of what?

In practice, the definitions of ready, done and others contribute significantly to complicating the actually "simple" agile process. The attempt to flank individual needs and sensitivities to the standardized manifesto often fails due to the sheer volume of these specific requirements and often makes the "learning" of this agile pact (possibly of earlier generations) unacceptably difficult for outsiders.

It used to be: Done is when I say it is! And it would actually be nice if the acceptance of developed software snippets was done again by explicitly assigning responsibility to a person and not by instruction by a principle.

Alternatives

There is of course no "one solution" for the varieties of teams, departments or companies around. In more than 250 customer projects, however, I have clearly recognized for myself that "agile methodology" according to the textbook has often been unsuccessful, sometimes even really harmful for the company, but also for the individual people in the company. Many projects that I have been able to experience would have been realized way easier in a classic waterfall mode or structured time and task planning and / or more cost-effectively - with considerably less human collateral damage.

For future alternatives I wish for:

  • Customizable working methods
  • Consideration of individual needs
  • Communicative transparency
  • Commitment and focus on the big picture
  • Time-based effort estimation

For me it is clear that not the development, but the product management has to think and act "agile" – in the very sense of the word, not out of a textbook-pattern. One has to be focused and with maximum foresight. Responsibility must not be based on "virtual" principles, but in real people. Appreciation must not be woven into theoretical game practice, but must be expressed by people.

Don't follow the hype. Thank you for your attention.
--
Photo by Mitchel Boot