Agile projects have become waterfall projects with sprints(thehosk.medium.com)
thehosk.medium.com
Agile projects have become waterfall projects with sprints
https://thehosk.medium.com/agile-projects-have-become-waterfall-projects-with-sprints-536141801856
209 comments
Maybe the time is right for anti-agile coaches to call all the companies that bought agile coaching over the past 15 years. I guess they'd be talking about why waterfall was best all along.
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.
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.
Yes I definitely feel that technical expertise and trust is needed in decision making for all projects.
In my current team, developers don't have much influence (lol um.. I mean just me as I'm the only 100% full stack) and we have non-technical leadership.
One problem is our tech leader isn't familiar with our programming language or development framework (worked with a different stack entirely).
Also, both the tech leader and the Scrum master do not trust us to make any API or front end changes that aren't listed on the sprint board. Everything must be decided during sprint planning for the two-week sprint.
So, if there's some code that obviously needs refactoring, or small code improvements (i.e. anything that's not on the board), every Pull Request is rejected.
What's that you say? "Create an explanatory task/story ahead of time, and mention it during planning?" Sorry, I've tried that many times and they were all de-prioritised and post-poned.
So, no trust both ways it seems! and now I'm ranting on HN
Edited: grammar
Edited: grammar
>> 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.
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).
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).
Arguing in extremes helps no one. Do a better job in your selection process and setting up proper paper trails and agreements.
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).
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'd love my post to be an argument in extremes for arguments sake. It is, unfortunately, half of my daily work at the moment...
If I recall correctly, "Working software over comprehensive documentation" is part of the Agile Manifesto.
I have seen this transformed into "We don't need documentation, just work on a new feature".
I have seen this transformed into "We don't need documentation, just work on a new feature".
Yeah measuring efforts in hours is the wrong kind of agile. That's the whole point of their effort point system.
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.
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.
Every team I’ve ever seen converts effort to burn down rate and then into time, because that’s what their bosses care about. Now 50 points per week with a team of five is 10 points per person-week or two points per person-day. So a point is 4 Hours.
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.
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.
I really appreciate your comment and yes, I hope I find another team soon.
Or better yet, hopefully I'll be replaced by a script (like an AWS lambda or an Azure function), ánd then I'll have all day to rant on HN. Beware! lol :-]
I find it helpful to distinguish between Agile, the thing that is waterfall in new terminology, and agile, the philosophy of how to flexibly adapt the way of building software to the lay of the land. You "do" Agile, or you "are" agile, never both.
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 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.
> Agile/Scrummy Agile/FrAgile/Enterprise Fragile shoved firmly down my throat
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.
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.
I was in an XP shop in the semi early days, and it really was a grass roots counter reaction to the enterprise over the top culture of the time.
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.
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.
As a fellow anti-agile dev, I can understand why its so prevalent. Labour estimates are crucial for business, even if they're bad - the goal is to improve iteratively over time and gradient-descend towards an accurate picture of resource allocation.
Is there a better way to do this than agile? No duh, but that's another topic. :-)
Is there a better way to do this than agile? No duh, but that's another topic. :-)
>Labour estimates are crucial for business, even if they're bad - the goal is to improve iteratively over time and gradient-descend towards an accurate picture of resource allocation.
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)
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)
That's so true, and why should one try to estimate non-trival work that we haven't done before, and make those estimates deadlines? Or worse, a higher management sets a deadline because of something (for example: launch advertising has already been paid for, so you must get it done by October or else) and you're now tied to that.
I think it is premature optimisation to estimate absolutely every fine-grained task and I feel it's born out of the desire to look effecient.
It makes sense to estimate R&D, it also makes sense to have limits. (Eg. some startup wants to solve global fidgeting, they raise a lot of money, and they have 3-4 ideas, so they allocate half of their money and one year on their best idea, then half of the remaining and half of a year on the second best, and ...)
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.
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.
But most part of work that got funding is trivial. Frontend, backend, CRM, backoffice, data this, data that, ETL, audit, backup, devops, cache, mobile, blablabla.
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.
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 think you're missing the part where people who don't do software are asking people who do software.
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.
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.
I'm happy to provide whatever estimates are desired by the business, and I'm sure all other programmers would too. But...most of the time I'm estimating something that I haven't done before (or for a long while), so they're bogus!
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!
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!
Estimates become deadlines because most managers don't understand the terms 'statistical variance' and 'sample size', not because the estimates are made. ;)
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.
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've been lucky in that I haven't had to argue with agile consultants claiming their 90s project management techniques are agile. I feel fairly confident I'd raise holy hell until either they fuck off or admit that our organisation is no longer agile. You want to work like it's the roaring 90s again? No worries! Just don't lie to me to get me in the door. In this job market we have options.
Your words honestly give me hope that there's a better place to work! lol
I promise you there are! My most recent interview was me interviewing them. I grilled multiple managers over multiple interviews over their culture, ways of work, their expectations, etc. I made my expectations crystal clear, and they accepted these without question. If they lied I'll simply leave. Tick that little box in LinkedIn and start interviewing workplaces for one which aligns with your values. It's easily the best time in 40 years to be shopping around for better employers.
I think I'll take your advice and start ticking that LinkedIn box tonight! Cheers!
I've seen my fair share of broken "Agile" processes but officially estimating bugs for more than "hey, do you think this is small or big?" for urgent stuff sounds even more terrible.
I'm sorry you have to endure this :(
I'm sorry you have to endure this :(
Sounds like you're working with someone who has never even taken the time to read the agile manifesto.
https://agilemanifesto.org/
There is no mention of estimates at all lol.
https://agilemanifesto.org/
There is no mention of estimates at all lol.
Lol omg in my last project team, no one was gathering requirements or doing analysis at all - noone! The developers asked every single day for someone to write down some basic requirements.
Someone from the "product owner" team called is into a meeting to lecture us about "true Agile" and "The Agile Manifesto"....still no requirements after that! So I just left the team and cried.
I posted this same sentiment just yesterday: https://news.ycombinator.com/item?id=32502498
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?
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?
Surely you realize project development meta-data is far far more important and valuable than actual software development. How are managers going to fill excel sheets and make bar charts for powerpoint slide decks to show off their management prowess without it?
That sounds excruciating. I've had those various pieces but never all at one job. I hope you grind that twerp under your tires while driving away after quitting in some epic fashion.
To be completely fair, what you are describing is not truly agile :)
Aha! Now I'm rich! :-D
Great software was produced before agile became a thing and lousy software continued to be made after it. And agile is of course not a thing but an adjective. Everybody wants to be seen as doing things in an agile fashion. It's an aspirational goal. The opposite of doing things with some agility would be sluggishly. There's a difference between what people say they do, what they would like to do, and what they actually do. But generally, sluggishness is not something you call out as a good thing. Hence world+dog is doing agile now. Even when they are obviously being ineffective and slow.
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.
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.
There is agile in practice and then there is the https://agilemanifesto.org/
The agile manifesto is purely common sense, everything else is useless managers je*ing off.
The agile manifesto is purely common sense, everything else is useless managers je*ing off.
No True Scotsman is indeed a popular fallacy.
would you buy a tool that creates automated report for you to make management consultant happy?
Even 10-15 years ago I was at a small Thoughtworks event where Martin Fowler was speaking and back then he was using the term “Water-Scrum-Fall” saying most Agile projects he’s seen are waterfall projects wrapped in to two week sprints. At the time Agile/Scrum didn’t have the popularity and only just gaining traction at larger companies.
Today everywhere I work is now “Agile”, doing scrum or similar. It’s all lip service, it’s just another process and ceremonies over the actual spirit and ethos of the original manifesto.
The teams I’ve worked on who didn’t practice agile where actually the most “agile” in the spirit of the manifesto. The teams that did agile, by the book, with the ceremonies and all, dogmatically, doubling down on it, where the least agile in the spirit of the manifesto and not that productive or creative, often micromanaging every tiny detail in a Jira ticket.
Today everywhere I work is now “Agile”, doing scrum or similar. It’s all lip service, it’s just another process and ceremonies over the actual spirit and ethos of the original manifesto.
The teams I’ve worked on who didn’t practice agile where actually the most “agile” in the spirit of the manifesto. The teams that did agile, by the book, with the ceremonies and all, dogmatically, doubling down on it, where the least agile in the spirit of the manifesto and not that productive or creative, often micromanaging every tiny detail in a Jira ticket.
Having worked in actual "waterfall" (which is just a perjorative term) environment in the defense industry long ago, scrum is quite a bit worse in overhead, amount of nonsense, waste, inflexibility, etc.
Agile/scrum is a codeword for "we don't want to / know how to / haven't ever experienced long term planning, but we're going to do it anyway".
Agile/scrum is a codeword for "we don't want to / know how to / haven't ever experienced long term planning, but we're going to do it anyway".
Yup. If you're at a shop that is openly waterfall, they do the requirements gathering and design/prototype work up front so the planning is based on something approaching reality.
"Scrum" has become waterfall without the pre-work so it often descends into iteratively pulling estimates out of your asses.
"Scrum" has become waterfall without the pre-work so it often descends into iteratively pulling estimates out of your asses.
I feel you, and I'm not in software, nominally I'm a Product Owner from the business side. As a business we didn't understand the problem we are facing yet, we have no strategy how to tackle the problem in limited time and with the limited resources we have. And since two weeks Dev Ops is pushing me to come up with a headcount estimate to develop the software solutions we need. Because, of course, upper management needs resource estimates to come up with a reduced budget. It's a mess. And our BPO is fully on-board with this, because career opportunities. And the other POs have close to no experience. The DevOps head never had any IT experience before he became DevOps. We have a whole bunch scrum masters, agile coaches and the like. We have zero functional consultants, and we are looking at an ERP implementation project here. Oh, and the last developer we had on the project didn't see the difference between a technical and a business go-live or the need to conduct proper use-case based user acceptance tests. Or proper requirements definitions, because, you know, agile. It's a mess.
GE, is that you?
And the worst part about it. Holding your ass to the flame over your shit estimate.
Definitely my experience of Scrum! In my part of a FAANG we do a sort of sloppy waterfall and honestly it's the most effective method I've found.
Waterfall was a problem too for those who focused on it to the exclusion of "individuals and interactions". Planning is good, being attached to a plan is not.
Scrum was designed for low trust environments where you have to constantly demonstrate that you are worth your salary, ie consultants. Scrum gives a constant stream of status updates to show you make progress and blocker reports to cover you ass and shift blame to the client, that is very important for consultants but shouldn't be needed in high trust environments.
Agile is also for projects where the customer doesn't know what they want exactly, but they do have an idea what problem they want solved. With an agile project they can pull the plug if stuff doesn't work and they can pivot (within reason) to new features that are discovered during the process.
I have friend in a defence sector waterfall project. It was meticulously planned years ago, the design was locked. Production was started. Everyone knows it'll get scrapped for being out of date when it's finished on schedule in 2024. But they need to finish it anyway, because the deal is hard-locked and there is a big penalty for not delivering or delivering late.
I have friend in a defence sector waterfall project. It was meticulously planned years ago, the design was locked. Production was started. Everyone knows it'll get scrapped for being out of date when it's finished on schedule in 2024. But they need to finish it anyway, because the deal is hard-locked and there is a big penalty for not delivering or delivering late.
Since the system your friend is implementing is already outdated... does that mean that someone else on the defense sector created a better system with a faster development process? Or did the competing developers simply make a better guess at what they should develop in their own own waterfall process?
Military secrets gotten from a drunken friend and all.
But let's say that the problem they're solving doesn't exist anymore, tech advanced and you can get 90% of the same functionality with off the shelf stuff =)
But let's say that the problem they're solving doesn't exist anymore, tech advanced and you can get 90% of the same functionality with off the shelf stuff =)
> where the customer doesn't know what they want exactly, but they do have an idea what problem they want solved
But they also know they need it by Tuesday.
But they also know they need it by Tuesday.
I have done CMMC3 waterfall development, though the maturity model certainly did not dictate that. I have also seen agile done in the way you describe. I have also been on teams and run teams that used agile ceremonies to foster communication and teamwork and set a cadence, while long term planning was going on elsewhere. The two are not mutually exclusive, and even mediocre agile is miles better for delivering working software than bad waterfall.
> even mediocre agile is miles better for delivering working software than bad waterfall.
Well, mediocre anything is usually better than bad something.
Well, mediocre anything is usually better than bad something.
To be clear you and the comment above are describing two different problems. "Water-Scrum-Fall" implies that too much planning was already done up front and the work is just divided into arbitrary 2 week milestones. You are describing a problem where product thinks they don't need to plan long term because they are using "agile". A good product team is somewhere in the middle. A long term user/product vision without getting too specific in implementation or feature priority so that the team can pivot as needed without eating too much cost (there is still a cost to a pivot).
Yeah, at my current place agile is also used for the hardware development side of things. And in all cases, hardware and software, it is, IMHO, just a pure excuse for non-existent requirements management (hardware) or no clue what the business actually needs (software).
Scrum is ritual heavy process by definition. There is no way to do scrum without being heavy on process or dogmatic. The moment you start doing that, your process cease to he Scrum (and any advocate will point at your difference against process as reason why it issues are not cause by Scrum and why it is not scrum)
I found Kanban a lot better for this. You have a sorted list of tasks, and you can only work on a small amount of them at once. A lot less time is spent estimating tasks to fit them in a pointless two week bucket.
Backlog grooming can be done asynchronously, constantly. The PM can push a task to the top without making the developers work harder this sprint. They can go faster or get delayed, because they don't have to meet the arbitrary requirements of a sprint.
Backlog grooming can be done asynchronously, constantly. The PM can push a task to the top without making the developers work harder this sprint. They can go faster or get delayed, because they don't have to meet the arbitrary requirements of a sprint.
Scrum is waterfall in disguise and it always has been. I have never seen scrum be anything but a catastrophe, or a token gesture to appease those who would replace accountability with process.
Scrum doesn't work unless the whole organisation implements it.
Thing is, Scrum doesn't work for most of the organization.
Sales use a sales funnel as their guiding organizational tool. IT operations and support do reactionary work on incoming tickets, and some rather routine and planned projects. HR is almost all routine paperpushing. Legal has to take the time it takes to answer the questions they get, because they have to answer correctly. Market analysis is timeboxed analysis - a spike in agile lingo. Hardware design is innately waterfall. Hardware production is just mindless repetitiveness as fast as you can go... and so on...
They're all different!
Sales use a sales funnel as their guiding organizational tool. IT operations and support do reactionary work on incoming tickets, and some rather routine and planned projects. HR is almost all routine paperpushing. Legal has to take the time it takes to answer the questions they get, because they have to answer correctly. Market analysis is timeboxed analysis - a spike in agile lingo. Hardware design is innately waterfall. Hardware production is just mindless repetitiveness as fast as you can go... and so on...
They're all different!
I have seen scrum turn into hell more then once and it had zero to do with rest of organization doing anything. Literally each time, there was no evil customer pressuring us too much or making bad demands, nothing like that.
Is it a heavy process when you compare it to stuff like Scaled Agile Framework (https://www.scaledagileframework.com/)?
Honestly, from all I've heard and read about "SAFe", it feels like "Take the already-not-very-agile Scrum, and squeeze the last vestiges of agility out of it to make it Enterprise Certified".
Genuinely, I have no idea. Never seen that in practice and I am reading about it first time. That is based on first quick glance at the link you sent.
>The teams I’ve worked on who didn’t practice agile where actually the most “agile” in the spirit of the manifesto. The teams that did agile, by the book, with the ceremonies and all, dogmatically, doubling down on it, where the least agile in the spirit of the manifesto and not that productive or creative, often micromanaging every tiny detail in a Jira ticket.
Personally I have noticed opposite scrum works if you run it by the book first and then start tinkering process based on retros and this "agile" does not work where you implement something that kinda looks scrum or kanban and kinda mess major part like estimates are hours etc. It is not ideal but low trust or multiple stakeholders it works.
Personally I have noticed opposite scrum works if you run it by the book first and then start tinkering process based on retros and this "agile" does not work where you implement something that kinda looks scrum or kanban and kinda mess major part like estimates are hours etc. It is not ideal but low trust or multiple stakeholders it works.
I'll add that empowering the development team via retrospectives and actual authority while having a single interface to the business via product owner are huge contributors to the agility of a team in my opinion.
I think one of the main reasons for wagile is that software development is often seen as capital expenditure rather than operational expenditure (or R&D, although companies love saying it's all R&D to the tax dept). CapEx assumes a fixed(ish) upfront cost and then an ongoing maintenance cost afterwards - which means that you need to be able to estimate the upfront expenditure.
In reality, software development doesn't fit neatly into this model. It's part R&D, part operational expense and part capital expense all at once (even in maintenance phase) - but it's impossible to distinguish which parts are which. The resulting product's value is constantly in flux, which means it is difficult to plan depreciation like a traditional asset.
Agile will always fail unless the way software is accounted for changes too, because the people at the top are looking at budget spreadsheets, not JIRA boards/burndown charts.
In reality, software development doesn't fit neatly into this model. It's part R&D, part operational expense and part capital expense all at once (even in maintenance phase) - but it's impossible to distinguish which parts are which. The resulting product's value is constantly in flux, which means it is difficult to plan depreciation like a traditional asset.
Agile will always fail unless the way software is accounted for changes too, because the people at the top are looking at budget spreadsheets, not JIRA boards/burndown charts.
Basically a new thing has been introduced into the world and the world has tried to fit it into an existing paradigm and when it doesn't fit, well let's invent a new paradigm that looks like the old one but better...
The problem isn't how the business solves software. It's how software dissolves the business.
The problem isn't how the business solves software. It's how software dissolves the business.
> I think one of the main reasons for wagile is that software development is often seen as capital expenditure rather than operational expenditure
Depending on where you are, you might find that allocating expenses as capitalisable is much more tax-efficient, hence the desire from the business (finance, specifically) to treat it that way.
Depending on where you are, you might find that allocating expenses as capitalisable is much more tax-efficient, hence the desire from the business (finance, specifically) to treat it that way.
Just once in my career I'd like to work on a project that resembles the original intent of agile. So far I've had 3 jobs that "did agile" and in each case there was a long list of requirements and a fixed deadline many months in the future for each "agile" project. No one wants to hear "We don't know when we will deliver X because we're working on Y this sprint".
In one company that proclaimed to do “agile”, our release was suddenly halted by the business, because they came up with some new requirements. These were regulatory requirements they of course long knew about, but only now decided to throw at us, because “agile” and it’s an ongoing product. All good and well, except that they now demanded the product to be released within two weeks, because that’s when the marketing campaign went live.
Of course, our PM and scrum master, just went along and put us all into a room, to estimate and figure out how we could deliver. All our estimates were proclaimed wrong, and we had to estimate again, eventually devs just gave a number to make it fit within the two weeks.
Needless to stay, the product did not launch, and the developers got blamed for not being flexible enough. That’s how agile works in big companies, use agile as a term for everything wen it fits, use it as a way to blame others. Scrum masters are just there to pass along communication from the business, and absorb complains from developers. It’s just another one-way street of communication.
Of course, our PM and scrum master, just went along and put us all into a room, to estimate and figure out how we could deliver. All our estimates were proclaimed wrong, and we had to estimate again, eventually devs just gave a number to make it fit within the two weeks.
Needless to stay, the product did not launch, and the developers got blamed for not being flexible enough. That’s how agile works in big companies, use agile as a term for everything wen it fits, use it as a way to blame others. Scrum masters are just there to pass along communication from the business, and absorb complains from developers. It’s just another one-way street of communication.
> All our estimates were proclaimed wrong
I've seen something like this happen, and I must wonder. The only ones that can give an estimation are the people who will actually do the work. This estimation will likely be also wrong, but it's their job and their estimation. How can anyone else dispute it?
Very tempted to reply "well, how about you do it in two weeks then?". I never do, because I want to keep my job. And nobody is ever punished for missing deadlines, anyway.
I've seen something like this happen, and I must wonder. The only ones that can give an estimation are the people who will actually do the work. This estimation will likely be also wrong, but it's their job and their estimation. How can anyone else dispute it?
Very tempted to reply "well, how about you do it in two weeks then?". I never do, because I want to keep my job. And nobody is ever punished for missing deadlines, anyway.
> I never do, because I want to keep my job. And nobody is ever punished for missing deadlines, anyway.
Pretty much, the general consensus amongst developers was to just go along with whatever the scrum master is saying, just so that we could at least get out of the meeting and start our work. Missing deadlines was pretty common, getting blamed was pretty common, but you won't get fired. Perhaps you'll get moved to a different team, where the same story repeats itself.
Pretty much, the general consensus amongst developers was to just go along with whatever the scrum master is saying, just so that we could at least get out of the meeting and start our work. Missing deadlines was pretty common, getting blamed was pretty common, but you won't get fired. Perhaps you'll get moved to a different team, where the same story repeats itself.
They dispute it because they assume that developers are padding their estimates. You know, it will probably take 2 weeks, so double it and then double it again.
That's using the "what's the earliest date you can't prove you won't be finished by" method of estimation.
And for every story like this, where developers can't do things they know they need to because all decisions are top-down . . . I say unionize. Management needs to know that IC devs are a force to be reckoned with and not code-bots. And then use the union to get contracts that allow devs more control over decision-making.
We don't need unions for better wages. What we're often missing is respect, dignity. (Yes, sorta like sex workers.)
We don't need unions for better wages. What we're often missing is respect, dignity. (Yes, sorta like sex workers.)
> No one wants to hear "We don't know when we will deliver X because we're working on Y this sprint".
You need a good PM who knows how to handle this for you. I did agile correctly in a large bureaucratic organization because our PM shielded us from those requests, and basically told the business that they could prioritize the requests appropriately in the next sprint planning session.
If they showed up and participated, they got to duke it out with the other competing business units about who got priority. If they didn't show up, we told them that their work was not prioritized because they failed to attend the planning session.
You need a good PM who knows how to handle this for you. I did agile correctly in a large bureaucratic organization because our PM shielded us from those requests, and basically told the business that they could prioritize the requests appropriately in the next sprint planning session.
If they showed up and participated, they got to duke it out with the other competing business units about who got priority. If they didn't show up, we told them that their work was not prioritized because they failed to attend the planning session.
All this really means is either
- You can only ever work on projects which are finished in one sprint.
- You have no idea how, when, or even why the big initiative you're working on will finish.
It's not practical to build a business this way, what happens when one team pulls priority and a different one next week? what happens when a multi-sprint project becomes a multi-year forever project?
You can get around this if someone (such as a manager/PM/lead) converts the sprint process back to a practical roadmap/design. However not involving the sprint team in this process merely robs them of autonomy. At best, the absence of autonomy for an individual in a scrum team might be the point of the whole process.
- You can only ever work on projects which are finished in one sprint.
- You have no idea how, when, or even why the big initiative you're working on will finish.
It's not practical to build a business this way, what happens when one team pulls priority and a different one next week? what happens when a multi-sprint project becomes a multi-year forever project?
You can get around this if someone (such as a manager/PM/lead) converts the sprint process back to a practical roadmap/design. However not involving the sprint team in this process merely robs them of autonomy. At best, the absence of autonomy for an individual in a scrum team might be the point of the whole process.
If you have a large project, you break it down into smaller parts. If you know what needs to be done, throw it in the backlog, give it a broad estimate, sort it, and you have an estimate for about how long it will take. If you have unknowns, make resolving them a task. If you need things from the business, give them tasks.
> It's not practical to build a business this way, what happens when one team pulls priority and a different one next week?
Someone has to own the project, and have the final say on priority. If the project is at risk due to shifting priorities, you need to escalate this to them for a final decision.
> You can get around this if someone (such as a manager/PM/lead) converts the sprint process back to a practical roadmap/design. However not involving the sprint team in this process merely robs them of autonomy.
If you have everything in your backlog, you can judge velocity to come up with an estimated timeline given all of the assumption at the current state. This isn’t a promise, it’s an estimate. When the business shows up to sprint planning and sprinkles around new ideas for high priority tasks, you always remind them that this means deprioritizing other tasks which will affect timeline.
> what happens when a multi-sprint project becomes a multi-year forever project?
Yes, at the end of the project you will likely have done something very different than what you originally put in your backlog, because the business will have changed their minds 100 times. This is the point! The point is to track close to building what they want, not to build what they wanted 8 months ago.
> It's not practical to build a business this way, what happens when one team pulls priority and a different one next week?
Someone has to own the project, and have the final say on priority. If the project is at risk due to shifting priorities, you need to escalate this to them for a final decision.
> You can get around this if someone (such as a manager/PM/lead) converts the sprint process back to a practical roadmap/design. However not involving the sprint team in this process merely robs them of autonomy.
If you have everything in your backlog, you can judge velocity to come up with an estimated timeline given all of the assumption at the current state. This isn’t a promise, it’s an estimate. When the business shows up to sprint planning and sprinkles around new ideas for high priority tasks, you always remind them that this means deprioritizing other tasks which will affect timeline.
> what happens when a multi-sprint project becomes a multi-year forever project?
Yes, at the end of the project you will likely have done something very different than what you originally put in your backlog, because the business will have changed their minds 100 times. This is the point! The point is to track close to building what they want, not to build what they wanted 8 months ago.
> you have a large project, you break it down into smaller parts. If you know what needs to be done, throw it in the backlog, give it a broad estimate, sort it, and you have an estimate for about how long it will take. If you have unknowns, make resolving them a task. If you need things from the business, give them tasks.
What’s the difference between this and “waterfall” then?
What’s the difference between this and “waterfall” then?
> What’s the difference between this and “waterfall” then?
The difference between this and “traditional waterfall” is that you do this continuously, simultaneously with implementation, and not just once, up-front before building anything.
(At least that's the common picture of “waterfall” -- which of course proponents of various “agile” methodologies prefer to contrast their product against -- though IIRC Brooks or someone had proposed / recorded iteration on this in parallel with implementation long before the Agile Manifesto.)
The difference between this and “traditional waterfall” is that you do this continuously, simultaneously with implementation, and not just once, up-front before building anything.
(At least that's the common picture of “waterfall” -- which of course proponents of various “agile” methodologies prefer to contrast their product against -- though IIRC Brooks or someone had proposed / recorded iteration on this in parallel with implementation long before the Agile Manifesto.)
It’s a vague todo list instead of a project plan. There are no dates or resources assigned to tasks. And you’re not committed to doing any of it yet. You might change items, add items, or remove items.
Nice summary and also my view.
I like to say that the whole point in the estimates is to set expectations. At that point a discussion is had with the stake holders.
If you know the velocity of the team, because it’s actually been measured (a rare thing in my experience), you will have a good idea on what is actually possible within a time frame.
I like to say that the whole point in the estimates is to set expectations. At that point a discussion is had with the stake holders.
If you know the velocity of the team, because it’s actually been measured (a rare thing in my experience), you will have a good idea on what is actually possible within a time frame.
Your first point is exactly true. We design concepts with certain goals in mind, then that gets cut down into something that takes one or two sprints of work "to see the results", which never come because it does not even cover mvp use cases. Then the rest never gets built.
Absolutely lack in long-term thinking, goals and vision.
Absolutely lack in long-term thinking, goals and vision.
This is true for any management role: protect those under you from the ridiculousness coming from above.
Filter out the crazy (which can be the entirety) and then pass down to the team the best way you can figure to move things forward.
I managed to do this for a while. It's hard on the ol' mental health though.
Filter out the crazy (which can be the entirety) and then pass down to the team the best way you can figure to move things forward.
I managed to do this for a while. It's hard on the ol' mental health though.
This is exactly the job of the Scrum Master in the Agile process.
<insert meme of soldier protecting sleeping child>[0]
The SM is supposed to be part of the team, not part of management.
[0] https://pics.me.me/the-silent-protector-sales-department-man...
<insert meme of soldier protecting sleeping child>[0]
The SM is supposed to be part of the team, not part of management.
[0] https://pics.me.me/the-silent-protector-sales-department-man...
Yeah, in theory you’re technically correct, but in my experience, because “scrum masters are on the team” they’re usually a developer with little political or managerial power. I prefer having the scrum master and the PM on the team. As a pair they can navigate technical challenges and business politics effectively.
There's nothing wrong with a full backlog. And also not with a deadline defining when something should be available. Sometimes such deadlines come from third parties (e.g. retirement of an already deprecated API version), a larger corporate program that requires multiple projects to deliver in sync, or opportunities based on external factors where marketing is already concentrating on a specific date, ...
My approach is the MVP way, where the team delivers everything that is necessary to meet the customers goals. All the bells an whistles can be qdded once those goals are met. If the goal can't be met within the given timeframe, then it's a problem of unrealistic expectations. But most of the times we have met the deadline while otheres with their bloated waterfall projects were late.
My approach is the MVP way, where the team delivers everything that is necessary to meet the customers goals. All the bells an whistles can be qdded once those goals are met. If the goal can't be met within the given timeframe, then it's a problem of unrealistic expectations. But most of the times we have met the deadline while otheres with their bloated waterfall projects were late.
I've had one and it was by necessity as we were building something new and we were a tiny company. It's great when it works.
This has been my experience as someone who has worked at a variety of large and small companies. Do you have a (generally B2B) product to market, with fixed release increments, and features set by some external marketing / sales team? Your agile is probably going to be "that agile." Are you a small company developing a new product that you don't fully understand yet as you're still developing it? Your agile will probably be closer to the experience people are seeking.
I’ve worked on three teams which have to some degree been agile in spirit. The first didn’t really have a planning philosophy at all, and was mostly agile in spirit by virtue of that other than when crunch time got really chaotic and stressful. The next took a minor opportunitistic rebellion to achieve, in the midst of a significant culling of management and a sympathetic view from one of the remaining leadership. My current job is thematically between the two and surprisingly adaptable even while being conscious of pressures.
All of these have been unusual work environments so I’m not sure I have reproducible insight to offer (though the second case probably is more reproducible than not at all, and I highly encourage anyone with the opportunity to throw down and choose your own planning adventure to coordinate with your team and see what shakes out; you have nothing to lose but your estimation poker hand).
All of these have been unusual work environments so I’m not sure I have reproducible insight to offer (though the second case probably is more reproducible than not at all, and I highly encourage anyone with the opportunity to throw down and choose your own planning adventure to coordinate with your team and see what shakes out; you have nothing to lose but your estimation poker hand).
Having managed agile projects at startups and big tech, there's a few problems that were common:
1) lack of customer feedback loop - agile is meant to ship features quickly to customers, get feedback, and iterate/enhance/pivot based on their feedback. Often times the projects were simply things that "had to be done" and the whole agile process was not necessary.
2) inaccurate estimation - projects would start with asking engineers to estimate "t-shirt size" efforts on user stories, and what happened in reality is the projects always ended up taking longer than expected due to unknowns, dependencies etc. I've only worked with a few senior engineers who can accurately estimate, but junior engineers starting their careers in a big company, it's a tall order to ask them to be accurate.
1) lack of customer feedback loop - agile is meant to ship features quickly to customers, get feedback, and iterate/enhance/pivot based on their feedback. Often times the projects were simply things that "had to be done" and the whole agile process was not necessary.
2) inaccurate estimation - projects would start with asking engineers to estimate "t-shirt size" efforts on user stories, and what happened in reality is the projects always ended up taking longer than expected due to unknowns, dependencies etc. I've only worked with a few senior engineers who can accurately estimate, but junior engineers starting their careers in a big company, it's a tall order to ask them to be accurate.
As I have taken on more senior roles I’ve learned how to estimate better and most of the time it’s just estimating much more time
Good old Miracle Worker formula. Take your original estimate and double it. =)
I've taken to doubling my estimate and then stepping up to the next order of magnitude.
Eg. 2 hours becomes 4 days. It allows for delivery, QA, bug fixes and documentation.
Eg. 2 hours becomes 4 days. It allows for delivery, QA, bug fixes and documentation.
Just use Scotty's rules :)
#1 is I think often the biggest issue, or rather a direct easy to spot symptom of the central issue which is that "agile" is just blanket applied as a development methodology to everything, including many projects that have no business being agile, while the project requirements aren't agile at all.
Agile is better thought of as a product management than a development methodology. It is meant to be agile in developing your product to iterate quickly and respond to feedback from real users. It's a great fit after a MVP is released to users to iterate on their interaction in a responsive way. It's not an ideology to be followed religiously for all projects with all constraints (particularly those where those paying for it want specific features/dates are a poor fit).
- If a given project is only agile on the development side and not also the project and product management/sponsor side, there's going to be a ton of friction.
- If all projects use the same methodologies (be it agile or waterfall or some other new hip flavor) to develop regardless of their scope and needs and sponsor, there's going to be a ton of friction.
- If your teams adjust their approach to meet the needs of the project at hand, and all aspects of the team for a given project are in sync with that approach not just developers, you just may be able to glean a relatively smooth experience.
Agile is better thought of as a product management than a development methodology. It is meant to be agile in developing your product to iterate quickly and respond to feedback from real users. It's a great fit after a MVP is released to users to iterate on their interaction in a responsive way. It's not an ideology to be followed religiously for all projects with all constraints (particularly those where those paying for it want specific features/dates are a poor fit).
- If a given project is only agile on the development side and not also the project and product management/sponsor side, there's going to be a ton of friction.
- If all projects use the same methodologies (be it agile or waterfall or some other new hip flavor) to develop regardless of their scope and needs and sponsor, there's going to be a ton of friction.
- If your teams adjust their approach to meet the needs of the project at hand, and all aspects of the team for a given project are in sync with that approach not just developers, you just may be able to glean a relatively smooth experience.
I wonder if there’s one of those observational “laws” that states that any idea, no matter how flexible and open-ended, must eventually harden into a rigid unthinking cargo cult.
As a corollary, all ideologies end up as self-parody, contradicting their original intentions in sometimes egregious ways.
> The retrospectives are gone
Oh, they’re still there, they take like seventy-five minutes, they do produce some good observations, aired-out grievances, and action items, the latter of which are never ever followed upon in full or even half.
As a corollary, all ideologies end up as self-parody, contradicting their original intentions in sometimes egregious ways.
> The retrospectives are gone
Oh, they’re still there, they take like seventy-five minutes, they do produce some good observations, aired-out grievances, and action items, the latter of which are never ever followed upon in full or even half.
John List, an economist, has a new book out called The Voltage Effect: How to Make Good Ideas Great and Great Ideas Scale [1]. I think it address your point in a more general way and has identified some failure modes that lead to a negative end state. [1] is a summary of the ideas from the author.
[1] https://nextbigideaclub.com/magazine/voltage-effect-make-goo...
[1] https://nextbigideaclub.com/magazine/voltage-effect-make-goo...
I have found a simple rule useful: if you know what the end product will look like and how it should behave, you're not "doing Agile", and there's no point in pretending that you are. If your PM or client can look at a piece of software and say "this doesn't behave like we expect it to" or starts asking "when can you have that done?" (and they're referring to any unit of time smaller than a quarter-decade), batten down the hatches and start writing requirements.
The last job I worked at still had defined features, test cases, and release dates for its projects, but since they were "Agile" they stored all of their "user stories" (read: free-form requirements that needed to be built according to a literal separate design document) in Jira tickets. I worked there until the urge to play in traffic became too strong.
The last job I worked at still had defined features, test cases, and release dates for its projects, but since they were "Agile" they stored all of their "user stories" (read: free-form requirements that needed to be built according to a literal separate design document) in Jira tickets. I worked there until the urge to play in traffic became too strong.
I think the reason why Agile worked, back in the days of the Manifesto authors, is not because of any specific thing in that Manifesto ... but because you had a small team that could decide how they wanted to work. This is antithetical to most corporate management.
Also presumably they were experienced engineers who could be trusted to make good decisions. But not all teams are like that. I have worked with many engineers who are completely lost, or will routinely make the worst decision possible, any time the requirements are exactly spelled out for them.
agile will not fix the problems of incompetency in engineering (or stakeholders for that matter).
But agile is often sold as a tool to fix such incompetencies i reckon!
But agile is often sold as a tool to fix such incompetencies i reckon!
Little a agile was supposed to be an iterative system that the team could adopt and adapt to their needs. These forms were intended to make developers more effective.
The manifesto was so small and stark because those were the few things that all of the manifesto signatories could agree on. They were trying to find consensus on principles that made products successful.
Big A Agile is much more rigid and top-down, marketed to management. Success there means selling training and certifications. Nothing more.
The manifesto was so small and stark because those were the few things that all of the manifesto signatories could agree on. They were trying to find consensus on principles that made products successful.
Big A Agile is much more rigid and top-down, marketed to management. Success there means selling training and certifications. Nothing more.
Also, they were thought-leaders with an interest in exploring better ways of working, and presenting what they found. As such, they surely adapted themselves and bent some rules. They were not following recipes in some book about Agile. But if you look at agile coaches preaching on LinkedIn, there is an endless stream of posts about the true way to do agile.
Small teams can only get a small amount of work done. How long would a team of 7 take to deliver something like Word or GNU/linux (both not just the kernel, but everything involves in a OS/distribution )
I mean, yes, thats literally what it is. Hilariously we attribute waterfall from Royce[0] in which he visually shows a waterfall like process, only to describe it as an iterative process (and essentially agile scrum).
> still makes projects late.
But under the concepts of the agile manifesto there is no concept as "late" so I'm not sure why the author refers to a project as being late. The whole point of an agile process is to be able to iterate quickly. 2 weeks is a generally accepted timeframe in which you can revert attention if what you develop is incorrect. So whats the gripe?
[0] - http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970...
> still makes projects late.
But under the concepts of the agile manifesto there is no concept as "late" so I'm not sure why the author refers to a project as being late. The whole point of an agile process is to be able to iterate quickly. 2 weeks is a generally accepted timeframe in which you can revert attention if what you develop is incorrect. So whats the gripe?
[0] - http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970...
Running waterfall on a two week cadence burns out engineers by forbidding them from doing any work with a timeline greater than one week.
After all, half a week is burned, minimum, at the beginning and end of the sprint on process paperwork and screaming at disconnected Zoom windows.
Next sprint, their week of work is frequently reverted or irreparably hacked to meet an arbitrary deadline.
Also, the product sucks, but management metrics ensure people that focus on shuffling the titanic deck chairs instead of fixing it get promoted.
If a group of engineers puts in a heroic two month effort to save the project, their metrics tank, and they end up reporting to the first group until their options run out or they are laid off.
After all, half a week is burned, minimum, at the beginning and end of the sprint on process paperwork and screaming at disconnected Zoom windows.
Next sprint, their week of work is frequently reverted or irreparably hacked to meet an arbitrary deadline.
Also, the product sucks, but management metrics ensure people that focus on shuffling the titanic deck chairs instead of fixing it get promoted.
If a group of engineers puts in a heroic two month effort to save the project, their metrics tank, and they end up reporting to the first group until their options run out or they are laid off.
Metrics. The way the MBAs will throw the world (further) into a meat grinder.
My wife is a teacher and she was telling me that a panel who was responsible for hiring a new permanent teacher was "not allowed" to consider their prior knowledge of the applicants' teaching abilities, and had to go with the teacher who best answered the Department of Education's paperwork questions.
They chose (against their personal better judgement) the worse of the two teachers because "on paper" they appeared better.
I'm currently struggling to find a job (my current contract ends in a couple of weeks), and I just don't have the ability to be the level of ass-kiss dishonest, straight-laced, official textbook answers that seem to be what lands the fish. I'll get something eventually, and that's all I want, but it really feels like the world is tuned to the sizzle even when you can smell that the steak is rotting.
My wife is a teacher and she was telling me that a panel who was responsible for hiring a new permanent teacher was "not allowed" to consider their prior knowledge of the applicants' teaching abilities, and had to go with the teacher who best answered the Department of Education's paperwork questions.
They chose (against their personal better judgement) the worse of the two teachers because "on paper" they appeared better.
I'm currently struggling to find a job (my current contract ends in a couple of weeks), and I just don't have the ability to be the level of ass-kiss dishonest, straight-laced, official textbook answers that seem to be what lands the fish. I'll get something eventually, and that's all I want, but it really feels like the world is tuned to the sizzle even when you can smell that the steak is rotting.
> After all, half a week is burned, minimum, at the beginning and end of the sprint on process paperwork
When you start a 2-week sprint how do you magically understand what you're planning to build if you don't do any planning...?
When you start a 2-week sprint how do you magically understand what you're planning to build if you don't do any planning...?
They always were.
Worse even, 'agile' gets used as an excuse for project managers and architects not to document requirements or plan properly, even in situations where all the goals can be known ahead of time, because that's a lot of work.
It's also rife with "It's not working? Clearly what we need is more interference, more monitoring by management, hire more 'agile coaches' to inflict more 'ceremonies' on developers and use even more of their time."
Never mind that planning is always thrown out of the window because priorities shift. Never mind that none of the changes that were identified as necessary in the retro get any sort of management buy-in, rendering it pointless. Never mind that 'stand-up' has become a management-run progress-report session. Never mind that this kills the feedback loop and developer-lead benefits that are supposed to come from this. No! Do more agile! Whatever the hell that means! Do it harder!
Worse even, 'agile' gets used as an excuse for project managers and architects not to document requirements or plan properly, even in situations where all the goals can be known ahead of time, because that's a lot of work.
It's also rife with "It's not working? Clearly what we need is more interference, more monitoring by management, hire more 'agile coaches' to inflict more 'ceremonies' on developers and use even more of their time."
Never mind that planning is always thrown out of the window because priorities shift. Never mind that none of the changes that were identified as necessary in the retro get any sort of management buy-in, rendering it pointless. Never mind that 'stand-up' has become a management-run progress-report session. Never mind that this kills the feedback loop and developer-lead benefits that are supposed to come from this. No! Do more agile! Whatever the hell that means! Do it harder!
> Worse even, 'agile' gets used as an excuse for project managers and architects not to document requirements or plan properly, even in situations where all the goals can be known ahead of time, because that's a lot of work.
What's the complaint? The higher ups have a scapegoat, so they're happy. And you can rejoice in it not being you or any of your friends!
What's the complaint? The higher ups have a scapegoat, so they're happy. And you can rejoice in it not being you or any of your friends!
The point of Agile is to give power to the team and also to use The Process to protect them from ad-hoc management interference during sprint.
10 The stakeholder says which features are the most important and gives the team a prioritised list.
20 The team goes through the list and determines how much work each will take. At this point the stakeholder might be asked to re-prioritise.
30 Team picks tasks from the top of the list for each sprint and shows the result to the stakeholder after the sprint in a demo.
GOTO 10
That's it.
If someone from outside the team has "a quick request" that needs to be done ASAP, the scrum master shows them the prioritised list and asks them what features should be dropped. If the someone is stupid enough to pick something, they can go wrestle with the stakeholder(s) of the deprioritised tasks about whose thing is more important.
The team doesn't see anything of said quick request, they can focus on their sprint.
If the stakeholder has any "quick requests" The Process says all work for the sprint is to be scrapped (no one really does it, but you don't tell that to the customer) and the sprint is restarted with the "quick request" included. In my 20 years in the business, zero customers have taken the "scrap the sprint" route.
But none of this will work unless an expensive enough consultant can convince the higher ups that it's a good idea. If they're not with the process, you get scrumfalls, 45 minute standups and other crap.
10 The stakeholder says which features are the most important and gives the team a prioritised list.
20 The team goes through the list and determines how much work each will take. At this point the stakeholder might be asked to re-prioritise.
30 Team picks tasks from the top of the list for each sprint and shows the result to the stakeholder after the sprint in a demo.
GOTO 10
That's it.
If someone from outside the team has "a quick request" that needs to be done ASAP, the scrum master shows them the prioritised list and asks them what features should be dropped. If the someone is stupid enough to pick something, they can go wrestle with the stakeholder(s) of the deprioritised tasks about whose thing is more important.
The team doesn't see anything of said quick request, they can focus on their sprint.
If the stakeholder has any "quick requests" The Process says all work for the sprint is to be scrapped (no one really does it, but you don't tell that to the customer) and the sprint is restarted with the "quick request" included. In my 20 years in the business, zero customers have taken the "scrap the sprint" route.
But none of this will work unless an expensive enough consultant can convince the higher ups that it's a good idea. If they're not with the process, you get scrumfalls, 45 minute standups and other crap.
Sounds like someone is working at a growing company.
Agile is great when you can be agile. Not every busyness fits into that mold. Some software projects are big, regulated, public, etc. They need more structure.
For instance, you don’t update the cloud provider at a 500 company with agile. It takes planning, coordination, contingency plans, and often 2-3+ year timeline. Agile is for smaller companies or smaller projects that can be broken up into sprint size pieces. Many are not.
Agile is great when you can be agile. Not every busyness fits into that mold. Some software projects are big, regulated, public, etc. They need more structure.
For instance, you don’t update the cloud provider at a 500 company with agile. It takes planning, coordination, contingency plans, and often 2-3+ year timeline. Agile is for smaller companies or smaller projects that can be broken up into sprint size pieces. Many are not.
You're just applying the concept at the wrong scale.
Honestly I hate the term agile, it should really be "open communication", and it can apply on even a daily timeline
Waterfall "style" is a directive comes from on high to get every service running on the new cloud provider, and 2 years later those on high find out we're still 2 years away from completion and along the way we spent months working on tiny aspects of it because the directive couldn't capture every nuance.
Agile "style" is where you get to return feedback to "on high" before that point. If there's a service that represents 5% of our revenue but required 30% of the effort, you get a chance to push back and talk to stakeholders before committing that.
-
It's really the idea of "further unraveling uncertainty as you go along instead of assuming you accounted for all of it at the start" that makes agile useful, and that can work on any project of any scale.
No matter how rigid the parameters of a project, at some level there's uncertainty (otherwise you'd have perfect estimates and nothing would ever be late). So better that "on high" learns more details about that uncertainty as you go along, and you get input on how to handle that uncertainty... than in a giant "we're flailing" moment later down the line.
I think people focus too much on the whole "no committing to deadlines" idea, when that is not at all central to the value proposition, and honestly feels like a feel good platitude that doesn't actually work when it meets reality regardless of how small you are
Honestly I hate the term agile, it should really be "open communication", and it can apply on even a daily timeline
Waterfall "style" is a directive comes from on high to get every service running on the new cloud provider, and 2 years later those on high find out we're still 2 years away from completion and along the way we spent months working on tiny aspects of it because the directive couldn't capture every nuance.
Agile "style" is where you get to return feedback to "on high" before that point. If there's a service that represents 5% of our revenue but required 30% of the effort, you get a chance to push back and talk to stakeholders before committing that.
-
It's really the idea of "further unraveling uncertainty as you go along instead of assuming you accounted for all of it at the start" that makes agile useful, and that can work on any project of any scale.
No matter how rigid the parameters of a project, at some level there's uncertainty (otherwise you'd have perfect estimates and nothing would ever be late). So better that "on high" learns more details about that uncertainty as you go along, and you get input on how to handle that uncertainty... than in a giant "we're flailing" moment later down the line.
I think people focus too much on the whole "no committing to deadlines" idea, when that is not at all central to the value proposition, and honestly feels like a feel good platitude that doesn't actually work when it meets reality regardless of how small you are
If you’ve worked in software for longer than a single project, you already know that software is impossible to precisely estimate and no two projects are alike. Anyone who claims that waterfall requires perfect estimates is using the term incorrectly.
_All_ software projects include an element of discovery as new details are discovered, technical challenges are encountered, etc. To think otherwise is naive.
Waterfall in software means there are fixed timelines and a fixed starting scope to work against. This helps align the efforts of multiple teams that have their own deliverables and timelines. As a project progresses, the timelines and scope are reassessed. This is true of any methodology.
Full agility is when you can pivot quickly to new opportunities. This flexibility requires a small scale. Most larger companies have too much going on to allow for something like this yet they also allow for agility. For instance, a security incident is not going to be neglected because of an ongoing project. Waterfall in software is not what the author makes it out to be.
_All_ software projects include an element of discovery as new details are discovered, technical challenges are encountered, etc. To think otherwise is naive.
Waterfall in software means there are fixed timelines and a fixed starting scope to work against. This helps align the efforts of multiple teams that have their own deliverables and timelines. As a project progresses, the timelines and scope are reassessed. This is true of any methodology.
Full agility is when you can pivot quickly to new opportunities. This flexibility requires a small scale. Most larger companies have too much going on to allow for something like this yet they also allow for agility. For instance, a security incident is not going to be neglected because of an ongoing project. Waterfall in software is not what the author makes it out to be.
No one said anything about waterfall requiring perfect estimates?
No one proposed or implied that any software doesn't have an element of discovery?
Obviously there's wiggle room for all of these terms but you're defining waterfall so loosely that you didn't describe waterfall at all (nothing about fixed starting scope and fixed timelines requires waterfall...)
Then on the flip side you're defining agile so precisely that almost no one can meet it. I mean what is "full agility"?
It feels like you invented a term for a theoretical "perfect" implementation of agility, but my entire point is that you don't need to go off the deep end with the concept of agile to reap the benefits.
-
Waterfall and agile mentalities don't need to be mutually exclusive, which is exactly what the article is about.
I lead projects on self-driving cars. When the NHTSA has hard requirements we don't get to go back and ask them to reconsider, but that doesn't mean that within implementing long-tail features we can't be have an agile process for making sure the teams implementing parts of those features aren't blindly banging away with no iteration on their approach.
Waterfall and agile should just be means to an end. The weird want some people have for one to be the "valid" approach has never made sense to me.
No one proposed or implied that any software doesn't have an element of discovery?
Obviously there's wiggle room for all of these terms but you're defining waterfall so loosely that you didn't describe waterfall at all (nothing about fixed starting scope and fixed timelines requires waterfall...)
Then on the flip side you're defining agile so precisely that almost no one can meet it. I mean what is "full agility"?
It feels like you invented a term for a theoretical "perfect" implementation of agility, but my entire point is that you don't need to go off the deep end with the concept of agile to reap the benefits.
-
Waterfall and agile mentalities don't need to be mutually exclusive, which is exactly what the article is about.
I lead projects on self-driving cars. When the NHTSA has hard requirements we don't get to go back and ask them to reconsider, but that doesn't mean that within implementing long-tail features we can't be have an agile process for making sure the teams implementing parts of those features aren't blindly banging away with no iteration on their approach.
Waterfall and agile should just be means to an end. The weird want some people have for one to be the "valid" approach has never made sense to me.
> No one said anything about waterfall requiring perfect estimates?
That is literally how definition of waterfall starts. Unless you use waterfall as "the mythical thing I project all my grievances at".
That is literally how definition of waterfall starts. Unless you use waterfall as "the mythical thing I project all my grievances at".
I figure it's implied "no one in this conversation", since outside of this conversation agile and waterfall have both been described in every possible way.
Waterfall "as it should be" was presented as a flawed model: In reality there is no competent team, using waterfall or otherwise, that relies perfect estimates and I wouldn't insult anyone by claiming they're doing so.
Waterfall "as it should be" was presented as a flawed model: In reality there is no competent team, using waterfall or otherwise, that relies perfect estimates and I wouldn't insult anyone by claiming they're doing so.
> In reality there is no competent team, using waterfall or otherwise, that relies perfect estimates and I wouldn't insult anyone by claiming they're doing so.
The waterfall is process where you start by collecting requirements, make estimation and sign contract with set deadline. The rest is development in one go, then testing and then you give result to customer. So yes, it relies on precise estimations. Whatever else you have in mind is not waterfall process. Waterfall does not prescribe how exactly you make estimation nor how do you communicate inside the team.
It has disadvantages which is why no one was using it for decades. Except as straw process to blame when other processes fail or dont prevent dysfunctions. So, management tries to implement scrum, it fails or turns into hell. Then next guy will try to implement Scrum or whatever, claiming he is bringing agile to save us from waterfall. But that is just a way to avoid saying that it was scrum that failed and repeating exact same cycle.
The waterfall is process where you start by collecting requirements, make estimation and sign contract with set deadline. The rest is development in one go, then testing and then you give result to customer. So yes, it relies on precise estimations. Whatever else you have in mind is not waterfall process. Waterfall does not prescribe how exactly you make estimation nor how do you communicate inside the team.
It has disadvantages which is why no one was using it for decades. Except as straw process to blame when other processes fail or dont prevent dysfunctions. So, management tries to implement scrum, it fails or turns into hell. Then next guy will try to implement Scrum or whatever, claiming he is bringing agile to save us from waterfall. But that is just a way to avoid saying that it was scrum that failed and repeating exact same cycle.
There is a difference between a perfect estimate and what you're describing.
Again, literally no competent stakeholder anywhere is expecting a perfect estimate.
Both agile and waterfall both aim for precise estimates.
With agile you're still aiming to have roughly correct story points, or having roughly enough work for your sprint. But you're moving the yardstick on how often you estimate and how you handle missing those estimates.
All of which is why again, I don't see the point in being so rigid in where one ends and the other begins. Waterfall has gone from a punching bag to a real process people follow by adjustment. People seem to miss that while the "OG" waterfall diagram was supposed to be flawed, even in the same document practical improvements were introduced.
Again, literally no competent stakeholder anywhere is expecting a perfect estimate.
Both agile and waterfall both aim for precise estimates.
With agile you're still aiming to have roughly correct story points, or having roughly enough work for your sprint. But you're moving the yardstick on how often you estimate and how you handle missing those estimates.
All of which is why again, I don't see the point in being so rigid in where one ends and the other begins. Waterfall has gone from a punching bag to a real process people follow by adjustment. People seem to miss that while the "OG" waterfall diagram was supposed to be flawed, even in the same document practical improvements were introduced.
> Again, literally no competent stakeholder anywhere is expecting a perfect estimate.
Incompetent stakeholders are real world phenomenon. In this sense, even stakeholders that are otherwise smart people and competent in other areas often fails in exact this way. Real world companies pay fines for being late. Real world customers without contractual guarantees end up paying more then project is worth too.
> Waterfall has gone from a punching bag to a real process people follow by adjustment.
This is the thing I disagree with strongly. Waterfall is punching bag and is not used in practice at all. It was past being used when I was young. Waterfall was also far from the only process that existed before agile came.
Iterative development process existed long before agile came to be. Agile means nothing and everything these days. Waterfall however is canvas where people project their grievances with other processes. That is why it is undefinable in these threads - it is either about communication, or people being treated bad, or about iteration or host of other practices that companies combine together.
Incompetent stakeholders are real world phenomenon. In this sense, even stakeholders that are otherwise smart people and competent in other areas often fails in exact this way. Real world companies pay fines for being late. Real world customers without contractual guarantees end up paying more then project is worth too.
> Waterfall has gone from a punching bag to a real process people follow by adjustment.
This is the thing I disagree with strongly. Waterfall is punching bag and is not used in practice at all. It was past being used when I was young. Waterfall was also far from the only process that existed before agile came.
Iterative development process existed long before agile came to be. Agile means nothing and everything these days. Waterfall however is canvas where people project their grievances with other processes. That is why it is undefinable in these threads - it is either about communication, or people being treated bad, or about iteration or host of other practices that companies combine together.
Totally agree with your last paragraph
"Agile is for smaller companies or smaller projects that can be broken up into sprint size pieces. Many are not."
Just not true. I know it's hard to know if you haven't seen it but I assure you it's possible and much for effective for a large team to be truly agile
Just not true. I know it's hard to know if you haven't seen it but I assure you it's possible and much for effective for a large team to be truly agile
Can you back that with some proof?
i call cap too. agileis the way to go, but requires focus, lots of communication and a concrete foundation of trust. that does in fact not scale well, in that angle.
[deleted]
It's also produced needless stress and bullies that manage scrum. Maybe that's what you want in a business to get stuff done on time.
With Agile, I find more ceremonies than actually work - Planning, estimations, Re-Planning, Cross Prioritization, Retro, Ticket Updates, Blockers, Blah, blah...
Our daily "15-minute" stand ups regularly tip over to 30+ minutes. This should be a sign that the team needs to be split up, as more than half of the stand-up is discussion of topics that are totally unrelated to my context.
It stops my momentum, annoys me, which ruins my motivation.
It stops my momentum, annoys me, which ruins my motivation.
I had a manager that gave me shit for not being verbose enough. And our stand-ups were already in that 20+ minute territory. Why do we have a Jira board if no one wants to read it? It's all right there! No blockers. Next.
I stopped going to stand-up and simply posted a Slack thread for status. The people who didn't like it are the people who would ramble on at stand-up, uncomfortable being curt or ending a meeting early. They'd ask "anyone have anything else to talk about?" just to fill up extra time. No preparation ahead of time, so a lot of "oh yeah and also..."
> more than half of the stand-up is discussion of topics that are totally unrelated to my context.
or the team is doing too much at a time, and delegating different "projects" to different people in the name of efficiency.
I think that's actually wrong - the whole team should work on the "same" task. For example, coding a module could be done together. It might seem like only 1 person is writing code, and everyone else is over the shoulder looking, but you save knowledge transfer times in the future, and you save code review time (you do review at the same time when everyone is there).
or the team is doing too much at a time, and delegating different "projects" to different people in the name of efficiency.
I think that's actually wrong - the whole team should work on the "same" task. For example, coding a module could be done together. It might seem like only 1 person is writing code, and everyone else is over the shoulder looking, but you save knowledge transfer times in the future, and you save code review time (you do review at the same time when everyone is there).
Don't forget that it wastes team's energy before, during and after. We would have 3~4 hour estimations & planning and it would just completely wipe everybody out. On top of that we had to track time to the minute and were thrown into debt because we owed "extra hours". On top of this our estimation would always be off due to people being burnt out and it would mean more hours were owed. This was a salaried position in Canada btw a long time ago and I don't know why there is so many of these small nanny startups that think they own people because they pay them a salary.
These used to wipe me out, but ever since I stopped paying attention to them this issue got solved. I use them for exercising, cooking, reading HN, etc while half listening to it like it would be radio.
And literally nothing was lost in the process. I am as productive as before, know as little about product we are developing as before.
And literally nothing was lost in the process. I am as productive as before, know as little about product we are developing as before.
Ye crowded useless meetings you don't pull are a breeze if you are WFH.
really? being on conference call for 3 hour straight, talking, thinking doesn't tire you out? the whole team takes breaks between and after too. even then I feel tired from such a lengthy session.
> being on conference call for 3 hour straight, talking, thinking doesn't tire you out
Being there straight, talking, thinking and listening would tire me out. But, I only half listen, dont focus on parts that dont seem relevant and get rest as I please.
These meetings were super tiring for me when I was trying to learn requirements from them. But the result was that I did not learned much anyway and not paying attention made no change.
Being there straight, talking, thinking and listening would tire me out. But, I only half listen, dont focus on parts that dont seem relevant and get rest as I please.
These meetings were super tiring for me when I was trying to learn requirements from them. But the result was that I did not learned much anyway and not paying attention made no change.
Described my current gig to a T except our useless project manager outright said he doesn't believe in agile and runs everything from excel. He came from a defense contractor and it shows. Everything has fallen apart, we've been late on every release, lost huge contracts and now we're outsourcing work to India, but, inexplicably, he still has two brand new cars and just bought a hobby farm. The bastard.
The only thing he did in response to failure was to pivot us to feature driven development, and then he screwed that up by not clearly defining teams and muddying responsibilities.
Pick your jobs carefully or be prepared to walk away :(
The only thing he did in response to failure was to pivot us to feature driven development, and then he screwed that up by not clearly defining teams and muddying responsibilities.
Pick your jobs carefully or be prepared to walk away :(
“feature driven development,”
Enjoy! All your problems are solved.
Enjoy! All your problems are solved.
You know what I'd do if I had a million dollars budget?
I'll tell you what I'd do, man, two teams doing Feature Driven Development at the same time, man.
I'll tell you what I'd do, man, two teams doing Feature Driven Development at the same time, man.
I don't know if I agree with every sentence in TFA, but this is obviously true:
> "Soon there will be a new project methodology that will promise to deliver software projects on time and on budget. It won’t work, but we will all have fun learning new terms and joining a new methodology cult."
I think everyone here will agree this will happen. Again, and again, and again.
> "Soon there will be a new project methodology that will promise to deliver software projects on time and on budget. It won’t work, but we will all have fun learning new terms and joining a new methodology cult."
I think everyone here will agree this will happen. Again, and again, and again.
For the next on we need something that uses the terms "back-propagation" (blah ... self-correcting planning ... blah) and "blockchain" (blah ... ensures to meet estimates ... blah).
I think it'll only work if the people paying for the product want an agile project.
And that they understand agile to mean the same thing as the engineers. That is to say to small deliverables within a short period. Review the small deliverable with client, make adjustments, then repeat until final product is done. Basically get things working a small piece at a time. Change directions if needed. Don't boil the ocean.
What usually happens is that the clients take "agile" to mean changes on-the-fly AND quick delivery of final product. They also usually prefer the waterfall deadlines, because then can line things up for Q2, Q3, etc.
I think a big reason for the disconnect is the word "agile".
And that they understand agile to mean the same thing as the engineers. That is to say to small deliverables within a short period. Review the small deliverable with client, make adjustments, then repeat until final product is done. Basically get things working a small piece at a time. Change directions if needed. Don't boil the ocean.
What usually happens is that the clients take "agile" to mean changes on-the-fly AND quick delivery of final product. They also usually prefer the waterfall deadlines, because then can line things up for Q2, Q3, etc.
I think a big reason for the disconnect is the word "agile".
Yeah, it’s like biz reads ‘agile’ and sees it as a buzzword for ‘everything we want’ instead of taking the word at face value.
The Agile manifesto is purely common sense: https://agilemanifesto.org/
Read it, it will take 20 seconds.
That makes sense. Now how does that turn into some monstruosity like scrum or anything else all the tech companies use, that I don't know.
"Agile" in the companies is all about process (have you done your standup, backlog refinement and retro?) and deadlines. The only thing we kept is not having documentation.
Great one btw, in the waterfall times we at least had an idea of what the hell was going on in a company.
Read it, it will take 20 seconds.
That makes sense. Now how does that turn into some monstruosity like scrum or anything else all the tech companies use, that I don't know.
"Agile" in the companies is all about process (have you done your standup, backlog refinement and retro?) and deadlines. The only thing we kept is not having documentation.
Great one btw, in the waterfall times we at least had an idea of what the hell was going on in a company.
Agile as understood by most companies is a self-deception framework. It's a way for companies to think they are more mature than they actually are.
The truth is that in most cases escaping the good - fast - cheap triangle is expensive because it involves a lot of research, and most companies either can't afford it or are led by greedy short-term thinkers.
Agile can only be solved with honesty. If you want some cheap crap, you can have it, but let's not get too pretentious about it.
The truth is that in most cases escaping the good - fast - cheap triangle is expensive because it involves a lot of research, and most companies either can't afford it or are led by greedy short-term thinkers.
Agile can only be solved with honesty. If you want some cheap crap, you can have it, but let's not get too pretentious about it.
They are if you allow it. I haven't had to put up with waterfall since 2007. Interview carefully, deliver good work to gain trust then read them the riot act if you have to. And if you can't change your Company, change your company.
I miss eXtreme Programming. If the team bought in and had some discipline, it rocked. Beck’s eXtreme Programming eXplained was my favorite book on the subject. Cunningham’s C2 was a gem of early ideas and thoughts exploring the space. And then it all slowly just eroded to crap. It reminds me of the morphology that took place with the first hundred years or so of Christianity.
I like the idea Extreme Programming. Well, anything at all that is different than the status-quo would be great.
Actually I never considered the theological connotations of working in an Agile project!
From my experience, there is usually a fundamental lack of trust and communication problems behind all of these project management approaches and initiatives. Ultimately it all stems from anxiety about the potential for a date to be slipped or something to not get delivered. It's not about peers, it's about tracking everything in a ticketing system so nothing is missed.
In practice, the only thing that ever really happens and I've never see anything deviate from this is as follows:
Sometimes things make it so the project is late, no level of agility or number of waterfalls can avoid the sometimes inevitable so it's better if product acts under the assumption things might not always be on time and have a more flexible marketing schedule etc.
None of this would be a problem, except now there's a lot of anxiety about not "doing agile", or waterfall or something...
In practice, the only thing that ever really happens and I've never see anything deviate from this is as follows:
1. Product team wants something feature or new product
2. A plan is formulated to get there, often by a certain date with engineers present.
3. An individual or team is entrusted with the delivery of said imitative
4. People go off to do the work to make it happen. Often for months, often without a ticket associated with the work, they just want to get their work done.
5. If you're lucky, the senior resources on the project will flag any issues as they arrive or foresee them.
6. A the end, if everyone isn't too burned out, it's nice to have some time of retrospective about how things went.
Sometimes things make it so the project is late, no level of agility or number of waterfalls can avoid the sometimes inevitable so it's better if product acts under the assumption things might not always be on time and have a more flexible marketing schedule etc.
None of this would be a problem, except now there's a lot of anxiety about not "doing agile", or waterfall or something...
This classic Yegge piece is almost 16 years old now and seems to describe more or less the same thing
https://steve-yegge.blogspot.com/2006/09/good-agile-bad-agil...
https://steve-yegge.blogspot.com/2006/09/good-agile-bad-agil...
One part of that post that hasn't aged well is the praise Google's launch culture got.
15yrs of hindsight later and it has probably become the biggest product pathology cliche identified with Google.
15yrs of hindsight later and it has probably become the biggest product pathology cliche identified with Google.
Phenomenal article, but I'm frustrated by his focus on Google, because it implies that you can only do 'Good Agile' when you have more money than God and no deadline. Although, perhaps that was his point.
In that timeframe a lot of his blog posts related to the experience of moving to Google - eg comparisons with Amazon etc.
It's now apparent that Google is both very a different place in recent years, AND that all the "Good Agile" stuff from 15 yrs ago kinda screwed most of their products and reputation long term.
It's now apparent that Google is both very a different place in recent years, AND that all the "Good Agile" stuff from 15 yrs ago kinda screwed most of their products and reputation long term.
A funny enough YouTube video (comedy) and really, it kind of reminds me of the agile methodology in the large company I worked at ... https://www.youtube.com/watch?v=bB340S0tGf8
Worse. At least with waterfalls, you are starting from the end goal. In my experience, most Scrum is the worst of both worlds - you are kept on a rigid/bureaucratic process but are not allowed to think about the end state.
I recently had a kerfuffle with a manager when I brought up the idea of a novel solution to a time consuming problem and proposed doing a quick proof-of-concept. I was told not to work on anything until we have requirements.
"How will stakeholders know to submit requirements for something they don't know is possible?"
"Well, we can't to any work unless it is submitted for approval in an Agile way".
I recently had a kerfuffle with a manager when I brought up the idea of a novel solution to a time consuming problem and proposed doing a quick proof-of-concept. I was told not to work on anything until we have requirements.
"How will stakeholders know to submit requirements for something they don't know is possible?"
"Well, we can't to any work unless it is submitted for approval in an Agile way".
I call it 'Wagile'. Everyone uses all the agile buzzwords yet all the project management is focussed on estimates and hard deadlines.
To me the most disturbing part is people read the 'Agile Manifesto' and say, "yep, that's what we do", yet for every item it is the exact opposite. For example, "people over process" seems to be addressed by considering every team member identical and focussing purely on the tickets.
I am to the point now where I think corporate 'Wagile' is the Agile process and I simply don't understand what it was years ago.
To me the most disturbing part is people read the 'Agile Manifesto' and say, "yep, that's what we do", yet for every item it is the exact opposite. For example, "people over process" seems to be addressed by considering every team member identical and focussing purely on the tickets.
I am to the point now where I think corporate 'Wagile' is the Agile process and I simply don't understand what it was years ago.
What you describe has nothing to do with waterfall and is simply agile. Literally nothing in what is supposed to be waterfall prevents specialization or treating people nicely. However, multiple agile methodologies explicitly prevent specialization and explicitly are tickers focused.
They do it for a reason, to be fair. But, it is ridiculous that for how long agile existed, every single uncomfortable or dysfunctional thing about any agile process gets blamed on waterfall.
No. These are all issues with agile methodologies. Agile manifesto is just feel good document meant to make you buy into the process in abstract. It is inspirational, but that is all there is to it.
They do it for a reason, to be fair. But, it is ridiculous that for how long agile existed, every single uncomfortable or dysfunctional thing about any agile process gets blamed on waterfall.
No. These are all issues with agile methodologies. Agile manifesto is just feel good document meant to make you buy into the process in abstract. It is inspirational, but that is all there is to it.
So, it seems to me, you are saying that we should not be taking any notice of anything clearly stated in the Agile Manifesto. Next time someone says to me "Don't bother telling me about the real work, just keep the ticket time spent updated", I'll keep that in mind. (A real quote from an Professional Agile Practitioner to me).
I had a large project for a new client a while ago; they had 50 devs and I was managing work of 20. They kept saying I did not understand what agile is; this way they have no control! They said. So they started more and more micromanaging this already waterfall project which they didn’t understand; daily ‘standups’ that took a lot of time and which were used to embarrass individuals who missed their estimates they put yesterday, pull tasks apart into minute subtasks and estimate them and hand out fines for people who missed their targets. Needless to say everyone was really stressed, they hated these ‘managers’ who were supposed to be on equal footing with me but were not. No one was project managing anything; the dude meant to be the PM went in such detail about useless product things that he didn’t have time to manage anything. All along this was hailed as a perfect agile project. Of course the project was fixed price, fixed deadline and fixed feature set (but no one told me that; I was hired as a freelance tech lead to make sure things were implemented properly as I worked in that field for ages).
Needless to say things didn’t go as planned and I was let go for not being a team player. The project is still not live years later and all people we worked with were fired and replaced several times as well except the ‘managers’.
Needless to say things didn’t go as planned and I was let go for not being a team player. The project is still not live years later and all people we worked with were fired and replaced several times as well except the ‘managers’.
Important fact about the waterfall model, that no-one ever talks about:
The authors thought it was important to actually do it twice [0]. Of course, nobody in the big corporate/government world wanted to pay a second time for work that has already be done, so most of the projects failed and continue to fail.
[0] https://en.wikipedia.org/wiki/Waterfall_model#Royce's_final_...
The authors thought it was important to actually do it twice [0]. Of course, nobody in the big corporate/government world wanted to pay a second time for work that has already be done, so most of the projects failed and continue to fail.
[0] https://en.wikipedia.org/wiki/Waterfall_model#Royce's_final_...
I've found that there's no single method that works well over time. Agile gives you crappy code and a stressed team and water fall gives you late projects. I generalize.
People want to blame the method of project management but it comes down to the team and the project manager. There's a reason why project managers get paid so well in every field. They know how to manage a team while bringing in the project on time. It's a hard job. What method is used is not as important.
People want to blame the method of project management but it comes down to the team and the project manager. There's a reason why project managers get paid so well in every field. They know how to manage a team while bringing in the project on time. It's a hard job. What method is used is not as important.
What's interesting to me about these posts is that usually employees are complaining about their current job, or a very few experiences compared to the thousands of software shops implementing this framework with various degrees of fidelity.
While your experience may suck, mine at my company has been pleasant and planning/estimates greatly help us organize and predict our work. We get the benefits of breaking down complex tasks, while throwing out anything unnecessary to us and coming to terms with the fact that estimates != time. Anything the business asks of engineering is a problem to be solved be engineering leaders without decimating the productivity of your teams.
I've gone from IC to engineering leadership and while I get the arguments, most of the blame falls on poor engineering culture and management implementing things without thought. You don't have to do everything the framework tells you. Use it in spirit in a way that's appropriate to your current team and company.
While your experience may suck, mine at my company has been pleasant and planning/estimates greatly help us organize and predict our work. We get the benefits of breaking down complex tasks, while throwing out anything unnecessary to us and coming to terms with the fact that estimates != time. Anything the business asks of engineering is a problem to be solved be engineering leaders without decimating the productivity of your teams.
I've gone from IC to engineering leadership and while I get the arguments, most of the blame falls on poor engineering culture and management implementing things without thought. You don't have to do everything the framework tells you. Use it in spirit in a way that's appropriate to your current team and company.
Quite simply this comes down to business users not wanting to know how the sausage is made after all. They want their food cooked fast, but don't really care how.
We manage 2 different conversations at all times (agile and waterfall):
Internally, the Chefs in the kitchen agree on Mise en Place practices, prep time, and have strong confidence then can run 100% regression tests and deploy at anytime. The overhead of TDD, technical debt (sharpening the knives), and retrospectives are kept internal.
Externally, the customers don't care about the ingredients or process. We encourage business users to take the waterfall view, think through their requirements, discuss menu options, set delivery dates and formal acceptance testing criteria.
It's not that development teams aren't doing agile. But the Agile Manifesto's ideal that Developers and Product Owners would all sit down and speak the same language turned out to be less than practical.
We manage 2 different conversations at all times (agile and waterfall):
Internally, the Chefs in the kitchen agree on Mise en Place practices, prep time, and have strong confidence then can run 100% regression tests and deploy at anytime. The overhead of TDD, technical debt (sharpening the knives), and retrospectives are kept internal.
Externally, the customers don't care about the ingredients or process. We encourage business users to take the waterfall view, think through their requirements, discuss menu options, set delivery dates and formal acceptance testing criteria.
It's not that development teams aren't doing agile. But the Agile Manifesto's ideal that Developers and Product Owners would all sit down and speak the same language turned out to be less than practical.
Keep in mind the Agile Manifesto was not a list of absolutes.
It was a list of values that accept waterfall practices, but with a preference to do things slightly differently.
https://agilemanifesto.org/
"That is, while there is value in the items on the right, we value the items on the left more."
It was a list of values that accept waterfall practices, but with a preference to do things slightly differently.
https://agilemanifesto.org/
"That is, while there is value in the items on the right, we value the items on the left more."
Yes, we know this. We've known this for a long time actually. Nobody has yet proposed a better method.
- The agile manifesto is a smattering of nice-sounding principles with no suggestion of how to achieve/implement them.
- Scrum is an over-prescribed, subtly-complex theoretical workflow from the 1980s that was carried forward in the absence of any alternative other than Waterfall, in the same wake that created TDD, XP, and other now-ancient methods that we pay lip service to.
- DevOps came and went like a fart in the night. Was supposed to result in better outcomes for developing and running software projects. It's now literally a cargo cult. People who have no idea what it is, saying that they "do" it.
If you have a suggestion for a better way to work, by all means, someone please blog about it, I will read it. But please no more blog posts about how Agile or Scrum don't work. We have a decade of those posts already.
- The agile manifesto is a smattering of nice-sounding principles with no suggestion of how to achieve/implement them.
- Scrum is an over-prescribed, subtly-complex theoretical workflow from the 1980s that was carried forward in the absence of any alternative other than Waterfall, in the same wake that created TDD, XP, and other now-ancient methods that we pay lip service to.
- DevOps came and went like a fart in the night. Was supposed to result in better outcomes for developing and running software projects. It's now literally a cargo cult. People who have no idea what it is, saying that they "do" it.
If you have a suggestion for a better way to work, by all means, someone please blog about it, I will read it. But please no more blog posts about how Agile or Scrum don't work. We have a decade of those posts already.
I will say that my favorite new methodology can be found here: http://programming-motherfucker.com/
I find that very shortsighted. Unless you're working on your own pet project, programming is like 20% of the job. The other 80% are designing, communicating, and collaborating.
You will not ship complex business software by just "Programming, motherfucker". You will build the wrong thing if you talk to the customer for one hour and then go off on a mad programming frenzy for the next 6 months. You need constant iteration and feedback (agile), or completely up front agreed-upon specs (waterfall), to not build the wrong thing. Both of these are absolutely not programming.
Next to that:
> "We are tired of being told we're socialy awkward idiots who need to be manipulated to work in a Forced Pair Programming chain gang without any time to be creative because none of the 10 managers on the project can do... Programming, Motherfucker."
This seems very stereotyping. Does anyone actually experience this? In this job market? The companies I've worked at are generally very happy to have a software engineering professional in the team, and are trusting of my word/estimations.
If someone would call me a "socially awkward idiot" at work, I'd have no problem finding another workplace that does respect me.
You will not ship complex business software by just "Programming, motherfucker". You will build the wrong thing if you talk to the customer for one hour and then go off on a mad programming frenzy for the next 6 months. You need constant iteration and feedback (agile), or completely up front agreed-upon specs (waterfall), to not build the wrong thing. Both of these are absolutely not programming.
Next to that:
> "We are tired of being told we're socialy awkward idiots who need to be manipulated to work in a Forced Pair Programming chain gang without any time to be creative because none of the 10 managers on the project can do... Programming, Motherfucker."
This seems very stereotyping. Does anyone actually experience this? In this job market? The companies I've worked at are generally very happy to have a software engineering professional in the team, and are trusting of my word/estimations.
If someone would call me a "socially awkward idiot" at work, I'd have no problem finding another workplace that does respect me.
I think you're missing that the website is satire. So the hyperbolic reductions it presents serve a comedic purpose. The site is supposed to make you laugh, not 100% accurately depict reality. What makes it good comedy is that triggers a cognitive dissonance by distilling frustrations with different software methodologies into ever-so-slightly absurd statements that almost represent reality, but not quite.
> This seems very stereotyping. Does anyone actually experience this? In this job market?
While not directly spoken to engineers' faces, there are absolutely people who think this way. And I know former coworkers who have worked in pair programming shops, so that part is actually factual. Innocence is bliss, though (;
> This seems very stereotyping. Does anyone actually experience this? In this job market?
While not directly spoken to engineers' faces, there are absolutely people who think this way. And I know former coworkers who have worked in pair programming shops, so that part is actually factual. Innocence is bliss, though (;
That's interesting actually, because it seems written by a contractor. Each role in each industry probably has its own warped methodology, which means a "better" methodology will need to be tailored to the role & industry. So we might need 40 methodologies, not one.
The biggest problem the anti-Agile crowd has is that:
1. They have no replacement methodology.
2. Even if they did, it has no name.
I get that lots of people dislike Agile and what it has come to mean in certain quarters. But I have yet to see a cogent, actionable response. Criticism is well and good, but changing a bad situation requires a better idea.
But "leave me, the beleaguered, over-meetinged, over-instrumented developer, the hell alone" is not a methodology, and it's not something any sane business is going to sign up for.
Many of the comments here against Agile really attack process itself. Not particular processes, but the notion that there is a process that is followed, the same way every time. And extra scorn is heaped on process attached to metrics.
1. They have no replacement methodology.
2. Even if they did, it has no name.
I get that lots of people dislike Agile and what it has come to mean in certain quarters. But I have yet to see a cogent, actionable response. Criticism is well and good, but changing a bad situation requires a better idea.
But "leave me, the beleaguered, over-meetinged, over-instrumented developer, the hell alone" is not a methodology, and it's not something any sane business is going to sign up for.
Many of the comments here against Agile really attack process itself. Not particular processes, but the notion that there is a process that is followed, the same way every time. And extra scorn is heaped on process attached to metrics.
> They have no replacement methodology.
Yes, we do.
> it has no name.
Yes, it does - it's called the "Agile Manifesto". When MBA's do something called "Agile", they're actually doing Waterfall, but worse.
Imagine if you hired a cleaning crew to clean a warehouse but, instead of sweeping up the floor, they started opening bags of garbage and dumping them on the floor. Now imagine that you pointed out to them that what they're doing is the exact opposite of "cleaning". Now finally imagine that they say, "oh, you warehouse owners always say we're not doing 'cleaning' right".
Yes, we do.
> it has no name.
Yes, it does - it's called the "Agile Manifesto". When MBA's do something called "Agile", they're actually doing Waterfall, but worse.
Imagine if you hired a cleaning crew to clean a warehouse but, instead of sweeping up the floor, they started opening bags of garbage and dumping them on the floor. Now imagine that you pointed out to them that what they're doing is the exact opposite of "cleaning". Now finally imagine that they say, "oh, you warehouse owners always say we're not doing 'cleaning' right".
> the anti-Agile crowd ... replacement methodology ... has no name ... lots of people dislike Agile
AIUI, there is no capital-A "Agile". It's a pilosophy, a mindset, a set of methodologies, not a brand or a product.
I actually think that could be a heuristic: Talks about capital-A "Agile" == doesn't get what "agile" is about.
AIUI, there is no capital-A "Agile". It's a pilosophy, a mindset, a set of methodologies, not a brand or a product.
I actually think that could be a heuristic: Talks about capital-A "Agile" == doesn't get what "agile" is about.
Re: no replacement methodology
The way I remember the RUPs and FDDs of the world they actually addressed technical questions developers cared about. Starting from XP they have all been about managerial concerns. I'm not aware of a consistent explanation for that transition.
The way I remember the RUPs and FDDs of the world they actually addressed technical questions developers cared about. Starting from XP they have all been about managerial concerns. I'm not aware of a consistent explanation for that transition.
Agile replaced waterfall, so one of the replacements for agile would be waterfall.
I think what makes or breaks a team is not so much "is it agile or is it waterfall", but more cultural and difficult to quantify. My fairly small team of ~20 tried all kinds of kanban, sprint, standup, scrum or whatever and have converged on something amusingly waterfall-like where we design stuff upfront then just bang it out. We have open communication, so if we hit unexpected snags, you can just talk to product or bizdev or dev and sort it out. If product is getting anxious about progress, they just ask and the devs give an estimate (or even a demo). I guess business is kinda like a marriage where just talking about things openly solves quite a lot of problems.
Agile is pretty silly. Waterfall is ridiculous. Instead, start with a good vision of what needs to be built (if you don't have that, maybe don't even start). Then focus on the product, not the process.
I think what you just described is what the agile manifesto described. Valuing working code over tools and processes to paraphrase. Scrum and kanban are not agile. Because agile is not a process. Process is for people who can't accept accountability.
The worst part about agile is it has become whatever each company wants it to be. Product owners dominate the pace and direction of development often to the detriment of engineering quality. At least in waterfall model, there is some one like a program manager or delivery manager taking overall responsibility for delivery and coordinating dates with stakeholders. With agile and scrum, there is no one taking responsibility for achieving things. Often product owners end up doing this for which they might or might not qualify for.
> The worst part about agile is it has become whatever each company wants it to be.
Actually, the point of agile is that it should become whatever the team needs it to be.
Also, scrum is an agile methodology, not a separate thing.
Actually, the point of agile is that it should become whatever the team needs it to be.
Also, scrum is an agile methodology, not a separate thing.
Until you get get it through the skulls of people with the money to pay that "we have it all drawn up, you just have to build it" is a horrendously bad idea, this will continue forever.
Scrum and Kanban ways of working, work for different kinds of people/roles/goals.
Neither are silvet bullet solutions to a problem.
But scrum has a well-defined method, that works for everyone. It is managed top-down to deliver items for individuals to do.
Whereas kanban needs the individual to take on whatever the work throws at them, including total failure of the deliverable by issues outside of their control. In this situation, the individual has to be empowered and trust should have been settled between managers and members of the team.
Neither are silvet bullet solutions to a problem.
But scrum has a well-defined method, that works for everyone. It is managed top-down to deliver items for individuals to do.
Whereas kanban needs the individual to take on whatever the work throws at them, including total failure of the deliverable by issues outside of their control. In this situation, the individual has to be empowered and trust should have been settled between managers and members of the team.
I found Scrum’s iterative approach very beneficial. In every other project without it or some other bastardisation of “scrum” there was always a major fuck around with wrong priorities, and constant reacting to every manager. Theres no point taking on Scrum if you only think it means story points and standups. In any case, I ask what frameworks (that i can read about) have worked for all of you?
I have never experienced a truly Agile or a truly Waterfall project. It has always been a mixed bag of approaches and ideas depending on the project, the client and team.
There is a reason there are managers and planners in every company. Projects are messy in all different ways.
Be flexible and keep an open mind. Try different things and figure out what works best for you.
There is a reason there are managers and planners in every company. Projects are messy in all different ways.
Be flexible and keep an open mind. Try different things and figure out what works best for you.
Waterfall projects with sprints. Releasing every 2 weeks is still way better than releasing less frequently. Yes its not ‘true agility’, but as long as you find your weakness and learn from them every 2 weeks you’re going to be in a stronger position than if you have to wait 6 months to realise you stuffed up 5 months ago
Witnessed agile/DevOps degenerate into resource constraint paralysis far too often. In general, such approaches are not appropriate for every project... even if you are not the one paying for the billable hours.
The Module pattern design built into many languages like Python is perhaps why some folks get away with it for awhile. ;)
The Module pattern design built into many languages like Python is perhaps why some folks get away with it for awhile. ;)
Waterfall - the mythical process that if ever existed it was 30 years ago, but we bring it up when we want to make our 30 years old process sound hip. And when we don't want to say agile both often massive sux and also is the normal way of doing things for decades.
Anybody ever heard "we don't plan that would be waterfall, we are an agile shop". It was at that point I knew it was over at my last gig.
I guess it depends where you work because this doesn't how things have been done throughout my career.
[deleted]
As the meme says: Alway was
They always were.
We've taken some inspiration from Shape Up by the Basecamp folk. We don't use Basecamp or follow it strictly, but since we had already been practicing some of the things the book advocates for, we decided to take a closer look and adopt some of their terminology.
Some highlights:
* 6 week cycle + 2 week cooldown
* no ticket backlog
* handoff between product and eng, scope hammering
* fixed deadlines
* integrate first then refine
To me it feels like a modern blend that takes a few good things from the Agile philosophy but concedes that not everything happens in 2-week sprints in reality and that effective product people have to actually design product and buy work instead of just dump user stories into the issue tracker and tell engineers to build them all.
With our team of 4, we essentially choose from a set of "pitches" 3-6 "bets" for a 6 week cycle. We then work on answering all the unknowns (e.g. "does this platform API support some requirement in the way we think it might?", or "is there a de facto library for this or do we need to build it?") and prototyping solutions for the projects. Those prototypes we share with each other once they're working (and of course collaborate along the way as needed). From the prototype, now that you actually have an engineering handle on the task, you basically resolve how much time is left in the "appetite" (allotted time for the project) against the remaining scope of work. Then you do an amazing rare thing: the engineering team cuts, or "hammers", scope until they can deliver something on time. This is very different from the norm in my experience where product tries to micro manage the outcomes of the project the whole way.
Obviously things are not totally rigid and sometimes a little more appetite appears to allow something to not be hammered out of the final thing or some preferences are expressed for which project to hammer harder when competing for remaining time, but it generally works pretty well.
At the end, product gets to taste what got cooked up by the chefs and then, during cooldown, decide (with eng leaders) what to pitch and ultimately bet on for the next cycle while the eng team addresses smaller tasks, monitors deployments, polishes, and fixes bugs.
The key, "shape up" terminology and logistics aside, is forcing product to make up front "purchase commitments" (my term) of things they need/want in the product. This forces a lot of things that don't happen normally or happen ad hoc during a sprint to happen up front (in theory, alas no process is perfect).
Somewhat secondary but also very important and close to my heart is that this methodology avoids the utterly useless and inaccurate time waste of trying to achieve task-level estimates prior to work, usually building something that nobody has every build before, has starting. It inverts the commitment so that engineers are building what the time allows rather than product asking how long something is going to take and then rightfully getting angry/frustrated when things 4x as long as the engineers said they would. It feels way more human as an engineer to be given some freedom to explore the solution space and then use your and your teams expertise to deliver a solution in the allotted time.
Some highlights:
* 6 week cycle + 2 week cooldown
* no ticket backlog
* handoff between product and eng, scope hammering
* fixed deadlines
* integrate first then refine
To me it feels like a modern blend that takes a few good things from the Agile philosophy but concedes that not everything happens in 2-week sprints in reality and that effective product people have to actually design product and buy work instead of just dump user stories into the issue tracker and tell engineers to build them all.
With our team of 4, we essentially choose from a set of "pitches" 3-6 "bets" for a 6 week cycle. We then work on answering all the unknowns (e.g. "does this platform API support some requirement in the way we think it might?", or "is there a de facto library for this or do we need to build it?") and prototyping solutions for the projects. Those prototypes we share with each other once they're working (and of course collaborate along the way as needed). From the prototype, now that you actually have an engineering handle on the task, you basically resolve how much time is left in the "appetite" (allotted time for the project) against the remaining scope of work. Then you do an amazing rare thing: the engineering team cuts, or "hammers", scope until they can deliver something on time. This is very different from the norm in my experience where product tries to micro manage the outcomes of the project the whole way.
Obviously things are not totally rigid and sometimes a little more appetite appears to allow something to not be hammered out of the final thing or some preferences are expressed for which project to hammer harder when competing for remaining time, but it generally works pretty well.
At the end, product gets to taste what got cooked up by the chefs and then, during cooldown, decide (with eng leaders) what to pitch and ultimately bet on for the next cycle while the eng team addresses smaller tasks, monitors deployments, polishes, and fixes bugs.
The key, "shape up" terminology and logistics aside, is forcing product to make up front "purchase commitments" (my term) of things they need/want in the product. This forces a lot of things that don't happen normally or happen ad hoc during a sprint to happen up front (in theory, alas no process is perfect).
Somewhat secondary but also very important and close to my heart is that this methodology avoids the utterly useless and inaccurate time waste of trying to achieve task-level estimates prior to work, usually building something that nobody has every build before, has starting. It inverts the commitment so that engineers are building what the time allows rather than product asking how long something is going to take and then rightfully getting angry/frustrated when things 4x as long as the engineers said they would. It feels way more human as an engineer to be given some freedom to explore the solution space and then use your and your teams expertise to deliver a solution in the allotted time.
I recently wrote about my experiences here, and especially, what makes a great project manager who can move a project in a flexible way. I quote myself:
--------------------
What about Scrum, Agile, Kanban, PMP and CAPM?
At this point many of you will be wondering, where is the conversation about all of the formal methodologies? Some of you will think it’s strange that I’ve written a whole chapter about project management without mentioning Scrum, Agile, Kanban, PMP and CAPM.
...I have not personally noticed that credentials (such as Scrum Master or PMP) are necessarily associated with real skill as a project manager. Rather, the key things that make a great project manager tend to be more qualitative:
--------------------
What about Scrum, Agile, Kanban, PMP and CAPM?
At this point many of you will be wondering, where is the conversation about all of the formal methodologies? Some of you will think it’s strange that I’ve written a whole chapter about project management without mentioning Scrum, Agile, Kanban, PMP and CAPM.
...I have not personally noticed that credentials (such as Scrum Master or PMP) are necessarily associated with real skill as a project manager. Rather, the key things that make a great project manager tend to be more qualitative:
• Does this person have the moral convictions necessary to take a tough stand against upper management, for the benefit of the overall company?
• Does this person have the confidence necessary to fire a poor performer for the benefit of the overall team?
• Does this person have the perceptiveness to correctly read team members and know when they are lying or boasting?
[deleted]
The problem is that programmers answer to idiots, but nevertheless those idiots have certain reptilian sensibilities in which they exceed us, and a consequence of this is that they have a knack for zero-sum power grabs and pissing contests. So, even though those people are 30-50 IQ points below us, they nevertheless end up remaining on top, and there isn't really much we can do about it unless we're prepared to burn down a whole socioeconomic system (which I am, but most people aren't there yet).
"Sprints" are supposed to be humiliating. The very message is that you're not trusted with even two fucking weeks of your own (!!) working time. It could not be clearer. If you work in sprints, it's because the higher-ups think you're a child and a loser, and you'll never be able to overcome that negative inference, because if you perform poorly you will confirm it and if you perform well, you will confirm that their micromanagement actually works--there is no winning.
Also, "Waterfall" never really existed. It was a straw man invented to sell this Agile bukkake.
In any case, a number of the dysfunctions are, in effect, intentional. Standups that go on for 45+ minutes? Long meetings are a classic way for managers to punish perceived underperformers (or, in Agile terms, "impediments") when they're not entirely sure who problem player is. The theory is that the rest of "the team" (I put this term in quotes because coworkers in corporate aren't an actual team--that's just management speak--but are often pitted against each other) will get sick of the incessant meetings and rat out the underperformer who is causing this wastage of time. The humiliations of Jira and "user stories" aren't bureaucratic accidents that occurred in good faith; they hurt because they're supposed to hurt.
"Sprints" are supposed to be humiliating. The very message is that you're not trusted with even two fucking weeks of your own (!!) working time. It could not be clearer. If you work in sprints, it's because the higher-ups think you're a child and a loser, and you'll never be able to overcome that negative inference, because if you perform poorly you will confirm it and if you perform well, you will confirm that their micromanagement actually works--there is no winning.
Also, "Waterfall" never really existed. It was a straw man invented to sell this Agile bukkake.
In any case, a number of the dysfunctions are, in effect, intentional. Standups that go on for 45+ minutes? Long meetings are a classic way for managers to punish perceived underperformers (or, in Agile terms, "impediments") when they're not entirely sure who problem player is. The theory is that the rest of "the team" (I put this term in quotes because coworkers in corporate aren't an actual team--that's just management speak--but are often pitted against each other) will get sick of the incessant meetings and rat out the underperformer who is causing this wastage of time. The humiliations of Jira and "user stories" aren't bureaucratic accidents that occurred in good faith; they hurt because they're supposed to hurt.
> Also, "Waterfall" never really existed.
That part is true.
> It was a straw man invented to sell this Agile bukkake.
That part is colorful, but retconning. A fellow named Royce coined the term in 1970 and used it as a strawman for common project iteration organization (V-model?) a the time.
I agree with most of the spirit of the rest of the parent's screed, though not with all the details.
That part is true.
> It was a straw man invented to sell this Agile bukkake.
That part is colorful, but retconning. A fellow named Royce coined the term in 1970 and used it as a strawman for common project iteration organization (V-model?) a the time.
I agree with most of the spirit of the rest of the parent's screed, though not with all the details.
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?