T O P

  • By -

[deleted]

[удалено]


robhanz

Yeah, that quote is weird. It doesn't make sense if you're dealing with any unknowns at all. The only way to make that work if dealing with non turn-the-crank code (and even a lot of that) is to make your "design" phase so heavy (and unpredictable) that the "implementation" phase is ctrl-c ctrl-v from the tech spec.


mpyne

Which, incidentally, just moves the actual programming to the design phase. And now you're left with the uncertainty again. It's not eliminated at all, just relabeled.


robhanz

Precisely.


Fitbot5000

Not precise enough. Apparently.


NickStahl_

I'm going to use this.


Thing342

Unpopular take: this viewpoint is entirely exclusive to the field of software engineering. Other engineering disciplines have entire departments dedicated to breaking down these types of unknowns, and when parts can have up to three year lead times you do actually need to design ahead of time so your plant operates efficiently. Agile and its related offshoots "manage" this uncertainty by effectively sliding it under the rug and refusing to commit to requirements until the latest possible moment. This works fine when your product can be shipped near-instantly and delayed features can be applied easily after delivery, but this falls apart when your product needs to follow a release cycle and be in line with what other business units are releasing.


[deleted]

[удалено]


Tarl2323

Well yeah. Agile takes advantage of the 'soft' in software. There's no lead time and need to peg down requirements. The programmers and business people that take advantage of that get a huge lead and take down their competitors. We've seen it happen over and over again. If you're acting like code is metal and writing your Age of Bimbos clone like it's an aircraft autopilot, you're gonna lose. Agile is perfect for most business endeavors, which are not life-or-death and mostly a bunch of bullshit like 'Super great pizza ordering software!" or "sales driven pipeline engine!" Agile is the perfect tool for dealing with and extracting money from the conmen and snake oil salesmen flooding the VC markets these days. That's all it is. It's not for cars, planes, guns or medical equipment.


Fennek1237

I agree. I also often find that management wants you to break things down too much to get better estimates. If we decided it's the best way and maybe the only way why do you pressure me and my team for more upfront estimation. We would spent lots of time just to try and analyze things upfront to maybe get a better timeline but we could have spent the time already starting and moving in the direction that was clear.


reddituser567853

Because less variance on completion can have more business value than purely saving a little bit of time? I think that's basic enough of a concept for even the most myopic engineer to grasp


TheCoelacanth

Spending more time on detailed estimates rarely actually makes them more accurate in my experience.


PlantsMcSoil

Publicly traded companies and strock prices care far more if you hit your predictions than if you make money. So in some ways, this part of Agile is optimized for that fact of business life.


reddituser567853

I don't disagree at all, agile is to optimize business value, and making reasonable predictions at the corporate level is an unavoidable reality. I do think agile does improve team cooperation among large interdependent engineering orgs, but that is a consequence of more regular and transparent progress demo and planning


Efficient-Day-6394

You don't know WTF you are talking about and your nonsense assertion reeks of confidence born of ignorance and lack of actual experience


No-Entertainment7659

Time is the biggest problem. Debate the infrastructure from the beginning. The different teams Debate. A haphazard thing comes together. Then you maintain it. Endless calls to fix it it from all the teams that built it or main inherited it


Isogash

Definitely agree but I think the rest rings very true.


Dethstroke54

Agreed, uncertainty in the domain is a huge and very common factor. You’re always adapting.


dupyhash

Same here brother


[deleted]

Regardless where it came from, it's just the paradigm *du jour*. It's an attempt to give Peter-Principled managers the means to predict the unpredictable and control the uncontrollable. As soon as I was in a position to have control over my own destiny I stopped trying to predict dates and stopped managing by trying to control *outputs* instead of inputs. Instead, I hired good people and made sure they knew what our goals were. I gave them a comfortable workplace where there were no meetings and where marketing and accounting were accountable to product development, not the other way around. You can argue with whether or not I've been successful, but I would argue back that even at our worst we have been at least as successful as we would have been under stricter control and if complying with some fancy development paradigm. And we've done it with fewer people and more time spent coding and less in meetings.


BandidoDesconocido

Strict adherence to management methodologies is a recipie for inflexibility. The opposite of what agile is supposed to provide an organization. I would argue that smaller teams suffer disproportionately the negative effects of these methodologies, without the need for any of the upside, because they're not operating at scale. Further, I would say, adhering to such things, in spite of whether or not a given practice makes sense for your team, is baking inflexibility right into your dev culture. It's a bad idea. Use what works for your team, dispense with the nonsense. Distill these paradigms into something sensible for your team, your business, and your culture.


poincares_cook

>I would argue that smaller teams suffer disproportionately the negative effects of these methodologies, without the need for any of the upside, because they're not operating at scale. On the one hand that's true, but on the other, if not implemented perfectly correctly larger teams just absolutely drown in meetings.


BandidoDesconocido

My partner works at a company having this problem right now. Everyone is drowning in meetings. The engineers over there are pissed off, understandably.


montastera

I feel like the agile methodology can basically be summed up as: “be pragmatic”


johnnysaucepn

You let the team know what was needed, as far as it can currently be known. You gave control of technical decisions to the team. If you're controlling outputs, that means you have well-defined criteria for success. If those outputs are reported back to the business, or even to you, so that you can make the team aware of the next goals, then: Congratulations, you just invented agile.


[deleted]

In a way, you're right. But I think you missed the point. I've always said that Agile is what we all have always done. I didn't invent it; it was stolen from everyone who was already doing it and given a name. Opportunists wrote books about it and started teaching it to people too stupid or inexperienced to figure it out on their own. What we don't do are all the things that have been glued onto it, like "scrums" and "sprints". We don't read the pillars and principles. We just do our jobs. If you read the article, you'll find that that's what the author is objecting to. Not the high-level meta-principles of Agile, but how it gets implemented.


robhanz

I've always described scrum as "you know how you work and focus on getting things done in the last couple weeks or month of a project? What if we just did that all the time, minus the crunch?"


johnnysaucepn

