cOdE fAsTeR!

But but but....

@@Maztergyl666 but before coding faster, lets have a 2 hour meeting on why you think this change requires 1 hour of work.

Which can be fine if the customer accepts that. For me, Agile is a good tool to understand velocity of a given team. Unfortunately, that is hard to know if it is made up of people you don't know. The team's velocity (avg. points closed over time) - can help you inform the customer of what can be achieved by a production date, or, if all features must be completed, when the production date will be. Customers want both, especially in the automotive industry - both features AND production deadlines are fixed.

In software, there is no standard. If you go to a car manufacturer and say "I want a car with 7 doors, one of them on the floor, and 15 wheels, 3 of them on the roof, and 5 engines" they will laugh you out the door, no matter who you are :))) These people don't understand the actual LUXURY they have when it comes to software.

@@ForgottenKnight1 Also, every 10 years the industry decides to no longer use the nuts 'n bolts of the previous product line, switching to something as radically different as e.g. using only glue or only velcro.

Software is 100% design! I'm going to remember that!

@@TheEvertw even worse: almost all libraries/SDKs update every 6 months or so with tons of breaking changes, which would easily break any estimate! And the management need new and shiny things, with smaller yet perfect estimate. At this point I find my kid easier to tackle than these non-technical (sometimes even technical) personnel.

@@SufianBabri Exactly! It isn't like the tooth shape of an M-10 thread changes every time the relevant committee has a meeting. But this does happen with our tools and even our programming languages.

Vanity metrics = vanity results

Quick fix on your text: "Management clings to estimates..." => "Bad management clings to estimates...." A manager work is to manage. Focus on controling aims to avoid unpredictable things, thus avoid things to manage; bad managers want to avoid having to do their work. But no matter how you fight reality, reality always wins.

I respectfully disagree that it's about vanity or control. Waterfall style planning is just the default. If I buy a jumper from Amazon, I expect an accurate ETA - I don't expect a vest this afternoon, a shirt in the morning and a jumper some point after that. I am very much for Agile, but I don't assume people are control freaks or 'clinging' for wanting an ETA on their project

​@@TomAndGingeCoLtd1996Right. Kent Beck has written about this with a lot of nuance. Senior management rather reasonably wants coarse grained estimates; the trick is not to turn things into a fine-grained estimation frenzy that ends up in meaningless story point=days and the like.

The Amazon jumper is an industrial process, repeated and stochastically predictable. Software is in general not. I watch department heads talk about accountability then apply pressure to meet the roadmap timescales, causing middle managers to claim empty victories on due dates, and the software to cause big clouds of bug reports on shipping because we track by the plan not by the condition of dependencies.

but most companies can't work "agile" for everything. I spent a lot of time in car companies, unless you have a bunch of devote fans who swallow everything and thank you, you can't roll out features months after the product rollout of a new model. the hardware is already in the car (or not), you pay when you order, you can't sell features, but deliver them agile, especially if legal/security is involved. Stuff needs to work on rollout when all the journalists drive your car and present your features. This rollout is planned years ahead, products go through long cycles, delaying a product rollout is also problematic (because your factories already order parts, free up production lines etc). In videogames, the "day one patch" and "feature will come later this year" solutions are pretty common and customers hate it with passion. And right now i'm in the public sector where everything is dominated by laws which are valid at a specific date or mass-events in a year for which the software must be ready and nobody is moving the Worldcup or Olympics because a bunch of developers was not feeling like updating estimations. And lets be fair, without estimations, we would be slower, not faster. Many (most?) humans are procrastinators, without deadlines, many of us would never get stuff done. A big reason why management loves estimations is to create pressure. Most of them know that it won't be ready in the estimated time, that's why they want updates and have big buffers to ensure that there is enough buffer left to get it done and react soon enough if it turns yellow/red.

