Everyone is agile nowadays. I think that even my cat knows this word. Our sales team is agile, our development teams are agile. We do daily stand-ups, why would you say we are not agile?
I am really very a bit tired because of all this hype.
Let me tell how it usually looks like when you are agile*. I mean “agile”. I know, I am mixing the issues of agile frameworks with the bad implementation issues. Please don’t blame me for that, as this is like real life – all possible mistakes are made and they are uniquely mixed.
*All characters appearing in this work are fictitious. Any resemblance to real persons, living or dead, is purely coincidental.
Hamster wheel
Also we have this wonderful framework – Scrum. Everyone knows that Scrum means daily meetings and iterations. We hardly know anything about the Scrum Masters, velocity or retrospectives, but we definitely have these daily meetings. And what is the goal of daily meeting? Right, we need to find the one who is the slowest. Who haven’t completed this task. The task, which was assigned to him by the Project Manager. Project Manager? What does he do here? Just don’t ask.
I definitely heard some of my colleagues be very concerned about “what to report during the daily scrum”? Report! Yes, we are still reporting. And it is great when you can report properly – telling how many obstacles you had and how you fixed that crucial bug. I remember it was one of my nightmares – “What I will say during the “scrum” meeting today?” Especially if you had that planning meeting all day long prior to this meeting and before you can join the retrospective meeting… The person who “too slow” is immediately identified during the daily meeting.
So the team feels that they are pushed to implement features quicker, just “somehow” make it work and do not think about the consequences. Probably, it started shoving consequences rather early, so they added concept of “technical debt” to agile vocabulary.
Scrum Master (ok, we all know that his real title is Project manager) pushes you to increase velocity and when you finally complete this sprint with all stories “done” what can you expect? Right, the next sprint. Where you will have to close the same amount of tasks, better even more. I find this process rather exhausting. There is no “success” state you can achieve, just continuous, infinite queue of user stories and sprints, when you are pushed to the limits to deliver faster and faster.
Power with no power
I think that power is the major thing which was promised to the developers, but not delivered in the real implementation of “Agile” in organizations. We expect companies to change their culture, be team-focused, give power to the teams. Instead we got the same management structure plus “agile”.
The whole Scrum, for example, seems to be centred around the developers. So development teams swallowed that very easy. But somehow project managers succeed in transforming that into the trojan horse. Developers thought the new way will be a paradise, but they got the old command-control style which now is called agile in many companies.
Focus on the process and methodologies
Now we have agile, but we still don’t know what we are building. We don’t know the product we are going to create. We don;t know why we recreating it. Is it a surprise then that we don’t get a good one?
That is great that we can develop faster, but what point developing faster if we still don’t know what to develop, dear product managers.
Agile was heavily captured by management consultants and transformed into “management methodology”. They finalized the small set of easy to learn rituals that emerged from the much larger, but often deeply technical set of agile practices. But these rituals are so easy, that you can learn them in 1-2 days(yes, these Scrum Master certifications) and start spreading the word among the others.
Heavy push
You have issues? Development is not going as fast as you expected? You have a lot of bugs? Don’t worry! Agile will help you. New, bright and shiny, silver bullet.
Why we are doing that? Because we don’t want to be behind our competitors? Because everyone around you is agile? And you hire several consultants to adopt the new practices. But why do we need it? It will increase our sales? Ok. Why do you wonder then that it is only a claim “we are agile”, not backed by anything at all. And all your developers just laugh at you when you ask them if their teams are agile. Companies try to implement the new “solving all issues” approach (as they think) not understanding why they need it. They are literally forced to become “agile”, as nobody wants to be among the “late adopters” and miss the train. But, probably, the ones who “implement agile” now are already late adopters. We already swallowed it, we digested it, we now need to cope with the consequences.
One of the huge issues which lead to all we can see now is that agile practices were designed for the small teams. But the money is not in a small teams, it is in the big companies. So agile scaling was “invented”. Scaled agile framework diagrams look impressive. When I see some – I feel proud been a project manager during this uneasy but full of new inventions period.
Why waterfall is opposite of agile?
When I say something about not “doing agile” people make 0_0 eyes and ask me if I am “doing waterfall”. Why waterfall is seen as the opposite of “agile”? It is like comparing apples to oranges!
What we really need
I think, there is only one easy to understand key to success. Not a ready-made fast-food solution, developed by your expensive consultants, not a magic new philosophy that you can find somewhere in the Kathmandu mountains. It is care. People who care, when they get together – they can do anything. Better if they are smart, but they don’t need to be super brilliant. But they still have to be good engineers.
I think it was one of the main ideas under all of that manifesto – people who cared gathered, they wanted to make it better. They just wanted to create software. That is it.
And then it was sold. To a thousands who did not care, by the people who did not care. And everything went terribly wrong.
Give me some fresh air, finally. Something, that will incorporate the only thing we all need – common sense:
- If you have poor quality team – you can use any methodology and any level of management skills, but you won’t get a good result. If you have a good quality team – your will probably succeed.
- Motivation of the team is in direct connection to the quality of the software they create.
- Hire people who care. Do not kill their motivation.
- The more you push deadlines the slower development will go.
- You can use estimates if you would like to have an illusion of control. But we all know that estimates are wrong. Always.
- Good developers can’t save the poorly designed product. Design issues multiply and grow fast.
- Changes are not free of charge.
- You can’t make the perfection from the first attempt. Try to make the changes easy and feedback loop short.
Do we really need some special methodology to get that? Or “agile” was created as these guys could not explain such simple things to the thousands, so rituals and procedures were created to increase the chance the audience grasp the common sense somehow in the end after repeating procedures for several times?
P.S When I got the idea of writing this post I knew that I am not alone and not unique in proclaiming “look, something is wrong with “agile”, guys”. Twitter periodically showed me the posts about “agile is dead”. I already posted 100500 times about that, but this post consolidated all I have to say on this topic. So here are the great inspirations, you should definitely watch the talk!:
Source link