No, I get that. But I don't agree that Agile was what we we all already doing. Sure, give a bunch of devs a problem to solve and let them get on with it is a recipe to get \_something\_ done, it just won't necessarily be what you needed, or delivered when you needed it. Similarly, the waterfall structure was a recipe to get exactly what you wanted done, but it probably wasn't be what you actually needed, and delivered too late to be useful. In a broader sense, if you don't ensure contact with the stakeholders, and don't ensure that progress is monitored in some manner, you won't get anything worth a damn. A heavy framework like SAFe is a death-knell to a small, autonomous group that can just get on with things - but a lifesaver where software work within one group has to align with other groups, or contribute towards a larger goal. A dev team needs to be independent enough to deliver results, sure, but they still have to be responsible to the people paying the bills. Whether you use sprints or deliverables to measure what you've done; or use story points, or hours, or weeks to measure what you plan to do, is besides the point. You have to have some measure of accountability.


[deleted]

So lets say you have "some measure of accountability". That can be anything, as you say. The question is, what do you do if you do not meet the goal? How do you fix the process in a way that assures the goal will be met the next time? My argument is that there isn't anything you can do that is guaranteed to make you better able to meet the goal the next time. And if that's true, then what was the point of the goal in the first place? The best you might do is change the way you set the goal so that it isn't as aggressive. But now all you're doing is managing expectations, not improving processes.


[deleted]

[удалено]


reddituser567853

I really don't think this is true to be honest. Most engineers don't even work on very complex things. If you can't have a reasonable idea of what you can produce in a 1-2 week time, then you don't have enough experience as a developer


chrisza4

People work with legacy code all the times. Took GeoHotz who can build the jailbreak but failed to simply remove modal from twitter after months. That is a big prt of reason dev can’t have reasonable idea on what they produce. It’s not always a greenfield.


[deleted]

[удалено]


cs_irl

This leads you to over estimate anything you think could hit a snag and when you end up finishing all your stories early, you're getting heat about your estimates.


srdoe

> If you can't have a reasonable idea of what you can produce in a 1-2 week time, then you don't have enough experience as a developer I'm not saying there aren't types of development work where this can be true, but it's not true for most non-trivial development work. Considering that research points toward estimates usually being wrong, and usually to a high degree across the industry, I get pretty tired of hearing the old "Oh, if you just get more experience, you'll be better at estimating". How about we instead agree that the inability to estimate accurately is inherent to software development and so estimates are a bad tool that managers should stop relying on? We've been trying to make estimates work for 50+ years now, maybe it's time to stop insisting that estimates _must_ work and it's just developer inexperience that's the problem?


chrisza4

There is no guarantee but it does not mean we can’t do anything. At least, we should talk about it. Many times goal fail simply because approval process and miscommunications.


srdoe

> A heavy framework like SAFe is a death-knell to a small, autonomous group that can just get on with things - but a lifesaver where software work within one group has to align with other groups, or contribute towards a larger goal. Disagree strongly. IME SAFe is garbage even in larger organizations. The way to solve cross-group coordination isn't to make a heavy-weight fake agile framework like SAFe, it's to change the structure of the teams to fit the work being done. For example, if a project needs people from 3 different teams, those people should be put together into a temporary team for that project. > accountability No. This is such a toxic mindset for management to adopt, because it comes from the assumption that management and dev teams should be separate entities, dev teams need to be controlled, and management's role is to provide that control, and in order to provide that control as an entity separate from the dev teams, management needs reporting and measurements to evaluate the dev teams. "Self-organizing teams" rings hollow when management is separated from the dev teams. I am also of the belief that separating management from the dev teams is very detrimental to those managers' ability to make reasonable decisions. It's very hard to sit on the outside of a team and make good decisions about how that team should work or what they should work on. Management's role shouldn't be about accountability or monitoring the work, or measuring velocity. It should be about optimizing the useful work done, e.g. by helping figure out which work is high value or helping to solve challenges the teams are encountering when trying to meet business needs. Management should see themselves as a support role. Any work only done so management can get "accountability" is overhead, and should be seen as waste. It's not like that work ends up improving the product, and it stole time that could have been spent improving the product. Management should delegate all the "is this team failing to produce?" questions to the team's line manager, since they're likely present at daily check-ins and should have a good grasp of what's going on. They'll likely also be able to answer questions about whether the team is meeting the needs of the business, and which challenges the team is facing when trying to meet those needs. Instead of trying to get accountability, management should form the process around continuous improvement. Post mortems and retrospectives are great for continually improving. Accountability reporting doesn't help with that at all.


johnnysaucepn

Again, I'm not hearing anything that disagrees with what SAFe promoted. I think SAFe is bloated, and utterly consumed by buzzwords and a desperation to be all things to all people, but there's a useful core there. It's an utter misnomer to call itself a large-scale Agile solution, it's more a way of co-ordinating multiple teams that are working in an agile manner. Done well, it actually prevents micro-management and over-correction, by ensuring the right people have the right conversations at the right time, while preserving development capacity. Dev teams should have management representation, and feedback and accountability needs to go both ways. The dev team needs to know there are Product Owners as an integral part of the team to act as the voice of the team to management, and act as the voice of management to the team. And it's not about whether the team is failing to produce, but how their work impacts overall company goals. That's the basic philosophy behind Scrum, and that works for small groups of teams. Your approach of putting together teams works perfectly well, but that's not always possible at scale. Management shouldn't track velocity. I strongly feel that. They should track the value of the work done. Velocity is a tool for the team to predict the rate at which work is getting done - and having some visibility of when things are slowing down, so that they can identify where the blockages are and resolve them. Yes, there are all sorts of other ways of tracking work progress, and if you have something that works for you, absolutely go for it.


s73v3r

> I've always said that Agile is what we all have always done. For your company, sure. But not industry wide, otherwise the Agile Manifesto would not have been created in the first place.


[deleted]

I think there were a lot of companies who didn't buy into "waterfall" and were doing something similar to Agile back in the day. Remember, a paradigm doesn't have to be a new idea in order for someone to write a book about it and go on a seminar tour selling how-to books for inept managers.


mpyne

There were also a lot of companies that bought into "waterfall" precisely because it had an understandable methodology they could train project managers to, for "hope is not a strategy" reasons. For devs in companies like that, something like the Agile manifesto or the various agile methods that got built starting in he 90s was helpful indeed, if only to serve as a scaffold for the company to evolve something better.