@@vanivari359 If you can't fully work agile, then don't do it at all. There is still a place for the waterfall model. There you have to plan everything ahead and you can't be flexible. That is the tradeoff. And the "you need pressure or the lazy devs won't work" is a really bad thing to think. Pressure only results in shortcuts being taken and worse results in the end. If you want fast results, there are a lot of ways to motivate the developers. First, give them properly defined stories with "who", "what" and "why". The "why" is often the most relevant point that can lead to way better solutions than initially thought of. Then, try to make the results measurable. Is it something that will allow more orders to be handled? Will it automate a previously manual task and free n days per month of unnecessary work? Provide proper feedback for good work and maybe even give rewards for it. Maybe even create (positive!) competition between the developers. The rewards don't have to be money btw, it can be a completely worthless "company coin". Or ten company coins translate into one ticket for a quarterly lottery where you can win small price. Something like that. There are other ways, but I hope you can think of some for yourself. If I hear that a feature helps someone to get rid of an unnecessary task who has too much to do anyway I am way more motivated to implement it quickly than if some manager pulled some date out of their ass that I should keep so that they get their bonus for delivering no actual value of their own.

@@user-ff7ct4go5f scrum masters are the worst. These are people nowadays who want to be project managers or "do something with people" who went from university to a 1 week scrum training (or how long those are) and then explain agile to developers working in agile projects for a decade or more. Most of them are the manifestation of a cargo cult. It's a really bad idea to give people with no clue a simple book of "rules" to follow, the harm those people (who never produces a single line of code) have created in teams and projects.

@@pcap8810 They'll want both scope and date....otherwise no contract. You lose.

Government space isn't tricky. The way they work is flat out wrong. They hire consulting agencies with incredibly high turnover rates so they lose knowledge like air from a balloon. The comment on death marches is 100% correct. Consulting leadership won't do anything to push back on incredibly unhealthy anti-patterns so they will just throw bodies upon bodies to get something done just so they can save face. There's zero education of the organization happening. Government also has missing or broken feedback loops. Some/most government agencies have blank checks so as long as things are getting done nothing changes. Government sets the incentives, consultants don't push back because they want that big, ever-flowing gov check. The only way to work for a government agency is to act like an owner. You, your kids, your family, your community, the individuals actually dependent on that government service is depending on it. No pressure 🤭🤭🤭

The principles still work. You can make "proof of concepts" very quickly even for very complex systems. That is what stuff like LabView and Simulink is for. Risk-driven prioritization is even more important for those projects. And management needs to know and be OK with the fact that early in the product cycle, estimates for software can be off by a factor 2. If they are not OK with that, they need to manage the project differently, spending more time in small POC projects before going all-out. If you give a detailed estimate for a complex software system when there still are technical risks, you are doing your company a disservice.

You know what else doesn't work? Pretending you can accurately estimate events taking place out years from now and that will likely be done by a different engineer than the one doing the estimating. It is a fools errand, and you are only lying to yourself and your employer if you think otherwise. Even if you ignore all the usual bullshit like parts of the team getting pulled off to work on different projects or whatever; building a new payroll system isn't remotely like building a timber framed structure where you can get a rough idea of on average how long it takes your team to frame 16" on center stud walls per linear foot and then multiply that by the number of feet of wall requested to be framed.

@@TheEvertw That doesn't work before the team is even hired, or when deciding on buy vs build. You can't say it costs 1 million dollars to buy, and an imaginary amount of time and money to build. You still need to estimate. Budgets are done years in advance. But yes, I agree that estimates are hard, and often wrong.Also, you cannot make 'proof of concepts' for very complex systems. By definition, that makes them simple systems.

Ultimately it’s not just the time but the capital too and that does need planning. I always challenge any view of prediction however, I can’t dismiss the premise of the question so quick as this video does.

"Some projects ... have deadlines that are not agile in nature, or have external partners and dependencies that don't work the same way" Still makes estimation a huge waste of effort and time, and one thing I used to complain to my manager all the time. If you already had a deadline in your own mind, why the fuck did you ask me to give you an estimation? Just let me start working.

@@user-ff7ct4go5f How long have you been a Software Engineer?

​@@user-ff7ct4go5fGames? BS? What are you on about? You think writing clean code is a game?

@@user-ff7ct4go5f Yeah you’re a bot or something like that. You’re not making any sense.

