Waterfall was worse, but in general, yes, Agile sucks. Most places I have worked have turned it into a kind of bludgeon that leads to high stress, lousy designs, and so-so outcomes. Been waiting for the "next thing."
Methodology is a polite fiction overlaid on company culture. Authoritaian cultures will turn any methodology into a cattle prod. Even a methodology that prioritized singing Kumbaya and gently praising each other over shipping software would turn the workplace into a dystopian hellscape in the wrong hands.
There are good things in agile and scrum, but Agile and Scrum? As soon as people start capitalizing their Methodology they stop thinking about what they do and why.
Never ascribe to malice, that which can be explained by incompetence.
I don't mean to be harsh on anyone, but after working for over a decade in enterprises, mediocrity seems to be the norm. There are of course bright and insightful people, but mediocrity is pretty much the standard. Take any good process, technical practice or whatever and see it be abused and misused.
With Agile what happens is a mediocre implementation that usually leads to the usual complaints we see about Agile. The number of times I've been told about how Scrum enables self-organising teams only to be told I have no control over the process because it has been standardised across the company.
Mediocrity demands cookie cutter solutions that can be standardised without need to engage thinking. If you work in an incompetent organisation, department or team, then there's no hope that agile or anything else can help you. In fact, the religious nature of Agile often works in favour of mediocrity as critics, even well-meaning ones, get labelled as waterfall sympathisers.
I hate Enterprise environments now after working in one for just a couple of years.
They are all about conformity, standards, following established routines, established chain of command. Endless meetings due to the need to 'sync' every little decision with team leaders, product owners, scrum masters, who in turn syncs with the team members on other teams, making sure information gets distorted, lost, confused.
I'm never again working in Enterprise until I'm 60 and just want to sit on my ass, do minimum work, get payed and retire.
The days of being able to "retire" went out the window, when companies stopped giving employees pensions, and they started offering 401k plans.
Then they decided to get rid of all the employees, and use exclusively contractors for whom they don't have to pay any benefits at all. No 401k for you!
If your 401k isn’t earning enough returns to let you retire, neither is your employer’s pension fund, and it will become insolvent. The difference between pension and 401k is unlikely to be make-or-break, and when it is, it’s more likely to break the pensioner (corporate bankruptcy, taxpayer sticker-shock, etc).
Pensions are great when they work, but it's impossible to predict solvency at retirement age. It's one of the most under-reported financial travesties, but your pension can be taken away when you need it. Even the public pensions are targets these days.
Agile works well in a well defined subset of projects. The precondition for success are well defined and known, a blanket agile ban is as sterile as global agile adoption.
> Agile works well in a well defined subset of projects.
No, specific methodologies like Scrum, Kanban, XP, etc., might do that (with different subsets for different methodologies.)
Agile is more an set of priorities for choosing how to build software than a methodology, though it often gets misused as a name for some methodology, most often recently some variant of Scrum (though early on, XP was probably more common.)
It's interesting to think of moving "past" Agile to some other place.
There's an old saying in consulting. It sounds really facile and dumb, but it's actually quite deep: people like doing what they like doing. That is, inside of each of us we have proclivities to act in different ways. I like thinking conceptually and writing. This other person likes thinking tactically and keeping things organized. No matter what situation we find ourselves in, somehow or another I end up writing and thinking conceptually and this other person is responsible for keeping organized and worry about immediate problems.
The organization -- any organization -- is simply a collection of people like that. They have a natural equilibrium, and no matter what kinds of things you say you're doing or not doing, they eventually come back to that happy spot. What we're really talking about here is a version of regression to mean, only in a social sense.
If what I'm saying is true, what conclusions can we draw? My money says that anything worth doing should be something that makes you uncomfortable in some fashion. I'm not talking unrealistic deadlines or micro-management. "Being uncomfortable" could simply be the development team taking a day and working alongside the people they're trying to help.
I looked at this entire problem sideways in my Info-Ops book: https://leanpub.com/info-ops -- Instead of looking at what people did, I looked at how information was handled and moved around. I found it insightful. One of my conclusions is that discovering and creating anything of value is all about tests, either business or development tests. Thinking in terms of tests allows solutions to happen in dozens of ways, but whatever solution is chosen, you get the results you want. Compare that to the ways we usually do things, which is the reverse. Usually we start with some idea of how we want to do the solution and then try to use that to make something people want -- but it seems like we're never really sure that we're building the right stuff. And meanwhile we're all back to doing things we like doing.
Tests allow us to be ourselves while constraining what we're doing to things that are valuable. I think people grok the idea of tests when it comes to TDD. Somehow they lose focus when it's about other things, like processes, methods, rituals, and so forth. But frack, that's where they matter the most.
I don't think you go beyond agile by changing the name or disavowing it. Unless we come to terms with what the root of the problem is? It'll just be the same thing ten years from now with new buzzwords. We've been doing this for decades in technology. We should be able to do better by now. I don't want to keep playing whack-a-mole with buzzwords and people's happiness.
This seems to fail to recognize—and consequently retain—the core failure of Agile. It's too squishy.
Agile is about finding and continually adapting methods that work for the team in its actual concrete environment, but the manifesto doesn't address how to do that, and the Agile literature is all about particular methodology and not about how you manage evaluating and adapting processes as a tesm.
The critical part of Agile has almost no coverage in the Agile literature.
I quipped in a retro once that uppercase-Agile is agile the same way the Democratic People's Republic of Korea is a Democratic People's Republic. This was shortly after a teammate of mine described the three-to-four-hour biweekly sprint planning meetings he was subjected to on a previous team.
Here's a tip: calculate the cost of every meeting by taking your salary (or an estimate of the average salary in the room), dividing by 52 and then again by 40, doubling it, and multiplying by the number of people and then again by the number of hours in the meeting. Alternatively, nevermind the salary calculations: subjecting 13 people to a 3 hour meeting wastes roughly a full-time human-week of productivity.
It doesn't matter to Enterprise that money is being lost. It's millions every day being wasted and they are still there, going strong. They are no longer competing because income is automatic and guaranteed unless they do something catastrophic.
I would like to see a timer on the desk during meetings, not showing the elapsed time, but the total wage bill the meeting is costing. I think that should concentrate minds a little
We once calculated that the cost of tinkering with the projector + web conf cost about $4k for the 15 minutes wasted across the population of the room.
Yeah but imagine such a large group having an unproductive week because people have to wait for each other or because of miscommunication think they have to wait. Or spend time on a non-sensical task because everybody thought they everybody knows what they are up to.
After all even a 3 hours meeting is less than 10% of the work week...
26 comments
[ 4.1 ms ] story [ 64.7 ms ] threadI don't mean to be harsh on anyone, but after working for over a decade in enterprises, mediocrity seems to be the norm. There are of course bright and insightful people, but mediocrity is pretty much the standard. Take any good process, technical practice or whatever and see it be abused and misused.
With Agile what happens is a mediocre implementation that usually leads to the usual complaints we see about Agile. The number of times I've been told about how Scrum enables self-organising teams only to be told I have no control over the process because it has been standardised across the company.
Mediocrity demands cookie cutter solutions that can be standardised without need to engage thinking. If you work in an incompetent organisation, department or team, then there's no hope that agile or anything else can help you. In fact, the religious nature of Agile often works in favour of mediocrity as critics, even well-meaning ones, get labelled as waterfall sympathisers.
They are all about conformity, standards, following established routines, established chain of command. Endless meetings due to the need to 'sync' every little decision with team leaders, product owners, scrum masters, who in turn syncs with the team members on other teams, making sure information gets distorted, lost, confused.
I'm never again working in Enterprise until I'm 60 and just want to sit on my ass, do minimum work, get payed and retire.
The days of being able to "retire" went out the window, when companies stopped giving employees pensions, and they started offering 401k plans.
Then they decided to get rid of all the employees, and use exclusively contractors for whom they don't have to pay any benefits at all. No 401k for you!
And I say this as an agile critic.
No, specific methodologies like Scrum, Kanban, XP, etc., might do that (with different subsets for different methodologies.)
Agile is more an set of priorities for choosing how to build software than a methodology, though it often gets misused as a name for some methodology, most often recently some variant of Scrum (though early on, XP was probably more common.)
i.e. hardware drivers. kernels. libraries built to spec. software upgrades. most products that aren't built on commissions too.
There's an old saying in consulting. It sounds really facile and dumb, but it's actually quite deep: people like doing what they like doing. That is, inside of each of us we have proclivities to act in different ways. I like thinking conceptually and writing. This other person likes thinking tactically and keeping things organized. No matter what situation we find ourselves in, somehow or another I end up writing and thinking conceptually and this other person is responsible for keeping organized and worry about immediate problems.
The organization -- any organization -- is simply a collection of people like that. They have a natural equilibrium, and no matter what kinds of things you say you're doing or not doing, they eventually come back to that happy spot. What we're really talking about here is a version of regression to mean, only in a social sense.
If what I'm saying is true, what conclusions can we draw? My money says that anything worth doing should be something that makes you uncomfortable in some fashion. I'm not talking unrealistic deadlines or micro-management. "Being uncomfortable" could simply be the development team taking a day and working alongside the people they're trying to help.
I looked at this entire problem sideways in my Info-Ops book: https://leanpub.com/info-ops -- Instead of looking at what people did, I looked at how information was handled and moved around. I found it insightful. One of my conclusions is that discovering and creating anything of value is all about tests, either business or development tests. Thinking in terms of tests allows solutions to happen in dozens of ways, but whatever solution is chosen, you get the results you want. Compare that to the ways we usually do things, which is the reverse. Usually we start with some idea of how we want to do the solution and then try to use that to make something people want -- but it seems like we're never really sure that we're building the right stuff. And meanwhile we're all back to doing things we like doing.
Tests allow us to be ourselves while constraining what we're doing to things that are valuable. I think people grok the idea of tests when it comes to TDD. Somehow they lose focus when it's about other things, like processes, methods, rituals, and so forth. But frack, that's where they matter the most.
I don't think you go beyond agile by changing the name or disavowing it. Unless we come to terms with what the root of the problem is? It'll just be the same thing ten years from now with new buzzwords. We've been doing this for decades in technology. We should be able to do better by now. I don't want to keep playing whack-a-mole with buzzwords and people's happiness.
Agile is about finding and continually adapting methods that work for the team in its actual concrete environment, but the manifesto doesn't address how to do that, and the Agile literature is all about particular methodology and not about how you manage evaluating and adapting processes as a tesm.
The critical part of Agile has almost no coverage in the Agile literature.
Here's a tip: calculate the cost of every meeting by taking your salary (or an estimate of the average salary in the room), dividing by 52 and then again by 40, doubling it, and multiplying by the number of people and then again by the number of hours in the meeting. Alternatively, nevermind the salary calculations: subjecting 13 people to a 3 hour meeting wastes roughly a full-time human-week of productivity.
After all even a 3 hours meeting is less than 10% of the work week...
I'll have you know that Ohio has some pretty good developers and some pretty good Agile training.
The “poor” in “to all those poor souls lost at sea” doesn’t refer to the economic class of the souls.