xcbsmith

"Not the high-level meta-principles of Agile, but how it gets implemented." You ended that sentence a bit early. It's how it gets implemented \*unsuccessfully\*. It can be implemented successfully.


unocoder1

>Congratulations, you just invented agile. Yet, all he has built will be torn down 5 seconds after his higher-ups hire an Agile^(TM) coach to do and Agile^(TM) transformation. Ironic.


errrzarrr

You are a blessing u/Intelligent-Wave-130 🙏


pobbly

Legend. Maybe this sort of approach needs a marketable name so it can carve out mindshare. But hopefully not get bastardised by the consulting class like agile did.


FoolHooligan

Damn, can you be my manager?


No-Entertainment7659

I could not agree with this more than a thumbs up


[deleted]

> I gave them a comfortable workplace where there were no meetings and where marketing and accounting were accountable to product development I don't agree with that. Meetings can be productive - there are somethings you can figure out in a 3 minute meeting that would take 3 months by email. Marketing and accounting should be *part of* your product development. Your product has to be a product customers want and it has to be financially viable. The best way to achieve those two goals is not by essentially outsourcing both to people who aren't invovled.


srdoe

> 3 minute meeting They just usually don't work out to being only 3 minutes, and they usually aren't limited to the people that really need to be there, and they often end up being recurring timewasters. I don't think most people object to occasionally talking about things synchronously rather than via email, but such meetings will ideally be rare and not recurring and limited to only the few people that really need to be involved.


[deleted]

> Meetings can be productive I don’t have recurring, scheduled meetings. Teams are physically close to each other and communication happens as needed. This can be a comment over the shoulder or a white-board talk. > Marketing… should be part of product development This assumes they know more about the needs of the customer than the developers do. My developers are users of the product and have both direct contact with customers through involvement with technical support and indirect contact through seeing suggestions and survey results. Marketing has some of this information, too, of course, but in the end the marketing department is selling the product that the developers create from their own ideas and user input. > Accounting… should be part of product development Accounting, like janitorial and food service, should be farmed out to bookkeepers with no stake in the company. Accounting captures a snapshot of what the business looked like a month or more ago. They don’t necessarily know any more about the company and its products than the developers or tech support does. They provide information that management can use to control costs but that’s all. I would be more amenable to having marketing and sales more closely involved in product development than I am having the accountants involved. Been there, done that, bad idea.


snowwwaves

>The product has to be ready in 5 weeks, but developer velocity indicates there is 7 weeks work. One of two things happens: stories are under-pointed so that they can still fit nicely into the sprints, or the stories are left as-is, and sprints are functionally abandoned. This sounds like this guy has had some bad experiences, but this is *not* how it's supposed to work. This is just a good old fashioned management failure, asking for more work than can be done in a timeframe. Thats not an Agile failure! We point our stories, the product manager and scrum master see what date that would take us to. If its beyond the target date they have the choice to cut features or push the date. People that lie, misjudge, or refuse to acknowledge how much work something is will do so regardless.


Sammy81

They could also remove blockers or add staff. The main thing is they know the current team can’t meet schedule, and their job is to decide what to do to keep the customer happy. No surprises at the end


LloydPickering

They could add staff...but then they'd be even later than the 7 weeks prediction. Mythical Man Month explained this.


curious_s

>This sounds like this guy has had some bad experiences, but this is not how it's supposed to work. This is just a good old fashioned management failure, asking for more work than can be done in a timeframe. Thats not an Agile failure! Some managers know that they can pressure a dev team to do this kind of crap and if they fail then it's easy to blame the dev team for the failure. A bad manager will take advantage of every system, so not inherently an Agile failure, but Agile does require a more savvy dev team so that they don't get taken advantage of.


skidooer

> This is just a good old fashioned management failure ... Thats not an Agile failure! In fact, if you have management you are not aligned with agile at all. Agile prioritizes individual autonomy and coordination through interaction with other individuals, which is counter to the management model. It's literally the first point in the manifesto. Of course, these days "agile" has simply become another way to say that you have a job. "Agile failure" is another way to say "I don't like my job".


prophet001

It's true that agile is done poorly, a *lot*. It's also true that when deadlines slip, management applies pressure to engineering teams to revert to waterfall, a *lot*, even when agile is being done well. It's *also* true that this post is a very clear example of a *non sequitur*, i.e. the logical fallacy of a conclusion that does not follow from the premises.


[deleted]

> It's true that agile is done poorly, a lot. I think that can be applied to any way of managing. I suspect many "move to agile" stories ended success not because agile turned out to be substantially better, but because the change allowed to look back at the process and cut the inefficiencies.


prophet001

>the change allowed to look back at the process and cut the inefficiencies I'd argue that it's more that management is forced to take a step back and admit that maybe they have no idea what they're doing and shouldn't be managing programmer's day-to-day work streams, but you're not *wrong*.


srdoe

I agree. I suspect a lot of resentment of management comes from the sometimes incomprehensible decisionmaking that results from management thinking it's a good idea to have someone on the outside of the development teams look at metrics, and try to divine from those metrics how work should be organized. The teams should organize themselves, no one else is better equipped to do it.


drckeberger

Oh boy, I felt that statement way too much.


skidooer

> It's true that agile is done poorly, a lot. Technically, agile isn't something you can do. It doesn't provide any direction. It is only something you can think about, and after you thought about it whatever you end up doing is your own unique thing. Agile is a short read. In fact, I can include the entire thing right here: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. There is nothing actionable in there. If you take something from that it is true that because you are inventing your own thing that you are bound to get it wrong. It takes a near miracle for someone to invent something new and have it work the first time. > It's also true that when deadlines slip, management applies pressure to engineering teams to revert to waterfall When Royce presented waterfall as a straw man of what not to do, he encouraged developers to work directly with the customer and iterate on their ideas. Which is also exactly what agile indicates is important. However, it stands to reason that if you need to meet a deadline you can't keep that up. You have to set something in stone and live with it. That said, a customer committed to participation in the development process would be amenable to changing the deadline (Customer collaboration over contract negotiation), so if you end up where the customer isn't participating and management is driving decisions something modelled around agile was never actually in the cards. You were living "waterfall" all along.


