Why Agile Makes Me Sad

Everybody loves agile. Really everybody? Is agile work in the new economy the utopia we all dream of? Is this the silver bullet to testers happiness?

Isn’t that a weird question?

You would not expect so see “sad” and “agile” in one sentence, wouldn’t you? But actually, there are quite a few opinions out there, that do not like the concept or its implementation. Quick google on “agile” and “unhappy” gives for example (not necessarily my opinions!):

• Why “Agile” and especially Scrum are terrible
  • Seems like agile is only needed if engineers are too “dumb” to understand the customers
  • It is hampering intellectual progress to work in an open office
  • Work is too atomized to be attractive
  • It is too business driven to support engineering inventions
  • It is dangerously short-term thinking
• The dark side of scrum
  • Scrum is actually the opposite of the agile manifesto
  • Scrum sprints slow you down
  • Scrum backlogs lead to bad product decisions
  • Scrum Stand-Ups create an interrogation atmosphere
  • This means that it makes sense to move away from siloed departments towards autonomous cross-functional teams
• Are Agile Teams Happier Than Traditional Teams
  • Happiness is more likely to show up at work if the following is present
    • Growth mindset
    • Autonomy
    • Individuals and interaction
    • Sustainable pace

Maybe the wrong question?

It seems, not agile as such is being used for arguing. While the first two articles basically dislike what scrum made out of agile, the last article goes back to the principles of agility and uses those as basis for potential happiness. And actually, the last article made me think why agile makes me unhappy: I have the impression that it is actually especially the absence of agile while believing you could do better.

In my understanding, one of the main reasons to use agile was to manage complexity rather than “only” complicated issues. Things where you do not know how to resolve something (or even what you want to resolve) rather than not knowing in which order you have to do all those many steps. Being able to learn from mistakes rather than having hidden or overseen mistakes lead to a catastrophe.

Also even with (claimed) agility, I am unhappy when I see that

• just the terms are used, but no space is left for improving the solution (no growth mindset)
• Agile is set equal to fast (i.e. sprint sounds so fast) or to chaotic so the expectations do not lead to a sustainable pace and definitely little autonomy
• The tester in the team is still cleaning up after the developers instead of working with them
• Agile is being used in a proper “scrum sense” but there is no openness to other teams, no consciousness to the outside IT world –  which is from my experience why for large projects, scrum is so difficult: as the focus is mainly team oriented, answers to integrational questions are considered with too little relevance
• It is very difficult to be a new member in a team: as the focus is very much onto existing team, and also as high responsibility is expected, juniors might have a hard time
• I doubt, all teams are self-contained in a sense that the team has all knowledge it needs in order to deliver. This might be the ideal, but, what about the infra guys in the background, the test data people, … sure you could try to get that into every team, but then you only need very experienced people with a high level of knowledge in many things. Also, sometimes special knowledge might be needed only to a small extent, but then on a very detailed level

But what I think is even worse, is forgetting the advantages of the agile concepts in harder times

• asking for more management structure and management level reporting (i.e. take away the control) if things don’t go well instead of passing on responsibility to the people in a consistent way
• deliver something to reach the planned statistic but of little value
• build up technical debts!
• Leave it completely to the tester to see if the implementation is good enough, as development has no time to test themselves

This is sad. And it gets you into a vicious circle where it is difficult to get out as expectations need to be unlearned. And usually someone needs to be convinced that being truly agile, maybe this crisis would not have happened! And that is not so easy!

And that actually makes me really sad

I have seen and heard a lot about agile projects. Many have been called successful, however was it really because of the agile methods? Or was it because of the agile mindset that it is ok to have a different result than original scope? Was it because the people have been happier and thus more creative and more productive? I am sure there are many articles out there explaining when agile makes sense. But there is no clear engineering ruleset, no cookbook you could rely on.

As tester, I would like to test this. As in psychological tests, this would be very difficult, you would need a hypotheses to probe, and a large enough sample of comparable projects. And that I guess is close to impossible. That is sad.

Any ideas on how we can test, when agile is more successful? Resulting into hard facts? And is this the right question, considering that everybody would define “successful” differently?