There is a sort of privilege gap in some of this genre of content. If you're in the top 1% of sought after SE talent, Farley or Holub or Fowler or Beck, you get to be selective about not dealing with customers (employers) who refuse to accept reality. Most of us have to adapt to what it takes to keep our jobs, at least until we can get to a better place. Often that means playing along with nonsense estimates.

There is an emphasis by the "true" Agilistas that the developers should be in constant contact with the customer. Things are supposed to be hashed out, compromises made such as descoping the project and reevaluating what are actual must-have functionalities and what are simply nice-to-haves that can come about in later updates. Perhaps something early on is being implemented that has a very simple implementation but is being overcomplicated based on a fundamental misunderstanding on the customer's part that doesn't grasp just how complex the work is. If you're thinking to yourself that there's no way you can do this in a corporate environment, recall the adage that "Agile doesn't scale." These guys may disagree, but a large corporate entity is just going to have a lot of bureaucratic legacy and your ability to actually be agile is completely snuffed by it.

Ironically the best empirical evidence Agile doesn't scale comes with a brand name starting with "Scaled Agile...." And Dave has a video on that, too.

I didn't get much out of it, because it didn't really explain what to do in all the cases where estimates are essential, such as build vs buy decisions, yearly budgets, government contracts, etc., etc. This just rehashed old ideas that we as agile developers all know already - it didn't provide any solution to the very real cases where estimates are needed.

No you’re right. I work for a big company where we have “business” and “IT” and it’s hard to change the culture because there are lots of moving parts (like launching a new brand that depends on IT components, marketing campaign that have to happens a certain time…) and IT is pushed to estimate and keep their word. It’s not always easy then it comes with tons of buffer and lots of work to establish proper expectations… and if you miss you’re in a big stress all the time.

I wrote this as a independent comment but does align with yours so will add it to this thread. I Echo your thoughts I would not tolerate a trades person \ mechanic etc that wanted to give me on going sprint updates and no rough cost or time estimates as there was to many unknowns to be accurate. ............................. While I fully acknowledge that estimates in the software development field often resemble speculative guesses at best, especially if you don't possess an intimate knowledge of the entire technology stack and its intricacies (a rare occurrence), I also find myself somewhat disheartened by how we handle requests for such estimates within our industry. Speaking from my perspective as a developer, I understand and respect that many aspects of a project are so complex that accurate assessments are challenging until you're nearly 90% into its completion. It's astonishing how frequently tasks projected to take months end up requiring just a week, and vice versa. Never the less I see from a business point of view why they want estimates and time lines. To illustrate this point, consider a scenario akin to approaching a builder with architectural plans, asking, "How much will it cost, and how long will it take to build this house in this location?" The builder responds, "We work in two-week cycles. In the first sprint, we'll dig the foundations, and then in about 10 days, we'll estimate the cost of pouring concrete. In the sprint after that, we'll focus on the flooring, providing estimates for large, medium, and small details, and so on." I comprehend the builder's standpoint: they can't reasonably estimate concrete pouring until they've excavated the foundations, and they can't predict flooring or brickwork costs until the concrete is in place. However, as the one financing the project, I need a rough idea-whether it's going to take eight weeks and consume 70% of my available funds or if it's going to stretch over two years, necessitating the sale of other properties and potentially refinancing my family home. If it's the latter, I'd prefer not to commence the project at all. If, after four to five weeks, the builder approaches me, saying, "Now that we've dug the foundations and poured the concrete, we can discuss the brickwork. This section will be quite extensive and cost significantly more than initially anticipated," in the agile development world, many developers might view this as a triumph-a successful delivery of two productive sprints with accurate planning for the next one. Yet, as the homeowner, I perceive it differently: I have a hole in the ground filled with concrete, and I've already paid for four to five weeks of work, but now it can't proceed due to unforeseen escalating costs. put like that I think any of us in that situation would sympathies hence estimates are required.