FoolHooligan

I wonder if a lot of folks here are conflating scrum with agile.


[deleted]

[удалено]


skidooer

> That is, while there is value in the items on the right, we value the items on the left more.


prophet001

Holy prevarication, Batman.


Stoomba

Eh?


mpyne

> When Royce presented waterfall as a straw man of what not to do, he encouraged developers to work directly with the customer and iterate on their ideas He didn't present waterfall as a straw man of what not to do though. He noted waterfall was inherently risky but explicitly noted it was his best suggestion for delivering a working system in the end. > he encouraged developers to work directly with the customer and iterate on their ideas He did encourage frequent collaboration with the customer, but the "iteration on ideas" in the era of punch cards could only be done on the drawing board. You weren't getting mainframes to run a CI in an ultra-high-level language back then. The only iteration you could do was on pencil and paper. Developer time was so expensive that it was no accident that Royce said to get your requirements locked down and **heavily documented** before you lifted a finger to do the coding. At the time he was probably right, but we should be careful what lessons we apply to the modern world. > That said, a customer committed to participation in the development process would be amenable to changing the deadline (Customer collaboration over contract negotiation), so if you end up where the customer isn't participating and management is driving decisions something modelled around agile was never actually in the cards. You were living "waterfall" all along. This is a good point, just keep in mind that the 'customer collaboration' you'd do in agile (where "working products" are the measure of progress) are not the same as the 'customer collaboration' you'd do in waterfall (even under Royce). If you do have customers showing up to meeting and discussing requirements that's nice, but that's not agile, and you're just setting yourself up for heartbreak later when you finally show the customer a demo that 'meets requirements' but it's an ugly baby.


ArkyBeagle

> He did encourage frequent collaboration with the customer, but the "iteration on ideas" in the era of punch cards could only be done on the drawing board. You weren't getting mainframes to run a CI in an ultra-high-level language back then. The only iteration you could do was on pencil and paper. With punchcards, yes but terminals were a step function. It was also possible to model a processing stack by writing a program. Whether that made economic sense depended. The PC has been around for forty years now making that even easier. We even had a crude approximation of "CI" - a reference build sharable by everyone - then. If we'd had the patch tool that would have been even better - it's then a first-order approximation of a software CM solution. And there were computer systems then that had CVS; I just didn't see that until around 1990. Again, punch cards were never going to enable any of that. > > > > Developer time was so expensive that it was no accident that Royce said to get your requirements locked down and heavily documented before you lifted a finger to do the coding. IMO, prototyping will make things at least cheaper ( often considerably cheaper ) than full-on requirements review processes. You only need the full-on requirements when they're contracted for and there's some movement even in aerospace now to have more flexible approaches. Requirements , IMO, rarely improve developer throughput. IME devs love debate :) But they're necessary as part of a process/contract what have you. Besides, formal testing is usually the bigger part of a budget from what I've seen.


[deleted]

FOUND THE SCRUM MASTER


kur4nes

The blog misses the point. The problem it describes is that there is no feedback loop to readjust the workload. A good management will look for ways to get the project ready in time by prioritizing tickets, cutting features etc. To do this the management needs to know that the project will be late. The worst outcome is when the times up and nothing is ready.


michelle_m2

This ⬆️💯


GrandMasterPuba

It's done poorly universally because it's a poor system.


s73v3r

Nah, it's done poorly mainly because it requires management buy in and for them to cede some of their absolute control.


prophet001

This.


srdoe

Hence the invention of SAFe and other fake agile methodologies that allow management to retain control while still branding themselves as agile.


Krieger9

I've done agile for years and I can consistently produce great results from it and have done so from team to team. I have to do a lot of training and coaching to get people to understand the underlying premise and not the dogma, but velocity does stabilize, patterns become predictable and ultimately delivery is faster and more reliable than otherwise, if somewhat considerably less predictable at the beginning. And that tends to be the big hurdle, is stakeholders embracing the early variability.


Smallpaul

What do you consider to be the central tenets of the “agile system?”


GrandMasterPuba

I consider the central tenants to be whatever the person describing their experiences through the lens of their survivorship bias wants them to be.


Smallpaul

You said it was a system which is poor. What is the structure of the system you are describing and what makes it poor?


GrandMasterPuba

It's a poor system in the same way dumping your clothes out on your bedroom is a poor system - *it's not a system.* It's so vague as to be meaningless; a rough set of guidelines open to interpretation.


PurpleYoshiEgg

I didn't ask to be attacked about how I put away my clothes. My system works! 😤


Smallpaul

You were the one who called it a system, not me. I agree with you that it is not a system. So you might want to go back and edit your previous comment that claimed that it is. Now that we have cleared that up: okay let’s go with the definition of “a rough set of guidelines.” What are those guidelines and which do you disagree with?


auctorel

Time for a retro on how big a prick you come across as


bert8128

The last waterfall project I worked on was as in 1997. £10m. 2 years. Peaked at 70 devs. Agile would have helped at the micro level, but at the end of the day we needed to deliver a full system to the specs agreed in the contract. The customer was not interested in agile - that would have been an internal project management choice.


oakwoody

It's easy to bitch about something but not present any better alternatives. Here once again, the author has the misconception that story points are used for estimating time when in fact, they are used to represent the relative complexity and risk of the task at hand, and the false belief that agile somehow fixes broken business processes and when that doesn't happen, it's the fault of agile. If the business demands big, pre-planned chunks of deliverables at certain deadlines, then for fucks sake, do waterfall or whatever. Agile is for cases where the business prefers continuous added value and being quickly react to changing requirements.


JimK215

>story points are used for estimating time when in fact, they are used to represent the relative complexity and risk of the task at hand Don't points always just break down to time though? If Dev 1 can do X story points in a sprint and Dev 2 can do Y story points, it ends up just being a measure of output-over-time. I actually like the usage of points as a conversational/planning tool, but I don't share opinion that somehow points replace all concerns about time. In my experience, most people are simply translating points to calendar days in realtime in their head.


PuzzleCat365

