I think some of the root issue is the annoying micromanagement and lack of trust from non technical stakeholders. They need to chill out, but it's in their nature to be dicks somehow. They think if only they plug numbers into a spreadsheet correctly, huge savings will just pop out. But really they waste time and annoy the hell out of people. Maybe anti-agile is "fire all the nontechnical managers".
Agile as a system of prioritization isn't bad, but human factors mess it up a lot.
Edited: grammar
Sure. And now imagine that one of those people encounters your proverbial, arrogant, software solves it all developer. The results, if there are any to begin with, are glorious (gloriously unusable).
It's absurd how this extreme is used to justify micromanagement without recognizing how things have exploded despite micromanagement being the status quo. Haven't seen a single stereotype micromanagement scrum shop care enough about the consequences of letting a few cowboys loose only to have trouble hiring devs to fix the mess later (because no self-respecting developer wants to fix old code with near zero documentation for a pittance).
I have seen this transformed into "We don't need documentation, just work on a new feature".
Also the fact that you're alone and only you to do them means it will get done when it will get done and they should only prioritise items in a list.
Sorry you seem to hate agile and I could see why but hopefully some day you get to be part of an effective team with a common sense approach to agile.
Next we multiply by the number of points in the backlog and we have our delivery date. If you don’t keep turning out two points per day the project will be late and there’s gonna be a problem.
Estimating in points is just what the magician does so you don’t see what he’s really up to.
The litmus test is quite simple: are sprints planned more than one sprint ahead? If an organization has a schedule where they map work to sprints months in advance, they are doing Agile. If they just have a backlog and the only planning they do is in preparation of the next sprint, they stand a chance of being agile.
The really frustrating thing is that what's now called "Agile" devolved from "Extreme Programming" (XP) which was as appropriate as it was poorly named. I first heard of it sometime around '99 or so, long after I had put up with my share of frustrations around the expectation that every programming task could be predicted ahead of time on the spot (and that every prediction was a few hours). XP, on the other hand, was a reasonable pushback against mismanagement: say what you want and then get out of the way and give them time to make incremental progress toward that goal. There were no estimates or deadlines in XP. There weren't any in the agile manifesto, either.
However, what's now Orwellianly called "Agile" as "tell me right now on the spot how long it's going to take to deliver this vaguely defined piece of functionality so I can 'negotiate' it down to when I need it by"... which is exactly what XP and the agile manifesto were trying to explain was impossible.
In the teams I've worked on that had a good sense of the essence and spirit of agile principles, we've done extremely well. But it's always been context specific and very fluid.
Where it's been a mandate from on high, where it's dogmatically enforced and people say things like "that's not Agile": it's always been a bit of a shitshow. Usually it's just window dressing on old school command and control style management.
I've personally found almost all SCRUM teams I've been on to be more of the latter. Not all but close.
I think fundamentally business school is just teaching a more static model than what really makes sense with modern software development, and that pervades throughout and beyond the organization. Hopefully we'll see that slowly evolve as competitive pressures punish the less adaptive ones.
Is there a better way to do this than agile? No duh, but that's another topic. :-)
I have two problems with this.
One, almost all work that is easily estimated falls into the realm of trivial work. Most work is not trivial given the rapidly changing work environments. If it isn't the tech itself, it's the people around you and above you. If it isn't the people, it's some context which in common human fashion, has become overcomplicated to high heaven.
Two, because things change so rapidly and riskmanagement is the way it is, we are in a perpetual state of businesses trying to pressure one another into getting the best short term deals at the cost of almost everything else. How many times has a deadline not been met with it being critical? Not that often, most things can wait another month. So why do we keep making unrealistic deadlines? (Semi-rhetorical)
If there's some set date (eg. demo/launch at big industry expo) it makes sense keep that constraint in mind, plan work in small chunks, iterate, and always try to deliver tangible things needed for the demo ... and it also makes sense to periodically check in (let's say at the end/start of every iteration) how the demo is coming along ... and it again makes total sense to adjust course if it seems that progress is better/worse than expected ... and it makes sense to try to do this tracking and estimation in some consistent/rigorous way, instead of just gut feeling.
"And that's how story points were born". (Which is just a fancy name for reference class based forecasting - https://en.wikipedia.org/wiki/Reference_class_forecasting )
And, again, if there's enough reliable data it's possible to give educated guesses about how the remaining tasks compare to the already finished ones.
...
Now, doing this top-down, from day 1, expecting 100% accuracy, and whatnot is complete business madness, and anyone who does that needs to be thrown out of a fucking (ground floor) window again and again until this gets through their (apparently) very thick skull.
...
I've seen this done well. (Not the defenestration.) And seen this done horribly. The "methodology" is not magic, and it definitely doesn't make sense if the people trying to "do" it are senseless imbeciles forcing things they don't even understand on people whom they also don't understand.
Usually what's not trivial is how much to build and when (which is product design).
> it's some context which in common human fashion, has become overcomplicated to high heaven.
yes indeed :)
If business (and/or management) is too neurotic, that definitely will fuck things up and it doesn't matter what methodology you try to manage projects with.
I used to scoff at the first dictum of the agile manifesto (individuals and interactions over processes and tools), but it fits exactly these problems. Business has to plan and build on what Engineering already does, not try to force things down onto it. Management has to work with the people, not try to force the people into their own crazy world.
And if they don't, then out of self-preservation, leave.
I've literally had clients go "Hey, can you add search to the platform? Can't be that hard, it's just a single input field on google dot com".
Your task is to tell them that this is too big to estimate and needs to be specified better and broken down into managable chunks. Well ok, in this case, just telling them to sod off would've been smarter, but that's a different story.
The common pattern I've seen is that everything is about estimates, which end up becoming deadlines. The management worry about them to the point of bloody-mindedness, at the neglect of gathering actual requirements from the customer. In my company, I work in a software department (I suppose we're an internal agency with just one customer). But, we can't speak directly to the customer and instead speak to another Project Manager (apparently because of "SaFE Enterprise Agile" policies), so we can't ask the customer what they truly need, and so the product isn't accurate, and neither are those estimates!
Entering a contract with a client based on an estimate without a large margin for error is a statistical failing, not a strategy one.
That said, I still think waterfall and other related variants are overwhelmingly the way to go. I've done both styles and the difference is night and day.
I'm sorry you have to endure this :(
There is no mention of estimates at all lol.
Some highlights:
> How many books, conferences, certifications, practitioners, evangelists, etc. does it take to make a paradigm, supposedly the paradigm, of working actually work?
> If the number one answer to we're using Agile but it's not working is "you're doing Agile wrong", then maybe Agile isn't the solution?
Any time you see a product manager plan 10 sprints ahead, you know that whatever that is supposed to be, it involves a lot of pre-planning before anything has actually happened. We used to call that waterfall. Planning is not actually a bad thing. It's just when those plans are unrealistic, infeasible, or very rigid that they become a problem. That was always the problem with waterfall. The plan was treated as set in stone and two months into the project it became a bad plan. That still happens a lot. People come up with bad plans all the time and then get sucked into believing in that plan. Being agile means having the tools to adjust the plan when it needs changing. If your PM sells a six month 12 sprint project four months before engineers even look at it, you know it's going to be a mess. The plan is probably wrong and the clock started ticking long before engineers got involved. But on the other hand, when you sell a project, there needs to be more than a "we'll see what we do and how long it will take". This fundamental dilemma was never really solved by agile.
I'm less concerned with agile as a noun or adjective these days. Everybody does some form of that; so there's very little point in splitting hairs over it. I'm more concerned with processes and practices. And as an engineer, cto and product manager, my observation is that processes are introduced when automation and common sense fail. Getting rid of unnecessary process is form of agility that is good. I'm always on the lookout for those.
When it comes to sprints, I treat them exclusively as planning horizons. Checkpoints where we assess where we are relative to the current plan and decide on what to focus on in the near future. We practice continuous integration and continuous deployment. The life cycle of a sprint and of a feature bear very little relation to each other. Work might start one sprint and then a few sprints later the change might get merged and deployed. Or the work is planned, executed, and shipped during a single sprint. Or even in between sprints. I define work here to cover the whole process of inception, business requirements gathering, design, implementation, and deployment. It's fundamentally an asynchronous thing. Features ship when they are ready, not when a sprint ends. Work on features starts either when planned or when prudent/urgent. Some things just can't wait and generally, I like short cycle times for work.
There is no need for synchronization bottlenecks in the form of meetings, commit freezes, sprint reviews, or other things we had to do in the past. Because we have asynchronous tools now. Up until the merge, the feature is not interacting or interfering with the software. After the merge, the CI/CD is fully automated. There's just one manual step: clicking the merge button. Doing this in an agile way means doing that without unnecessary delay but with all the due diligence of testing, reviews, etc. And it's nice if that goes according to a plan.
The agile manifesto is purely common sense, everything else is useless managers je*ing off.
I have had Agile/Scrummy Agile/FrAgile/Enterprise Fragile shoved firmly down my throat in every single job I've work since 2006. Rather than actually let the software professionals do their job, other non-technical people insist on these poor excuses for a micro-management methodology.
Just this week, I was asked by our resident enterprise management consultant to put hourly estimates and actual hours worked on all of my assigned 20+ User Stories. He said "This is Agile 101! All of the best teams in the world do this! Follow the process!" Today, he wants me to add estimates and actual hours to my 20 Bugs and bug-fixes too, plus add tasks to each User Story explained what work I actually did. Nevermind that I'm the only developer 100% allocated to the project, so there's only one person to micro-manage I suppose!
Shouldn't commonsense prevail in these modern times? No? lol :-P
Edit: Is it possible for one to get paid just to rant about how terrible Agile is?