@@michaelbourke8967 I've used the "building a house" metaphor for software development in the past as well but I've learned that this doesn't really fit at all. If building houses would be like software development, you could first just place a roof to have a dry workplace, then add the stairs and floors to be able to walk around and then start adding the stuff based on what's most important for the people who want it. You could for example let the residents move in without having any bathrooms. They could use chemical toilets and shower in the gym until there's time and money for the bathrooms. You could add the cellar last and add floors later if you see that there's not enough room. But with each house you'd have something you haven't seen before. Each one would have new materials or outside factors you didn't know about. Like the gravity or temperature would randomly change. Then the client would suddenly want a 3meter deep pool in the second floor and argue that that's a totally standard request to have and you should add it until the end of the next business day. Then the government would decide on a new law that requires you to change any door to be 2 meters wide, swing in both directions and - additionally to the normal key - will also open if a government key is used. Just because you have some overlapping terminology doesn't mean that you can compare those two. In my opinion, a professional company should be able to give a fairly good estimate for implementing some standard functionality. But almost every custom software development is very hard to plan ahead and even more difficult to estimate. So I would recommend to follow the advice given in the video for that part: Find out what is most important, order the tasks by importance and let the devs do them in that order. They have to be done anyway, so there is no real advantage in wasting time (and money) trying to estimate them, which will fail in most cases anyway.

Then you should be using waterfall, not agile. When they have to accept that no changes can be made to the plan without invalidating it, they'll quicky decide its the even worse approach.

@@adambickford8720In reality, they’ll use waterfall but make changes all the time. And you can’t complain.

Yet, estimations are always lower than the actual required time. If it would just be a factor of bad accuracy, we would over- and underestimate, but we always underestimate. It's called Parkinson's law, it's how most humans work. So by asking for estimations, management already has an important information: it will for sure not be cheaper and not faster. Now they can for example use historic information to see what the typical overrun is in that department or in that area or with that provider and they have a pretty good idea if they will make it until the product launch or a new tax law going into effect. And if the estimation leaves you with 8 month buffer and you are falling behind the estimations fast and hard, you have enough time to adjust (which happens, projects are "rescued" all the time in all kinds of ways after estimations for remaining work run into yellow/red status)

Exactly - many of these Agile advocates don't seem to live in the real world, or at least have only worked "in house". When you're dealing with a client with a fixed budget you need to deliver what they want for that budget. If you go over the estimate your company either has to take the hit, or the client has to agree to accept a partially finished product (which most won't, particularly if you have a contract which commits you to delivering the finished product within their budget).

Sounds like you are setting yourself up for either (a) failure or (b) pain. Low-balling your estimates to make them more appealing to customers / management means that the developers who will be stuck trying to meet those estimates will be forced to absorb the difference, at the cost of their own health and well-being. This seems to be why (a) software engineers are paid well, but also why (b) there is such a constant demand for young, fresh grad developers willing to take this sort of beating - because they don't know better. Both of these points directly lead to the sort of effective ageism we see in the field. The more times we have gone through this process, the less willing we become to go through it again, and hence the more compensation we demand for the pain it causes us. And the more we push back against decisions that lead to that pain. Both of which make experienced engineers less appealing to the managers who make the promises you find yourself making. We also push back against these unreasonable deadlines because they lead to technical debt, and poorly implemented software that is difficult to support and a nightmare to extend with new features in future versions. But of course, that is not a problem for contractors, because they only make the bed, they do not have to lay in it afterward.

@@rdean150 ? some contracts are for an entire team to develop the entire code base for a product and do it on time on *budget*. The penalties for not doing so can kill any profit, or worse, and lead to layoffs or even, for small companies, kill the company. Agile just doesn't accommodate for this, especially if the product involves functional safety certification like ISO-26262, IEC61508, DO-178C, etc.. Hence the term 'agile scrumfall'. But none of this goes over well with customers.

Then you take the hit if you're going over budget. Or decline the contract. Simple.

Clearly you have never worked with a Plumber or a Builder 🤣🤣

There's a reason people get pressured to do more for less pay. Layoffs are a thing. Companies fail. I don't believe there's any real "solution", but a corporation can mitigate failure. Reducing useless positions within the company, perhaps not spending on opulent perks, favoring a respect for work-life balance as opposed to paying top dollar for talented engineers, raises are low such that the employees typically can't beat inflation... Pick your poison: money or stability.

Why use more dollar when few dollar do trick

Congratulations on being unprofessional and childish.