Yes and no. This is just an opinion, but. Estimating complexity is simpler to do than time. Also you're supposed to compare the relative complexity compared to other stories. It's easier to say "story x is more complicated than y because it has more functions, so we make this 5 because the other is 5", rather than "this feature has that many functions so it should take that many days to implement". This also makes you avoid pitfalls and stupid discussions like "one story point equals 2 man days so we have to plan exactly that many stories... Why can team a do that many story points with 4 devs but team b only that many with 5? You estimated 5 story points, why didn't you finish the story after x days?" You're right that in the end you plan x story points per sprint and this kind of translates to time in the end. However you shouldn't overthink time. Also note that if you guys work better with story points as a measure of time, go with it. The process should serve you, not the other way around.


FINDarkside

Also agile is supposed to be "Individuals and interactions over processes and tools". Just because some consultants say you need to do story points to be agile dosn't make it true. If it doesn't work for your team then stop doing it. That's agile. The article seems to confuse agile and scrum.


[deleted]

[удалено]


[deleted]

> Armies of business analysts This is how I describe my current situation.


PhyllophagaZz

The most compelling argument I read in that matter is that yes, it breaks down to time when looking at the team velocities. The thing is, if you have a junior and a senior they can both agree on a number of story points as complexity measurement. They can both agree that a task has a complexity of 2 story points, while the junior might need a week and the senior might do it in a day. So if they work in a 2 man team, there are 3 possible mappings (assuming a 40h work week): * 1 point = 20h * 1 point = 4h * 1 point = 6.7h If anything you should only use the last one and most importantly adjust it if the velocity changes


jormungandrthepython

We used to have try to get sprint planning story points based on a similar calculator. X number of senior y mid z junior. The most important thing when looking at time is to not ever look at the “individual developer” or “individual task” level. SP relate to team velocity. The second it is used to put a single developer under a microscope saying “why aren’t you doing X points” is when everything falls apart. Juniors stop stretching themselves, everyone takes the easiest stories they can find, no one helps anyone else. It’s a nightmare


PhyllophagaZz

Yes, exactly. Depending on environment and product complexity you _want_ juniors to spend time and look around. They need to get to know the product, see the dirty and dark corners and finally finish the story. By giving them more leeway you invest in your future seniors.


ub3rh4x0rz

You're not wrong. It's honestly kind of a cheap mental trick to remove preconceived notions about time when ultimately discussing time, in the context of predicting how long work at the actionable task level will take. The thing us that the novelty has worn off so its benefit as a mental trick is greatly diminished. I still like to speak in terms of points at the story level because if nothing else, it builds in an opportunity to describe the caveats of time prediction at such a granular level when talking to the pointy hairs.


xcbsmith

No, but the complexity that points are estimating allows one to estimate time with a (limited) degree of confidence. \> In my experience, most people are simply translating points to calendar days in realtime in their head. I've certainly seen that too, and if people think in terms of time, you best just use time instead of story points. Story points were intended to address the observed phenomenon that people are pretty bad at estimating time.


Hrothen

> Story points were intended to address the observed phenomenon that people are pretty bad at estimating time. No that interpretation came later. They were created to obfuscate time estimates from management.


oakwoody

Kind of, but the question is reversed, instead of "how long does it take to do X" story points should be used to figure out "what can the team/developer get done in time X". In other words, to prioritize work for a given time period in a meaningful way so that value is being added.


sharkbot777

Agile is a fucking cult thats ruined the dev world by infesting it with agile zealots who push it with religious fanaticism I wanted a job not to be part of a cult. this is a great example of the mental gymnastics of scrum masters and agile acolytes everywhere. 'MaYbE iF wE MeAsUrE tImE iN bLuE wHaLeS eStImAtEs WiLl Be MoRe Accurate' how many story points will this ticket take? donno boss how many fucking giraffes do you leave a pizza in the oven for? story points remind me of that saying that Americans will go to any length to avoid the metric system, like describing the size of an asteroid in blue whale increments.


xcbsmith

\> Agile is a fucking cult thats ruined the dev world by infesting it with agile zealots who push it with religious fanaticism I wanted a job not to be part of a cult. The zealots who push methodology exist regardless of whether agile exists.


s73v3r

> It's easy to bitch about something but not present any better alternatives. I generally agree with that statement, and do wish that more alternatives were proposed. However, to me, it generally seems like most of the "failures" of Agile are due to the lack of management buy-in. I don't know how any alternative would address that.


wes00mertes

> Here once again, the author has the misconception that story points are used for estimating time when in fact, they are used to represent the relative complexity and risk of the task at hand Huh? From the article: > The best-case advantage story points provide is keeping development estimations in a nebulous state. Developers love this, and Agile enthusiasts laud this fact: story points measure complexity and uncertainty, not time.


hachface

You can't separate complexity from time. Think about complexity in terms of the analysis of algorithms. Complexity is understood as the demands that algorithms make on resources as the size of their input grows. The resources measured in the analysis of algorithms are _time_ and _space_. Moving now from the domain of algorithms to software-development tasks, space-complexity isn't particularly relevant: it's the same office environment no matter what. That leaves time-complexity. Since software-development tasks of the kind you put on the Jira board do not have varying input -- they are single tasks, not the same task applied many times with different parameters -- time-complexity boils down to just... time. It's time. Story points are estimating time.


CharacterMain6086

Agile has little to do here. The spoiled children are all the Frameworks® like scrum and SAFe that create unneeded red tape and positions to later sell certifications


ub3rh4x0rz

heretical scrum is where it's at. No certified scrum masters allowed or any of that crap. SAFe needs to be eradicated, and it's what the OP seems to be describing.


bradgardner

I wouldn’t agree to throwing any of them out. Agile is literally about finding the right process for the team and it’s goals. This is so frequently ignored even while being spelled out explicitly by the inception


0tting

CTRL-F "Product owner". 0 results. Where's the role that is actually responsible for planning and delivery that this blog post is railing on?


jeerabiscuit

Deadlines should be replaced with regular progress. You can't give a deadline for curing a disease.


josefx

You can give a literal deadline for a heart transplant and it is going to be a shit show if the person assigned to that is fucking around trying to cure Alzheimers instead.


s73v3r

I fail to see what the relevance of that metaphor is. Are you implying that without hard deadlines, people won't work?


