181–190 of 231 posts
Earlier quoted context omitted.
You're never going to know that. I rather track for example DORA metrics like MLT or DF versus tshirt sizes.
Aren't those DevOps KRs? I would track KRs even in software engineering: releases without incident, estimate to reality ration for future planning, etc
Here's my beef with estimates. I can give you a really really accurate estimate, but in order to do so we're going to have to spend a lot of time going through the request, building and verifying actual requirements, designing the solution and then validating it. The process will require dev resources, business resources and probably people from the support team and will take a lot of time. I'm happy to do it. It's a…
IMO the best use of "agile"-style planning is to replace the estimation process with development. After 6-12 weeks you'll have some amount of working (if minimal) software, and a decent (by software planning standards) idea of how long at least the first major set of features will take. If you like what you see so far, and the estimate doesn't seem like it'll wreck your budget or timeline, you keep going. If not, you…
I've always hated estimating. Then a few years ago I realized that if I'm going to work on a project with a team of six for a year (at a San Francisco tech company) that's in the order of a million dollar investment (likely more). If the organization is spending a million dollars it's reasonable for them to ask for an idea of what they'll get and when!
Earlier quoted context omitted.
Kanban lends itself well to this. Breaking down work into similarly sized tickets/units can, over time, be used to predict delivery/capacity (which one can use Cycle time to calibrate) Even neater with enough data it becomes possible to use Monte Carlo simulations to give you confidence intervals on how much can you do or how long you will take to do X amount of work. https://kanbanize.com/kanban-resources/kanban-ana…
Breaking down work into similarly sized tickets/units can, over time, be used to predict delivery/capacity IMO "can break up work into similarly-sized units" is equivalent to "can estimate accurately". Re: that article - I can't imagine many things LESS accurate than "we have 104 tasks on the board and each team member's cycle time is 2 days so we can finish all the tasks with 10 people working for 20.8 days". Yeah,…
Teams above a certain maturity level do often settle on a certain number of delivered tickets per month, and when you're looking at that sort of resolution, dependency problems and other factors like those you mention are represented in the data. It's not so much a measure of how productive the team is, it's a measure of how much work the team can get done embedded in the organisation they're in, which covers off their ability to resolve blockers and communicate with other teams.
There's a very different cognitive framing if you count tickets, too: you're not saying to the team "come up with a number, you're going to get shouted at if it's wrong, and you've only got 10% of the relevant information to hand", you're saying "do your usual design process, and we'll use the output to make a projection based on the history." Functionally it might be equivalent to "can estimate accurately" but it doesn't work like that when you're the one in the hot-seat.
Complexity exists in interaction between parts - not necessarily the parts themselves. Breaking down a project do not take those interactions into account. Even if we were to try considering interactions we would fail. Like the weather, and other topics in the complex systems domain, software is sensitive to initial conditions. A small change in input (change in data or code) creates a large change in output. We gene…
I agreed with you all the way until the last part about symphony, that is how you lose the attention of managers and leader types. majority of software is not a symphony rather a race car held together by ziptie and ducktapes just well enough to give a feel of something big in behind the curtains. this is especially true if you consider the incremental work projects take on. THAT incremental work IS forecast-able. pr…
Let's agree that estimation is possible to a certain degree. We know this and accept the inherent uncertainty.
Modern project management is whole sale copied from industrial construction and manufacturing. It seems no one stopped to ask whether the same logic applies to software creation. And it doesn't.
The business side of IT is stuck in a mental model build on construction and manufacturing. Yet the process of creating software contains neither of those concepts with the exception of automated build and deploy (and costs for those are negligible).
It is also interesting that no distinct vocabulary for software exists. We build, deploy, construct, have factories and so forth. Again copied from disciplines which are complicated - but not complex.
It is not possible to obtain the information you refer to by analysis. That's a property of a complex system. Analysis of parts neglects the interaction between parts and in software more or less everything is connected.
This is one of the reasons why we cannot forecast weather and why we cannot reliably estimate software.
Now, if I start my explanation this way I'm also sure to lose their attention. So what do we do? Which intellectual approach will captivate these people, retain their attention and at least plant a seed of doubt in the established way of working?
Here's my beef with estimates. I can give you a really really accurate estimate, but in order to do so we're going to have to spend a lot of time going through the request, building and verifying actual requirements, designing the solution and then validating it. The process will require dev resources, business resources and probably people from the support team and will take a lot of time. I'm happy to do it. It's a…
> Good and accurate estimation is not just a dev function. It requires buy in and input from the entire business stack. And in my experience, when people don't want to buy in to doing the whole process up front but they still demand some kind of commitment, the easy way to handle it is: "We can commit to a date and we'll finish whatever we finish by then, or we can commit to a scope and it will take as long as it tak…
This.
I often find myself saying “you can be feature-driven, or you can be date-driven, but not both.”
Steel in tension, low uncertainty, LRFD safety factor is 1.75. Steel in compression, medium uncertainty, safety factor is 2.5. Anything to do with soil, high uncertainty, safety factor of 4.
Same principal really. If it works for life/death scenarios, it'll work for you!
Look, it's just a requirement to know the weather 3 months in advance. A lot of money is riding on this: agricultural impacts, shipping, the effect on consumer behavior and power generation requirements. Doing without accurate weather reports 3 months out is just not acceptable. Sure, it's hard, but you have to just do it anyway, because it's so important. ... Except weather reports 3 months out are not reliable, unl…
it's so weird. i know it'll be cold in feb in minnesota. i know this because i have experience. and that experience translates into my ability to give guidance. if you want to be taken serious, you need experience to be able to estimate.
"Cold" is not an adequate analogy for the sorts of estimates that non-delivery parts of businesses seem to think they are entitled to, and it's not reasonable to say people can't be taken seriously for rejecting that trap.
It's by Steve McConnell (also author of Code Complete) and largely covers what this author does (but more, and in more detail). I have found it consistently one of the more useful books in my library - particularly for its emphasis on error bounds and on how bad people are at estimating confidence intervals...