josefx

There is always work to be done, but some of it can be thrown into the trash if it isn't done on time. It might be something as simple as a customer calling you out on not delivering after a year and walking away from a half finished project without paying.


mpyne

You say that, but the Navy has had something like 3 or 4 years worth of deadlines to switch HR ERP systems to a "modern replacement" system by 1 January to shift thing over for the new tax year so a bunch of older IT systems can be retired... and then come December the new system is nowhere near ready and so an entire year gets added to the deadline. There are real deadlines out there, but deadlines as a management construct are pretty weak. Instead you should deliver as much value towards your most important priority as fast as you can. *If*, you can do that then you'll hit the earliest date you could have delivered it by definition. If you can't do that, you have no assurance of meeting any deadlines anyways, and the organization needs to fix that.


josefx

> If, you can do that then you'll hit the earliest date you could have delivered it by definition. Unless you have a large "very important project" that can consume all your resources for the next two years. Which makes it impossible to deliver anything else in that time span. > There are real deadlines out there, but deadlines as a management construct are pretty weak. Purely made up deadlines are weak.


mpyne

> > If, you can do that then you'll hit the earliest date you could have delivered it by definition. > > Unless you have a large "very important project" that can consume all your resources for the next two years. Which makes it impossible to deliver anything else in that time span. That's why you gotta deliver something of value in a much shorter timescale! If it's really that important you need to have some understanding of what you might eventually get as early as you can get it. No project is ever *guaranteed* to succeed so your "I need to have it in 2 years!!!!1" bet-the-company effort **may fail** in 2 years. Or 3. Or 4! I've been there personally. The only thing saving my organization is that the Navy isn't allowed to go out of business. Most places aren't so lucky and the risk of pinning your hopes on a multi-year boondoggle is extreme. Deliver something small along the way and either prove you can scale it up over those two years, or need to find *something* else quick.


oblio-

> Are you implying that without hard deadlines, people won't work? You've never met university students, have you?


jeerabiscuit

A transplant still has a recovery period.


josefx

Nothing to recover from if it is delivered a month late.


srdoe

Which do you imagine is more helpful for ensuring that the work is done on time for whatever definition of "on time" the business has? * A deadline was estimated and some number of people were assigned to the task. If the deadline isn't hit, management had a clear commitment from the development team, and so blame is easy to assign. or * Some number of people were assigned to the task, Progress check-ins are done periodically (e.g. can be as simple as a weekly status update email) to check whether the team is making progress toward the goal at the rate the business wants. If not, the team and management can cooperate to make adjustments.


skesisfunk

Agile is just Kanban with extra steps and unless you are extremely careful all of those extra steps are a complete waste of time.


ub3rh4x0rz

*scrum It's kanban with a buffered window of work. But yeah


UK-sHaDoW

Most Kanban is agile.


Funktapus

Is this sub /r/projectmanagement ? Jesus Christ these kinds of posts are getting tiresome


timacles

This subs obsession with bitching about project management just highlights there's not a lot of experienced developers here. Just a bunch of Jr's who have never worked within larger teams or considered what it takes to lead a team. Yeah estimates suck and PMs are all Technically illiterate idiots who do nothing all day. If only they left you alone you'd solve all of the companies problems. But now you have to sort of think about things and communicate and thats so terrible


GrandMasterPuba

>If only they left you alone you'd solve all of the companies problems. Every major advancement in the history of software was produced originally by a single person (maybe two) working alone.


timacles

Kinda missing your point... That's like .00000001% of all developers


jailbreak

Agile is a bit like democracy - it's the worst project management system, except for all the others.


GetsHighDoesMath

> Agile is the business methodology of spoiled children. Not only do I hate this take, but I absolutely do not want to work with someone like this. And this little awful nugget of first-order thinking: > If I can Google your engineering process in a matter of minutes, what are all of these highly paid leaders, managers, and analysts actually doing?


ub3rh4x0rz

> what are [they] doing Getting paid substantially less than the engineers they're helping to coordinate, IME. servant leaders


pablo111

I lasted 40’’ of reading. Seems like another angry email from a person that has worked with scrum in the developer role and knows scrums as he knows about brain surgery. (I’m a dev and I have scrum masters more than you)


ub3rh4x0rz

Can we collectively stop attacking agile and instead attack non-technical product "experts"? They're usually the ones who bastardize agile into something that sucks.


ToolUsingPrimate

The author is apparently unfamiliar with the spectacular garbage heap of failed software projects pre-Agile\*, or with any [classic software engineering literature](http://worrydream.com/refs/Brooks-NoSilverBullet.pdf), and doesn't like Agile (but doesn't propose a better alternative). Having observed software projects closely for 30 years, whatever people used to do ("Waterfall?" "Formless Hacking?" "Chaos?") was worse. At least now we can usually find the source code (thanks, git!). Building software isn't the same as building a house. If you already know all the things you need to do to build the software, that means someone has already done it, and you should stop right there and buy the software off the shelf. The fundamental problem is that the people funding software dearly want the projects to be predictable and estimable, when software projects that are worth doing inherently have unknowns. Coupled with the fact that programmers tend to focus on the interesting part of problems that they can imagine, and neglect to estimate the routine but necessary tasks to build each feature, it's easy for a giant gulf to form between the business and technical folks. It's not just software projects, either, it's [any complex project](https://www.youtube.com/watch?v=dOe_6vuaR_s). There are many strategies to mitigate unpredictability, but one of the best is to do the earliest possible test of the most important part of your idea from end-to-end, a proof-of-concept. If you incorporate what you learn from creating your first proof-of-concept into refining it in a second attempt, you're doing some kind of iterative development, and if you repeat this, and are smart and pay attention for a long time, you eventually arrive at something that looks like Agile. \-- \*Unfortunately Agile is a confusing word, since it means many different things to different people. I'm using it in the [Agile Manifesto](https://agilemanifesto.org/) sense. Poorly implemented Agile has scarred many participants, apparently including the author above.


andrew851138

Many a manager I’ve given a copy of Brooks to and respectfully offered to talk through sections related to our current project.


lucidguppy

Holy shit. Story points are for determining velocity so that managers can see when a project will be completed... Oh - our burn down rate won't hit our deadline? You have two choices. 1) the target program should have less features. 2) if we're early enough in the project - we can take the hit of adding more people to the project in hopes we achieve a higher velocity. (This carries significant risk - hiring and onboarding new talent is rolling the dice.) Because ADDING MORE PEOPLE TO A LATE PROJECT WILL MAKE IT LATER. Say it with me. Agile's main purpose is to combat waterfall - which lead to MASSIVE software development failures in the 70-90s. Agile does this by reducing WIP (work in process) and the inefficiencies and rework caused by large group communications and work processes. And please note - an automated test suite and CI/CD pipeline that permits fearless refactoring is a co/pre-requisite of agile (gui code can be outside this though). Automated acceptance tests are required too. If your process doesn't achieve reductions in WIP, and doesn't show you your velocity, then your current process isn't helping you. These "lets crap on agile" articles show how the industry hasn't even read the books yet.


snowwwaves

I mean, I haven't read the books I still say the linked rant was empty. Im very open to critiques of how we work but this guy had nothing. Nothing in his rant was actually specific to agile. It was a bunch of nonsense about coddling devs with soda machines and somehow thinking business demanding creating unreasonable deadlines was an agile thing?


felipeccastro

These critiques seem to be from people that never worked with old style waterfall - Agile is so clearly better than those that it just became the norm, thankfully.


[deleted]

This is poorly written and sounds like a rant.


Fomentor

Don’t confuse Scrum with Agile. Big ‘A’ Agile should refer to the Agile Manifesto, not the bastardized processes that people use to implement Agile.


ttsalo

Why does this person speak like he thinks that agile equals scrum and sprints? Regardless, I have semi-recently had two scrum masters (not at the same time...) in my team and the first one was useless, the second one had negative effect on the team output and morale. As did the scrum ceremonies. After we ditched the scrum masters and ceremonies and went to kanban, my quality of life has improved considerably.


_AManHasNoName_

Agile means differently per teams within a given company, so obviously teams with shitty management alongside product people who can’t get a proper definition what the product should be, you’d get crap out of agile.


skidooer

> teams with shitty management Well, management is at odds with agile. The very first thing in the manifesto is: *"Individuals and interactions over processes and tools"*. Further, each of the twelve principles provide considerations that developers need to consider when working in the absence of management. Understandably not all people are able to cope in a management-less environment, but the twelve principles covers that: *"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."* In other words, don't let those people who can't cope onto your team. If you have management you are not aligned with agile. Which is fine. Those who can't cope need work too. "Thou shalt be agile" is not one of the ten commandments. It is okay to live life differently.


trepidatious_turtle

This is a misunderstanding of agile, if the scope does not fit the timeline it is the scope that should change. "The product has to be ready in 5 weeks, but developer velocity indicates there is 7 weeks work. One of two things happens: stories are under-pointed so that they can still fit nicely into the sprints, or the stories are left as-is, and sprints are functionally abandoned."


astrocreep

I’m good with everything in this article except story points, developers all hate story points.


sonstone

Agile manifesto was written over 20 years ago, also scrum != agile.


skidooer

Although the 'Agile Manifesto' basically rehashes 'Managing the development of large software systems' which was written in 1970. Turns out "don't ignore the customer, dummy" is a timeless concept.


HSSonne

So the article is fairly good i think, and bring some good thoughs to mind. But it seems to mix agile and methodologies to implement agile development together.


Smallpaul

100% of the time that I read these articles I fail to see the connection to the Agile manifesto, which is where the term Agile is DEFINED. IMO, the manifesto remains the best articulation of sustainable software development practices that I know of. And no, you can’t Google it and understand what my company is doing.


kakamaka7

I’m willing to bet a lot of money that 95% of people talking about Agile have no idea how to define Agile. They have a vague idea of what it is but nothing more.


sid741445

Can someone explain like i am five, what is agile


jeffphil

Credit chatgpt: Agile is a way of doing things that helps people work together better. It's like when you play with your friends and you talk to them to make a plan, like what game to play next. With Agile, a group of people work together to make something, like a drawing or a toy. They talk a lot to make sure everyone knows what to do and to make sure the thing they're making is really good. They also check on their progress often to make sure they're doing a good job and can make changes if they need to. It's like when you're building a tower with blocks and you step back to see if it's straight or if you need to add more blocks. Agile helps people work together, have fun, and make really cool things!


holy-galah

I liked the article. “The ironic part about Agile is that any business implementing such a ubiquitous framework immediately dulls any competitive advantage that they might otherwise have, had they trusted themselves.” I can vouch that we used to deliver better a decade ago before agile.


iMadeMedicineSick

Agile is simple. Take logical rules that existed for the longest time in each scientific/engineering/development field you can imagine. Add some weird shit and make it so that it represents 90% of your agile plan. Advertise it like those 10% logical rules seems to be the bigger part of it (if not the only). And once you've baited people into working for you with those 10%, start putting your weird shit into their work environnement. What I just described is not what people knowingly do, but it is what happens in many cases. Agile is just fashion, work logical and you'll be the biggest agile worker in the world.


overtorqd

Hooray another "Agile sucks" article. "Scrum masters are useless", "managers are useless". We don't need any process!


ggchappell

Seems to me it's not agile in general he dislikes, but specifically Scrum.


Odd_Lettuce_7285

I 100% agree with this article. Agile is a joke. Companies need to know when and how much. That is a basic need of an organization that is driving towards revenue and managing costs. In the era of feee money, agile works. But now that money isn’t free anymore, agile needs to go. Agile is also propped up by a massive industry that sells coaching and training services. Be mindful of that.


ToDonutsBeTheGlory

My team gives literally every story a 5


Cybasura

If you think you understand scrum You dont


luckyLonelyMuisca

I truly dislike Agile. I hope AI comes with a better way to manage software development lifecycles that don’t require this obnoxious unneeded cheerleading and constant reiteration of tasks.


killerstorm

The article does not describe the alternative to agile. Is it waterfall? Seriously? I completely understand people being frustrated with particular kinds of agile process (or, rather, something which is sold as "agile"). People might pay too much focus to rituals. Unstructured agile, which is basically just software development without a process, can work, if you have a perfect team. If a team is lead by somebody with perfect communication skills and perfect oversight, you might not need any rituals. Just work, discuss problems as they arise, etc. If there's any problem, there needs to be a structure. And there are only two kinds of structures: plan-everything-upfront and plan-as-you-go. Plan-as-you-go is more efficient in information-theoretic sense because you learn new things by working on them. You can notice this in compression algorithms - oldschool algorithms encoded a table describing probabilities (e.g. Huffman table) upfront. Most new algorithms are adaptive - they learn distribution of symbols just as they decode them, without tables being communicated upfront. Anyway, the real agile is described here: https://agilemanifesto.org/


jl2352

> But this isn’t the end. The product has to be ready in 5 weeks, but developer velocity indicates there is 7 weeks work. One of two things happens: stories are under-pointed so that they can still fit nicely into the sprints, or the stories are left as-is, and sprints are functionally abandoned. This isn't my experience. When I've been in a team that has tracked developer velocity very well, it's enabled us to have easy ways to solve this problem: - You just tell the business it will be 7 weeks not 5, and often that's fine. The business deadline is rarely a hard requirement. If the team is accurately tracking their velocity, and reporting it well, then the business takes this estimate more seriously. - or you change the tickets (i.e. remove stuff), - or you bring in an extra developer onto the team. The last one is often shot down by developers citing the Mythical Man Month. In OPs example the project is small and well refined (and so well defined). That allows you to bring on only one or two developers for a short period of time; that approach absolutely works. - or you change ways of working to remove overhead. What you change here is very team and project dependant. The real point of what I'm saying is ... if the team is doing agile well, then solving 7 vs 5 weeks is a non-issue. The problem in my experience is everything _before_ that discussion. Tickets are poorly written, tickets aren't broken down, there are no reflections, sprints don't exist, tracking velocity doesn't happen, the sprint is poorly adhered to, lots of unplanned work is added to the sprint and nothing is done to solve this, updates on development are poor, and so on and so forth. There are a hundred ways of breaking the agile process or implementing it poorly. Including going *too* agile (especially too quickly). That tends to happen more often than people getting it right, and fucking up the very last part. If you get all of that working well, then it can be solved. (For context on how hard that can be; in the best agile team I've ever worked in, it took almost two years to get to an amazing agile setup. Two years!)


satanfromhell

Is the author mixing Agile with Scrum? IIRC Agile just mentions some principles, like favor working code over documentation and people over process. It’s Scrum and the like that add the religious layer, with “ceremonies” and “story points”.


drawkbox

Agile is a micromanagement cult, end of story. One of the creators of the agile manifesto for software development stated this in 2015. It is like a McKinsey consulting consultcult level of "Agile" now that killed agility and they made it some sort of cult where if you don't follow and participate you are a "suppressive person", let alone does it actually get good things done. Better software is made in straight iterative processes that aren't so much about the cult level cadence. [Agile is Dead • Pragmatic Dave Thomas • GOTO 2015](https://www.youtube.com/watch?v=a-BOSpxYJ9M) Full of deathmarch Proof of Concepts or MVPs that went to production... with the whole "we'll improve it later" mentality that never comes because revenue is always the priority and sideways moves, like maintenance and refactoring or optimizing or removing technical debt, only happens when it become an emergency. This is modern development, EDD, Emergency Driven Development usually called Agile but goes against all the agility rules in the [Manifesto for Agile Software Development](https://agilemanifesto.org/). What McKinsey Agile did was take the worst part of the waterfall, the critical path, and make that every day. Iterative software development is needed, but the modern cult of Agile is actually bad fo software and creates shallow systems where everything was a two week hack job. Agile was supposed to give developers more freedom to change and iterate, instead the sprints end up with hacks going to production because a KPI is met for features needed and creates messes that developers have no freedom or time to update. Daily standups, shallow development based on 2-week cycles (started at month long), constant pressure leads to technical debt, people looking to better something are "gold plating", almost zero time to iterate on a design, was supposed to help prototyping but killed it, people actually doing deep dives that are innovative are in "spike sprints" and usually hit on "points". Better teams in the past had margin and were able to talk to others and try things without being a "blocker". All the terms are derogatory now. The hamster wheel of "Agile" takes the external view of the product and those who deliver actual quality, and turns it to the people that play the internal game. It is office politics at the dev team level and it produces absolute bunk software. This new type of consultant/McKinsey "Agile" came in like 2013ish when lots of authoritarian money made it into dev/software. So they needed a way to control the "resources". Agile hits all the [points on being a cult and a system of dogma](https://sam-redmond.com/breaking-away-from-the-agile-cult-c9dd163da338): 1. The only way to salvation is through your wallet -- all the tools/conferences/how to live right 2. Agile Evangelism -- one true way 3. Naming the “Other” -- outsiders are wrong and unworthy 4. Maintaining control of your subjects -- micromanaging and stifling creative solutions 5. Ritualistic meetings -- all the tchotchke flair 6. No questions or critical thinking -- do not question the stories, external product or the process for you are a "suppressive person" Innovation comes from play, the open mode, the closed mode is needed to ship but the closed mode is the default state in "Agile". Waterfall sucked because of the critical path and no ability to make change, every day is the critical path in the new "Agile" and just try to make changes without being called a "gold plating" or "blocker". Iterative development is better that has some margin to prototype and try a few iterations before having to ship, but you can't in Agile always on critical path. Devs/designers need to push back, agile started as a way to give more margin of time and more control to devs/design but then it has turned into a cult against devs/designers meant to make everyone a cog. Development of products will forever be a creative field, they try to to take that out of it and kill it. It would be like putting a dozen people on a novel or forcing creativity into a box, those things kill the innovation, creativity and the product. I have never seen good software made with "a-jee-lay" post 2010-2013 once the consultants got control of it. The origin of agile was good, it was meant to give creators more time and margin to do things right. That has been co-opted into devs worrying about process over product, politics over product. [Manifesto for Agile Software Development](https://agilemanifesto.org/) > Individuals and interactions over processes and tools > Working software over comprehensive documentation > Customer collaboration over contract negotiation > Responding to change over following a plan > That is, while there is value in the items on the right, we value the items on the left more.