Agile works since 1947 at Toyota:
https://en.m.wikipedia.org/wiki/The_Toyota_Way
Dear Agile, I’m Tired of Pretending (2018)
241–250 of 420 posts
Re: Dear Agile, I’m Tired of Pretending (2018)
#242It is a balance: We don't know how long something we've never done before is going to take, and at the same time, we often need some time boundaries so we don't go off tangent building some wildly ambitious re-write of the world.
Perhsps the qustion we ask in projects shouldn't be "how long will this take?" but: "How long do you want to spend on this problem?".
Re: Dear Agile, I’m Tired of Pretending (2018)
#243Earlier quoted context omitted.
> between an output and an outcome and a huge distinction between a project plan and a road map. I mention neither of those. I'm not complaining about your reply, I think it shows how those texts are (to be?) used: Just like art. You project your own experiences into it, it's more about getting you to think. So naturally different people are going to react differently and read different things into the same text. Tha…
I think you misread the part you quoted, while GP read it correctly - it's comparing outputs and outcomes, not outcomes and milestones.
No I did not.
Let me quote again what I already quoted:
> with roadmapped outcomes replacing planned milestones
"outcomes" vs "milestones"
See?
Re: Dear Agile, I’m Tired of Pretending (2018)
#244I’ve been a tech lead for 6 years and Agile has given me a lot of imposter syndrome because I can’t seem to make it work for me. The biggest point for our org is to cost work items and realize a consistent throughput for our team on which we can make scheduling predictions.
Unfortunately my tasks tend to be nebulous. They involve investigating very large potential systems and breaking out smaller tasks, many of which won’t be fully understood till we’re in the trenches. How do I cost the time it takes to learn how Spanner will handle my design and update architecture accordingly? How do I cost “interrupt driven” work like getting buyoff on a given architecture? One of my OKRs was literally “Create a security model for a new foundational technology that is acceptable to all integrators, follows Google Cloud best practices, and can be represented in Kubernetes.” How would you break that into (bi)weekly sprints? You don’t even know what work you’ll have to do until you go to a committee of stakeholders and get told where you have to go back to the drawing board.
Re: Dear Agile, I’m Tired of Pretending (2018)
#245Earlier quoted context omitted.
I feel as you should be able to provide an estimate even if it something that you have not completely done before. One should spend some time to gauge how much of this new thing is really "new" and what parts should be easy to figure out. Then, try to look at resources about those unknown parts, and that should allow to provide a rough estimate. And when road blocks come up just communicate early, and then if PM/boss…
Im not a coder, so maybe the domain is different in a way i dont understand, but I agree with you 100%. Refueling nuclear aircraft carriers have projections start to finish, a half decade long. There are countless pre and co requisites with interrelated projects, not counting the mundane issues like material and manpower. I simply do not accept it is impossible to project a timeline for software. If someone stops you…
> If youre a professional coder and you show up to a planning meeting and your answer is "I dont know, i have no idea and its not possible to provide an answer even on an order of magnitude" thats just ridiculous.
True, but it's because that question is often ridiculous.
If it's technology I've never worked with before, in a domain I've never worked, for which the test data doesn't exist yet, it's perfectly reasonable to be outside an order of magnitude.
E.g., we mostly do Web app development with React and Django, sometimes going into more complicated data processing and visualization. In a recent planning meeting we were asked about recognizing waterways from aerial photographs to improve local government's GIS datasets. Ummm...
Re: Dear Agile, I’m Tired of Pretending (2018)
#246Earlier quoted context omitted.
I feel as you should be able to provide an estimate even if it something that you have not completely done before. One should spend some time to gauge how much of this new thing is really "new" and what parts should be easy to figure out. Then, try to look at resources about those unknown parts, and that should allow to provide a rough estimate. And when road blocks come up just communicate early, and then if PM/boss…
Great! Please let us know when cancer will be cured. In other words, "I don't know" is sometimes a complete answer. I don't know. Period. This is supposedly one of the main points of this religion (agile). Some things are unknowable. So you move ahead a bit, and reassess. If you are scrumming, that is usually 2-3 weeks, and don't get me started on that arbitrary limit. But, you try to move forward for a bit, learn so…
> Please let us know when cancer will be cured.
An absurd comparison given most software engineering tasks have been done before, they're simply difficult to estimate for some given team without expertise in doing some particular task.
Re: Dear Agile, I’m Tired of Pretending (2018)
#247I've been developing software for over 20 years, and I still can't estimate how long something will take me when I've never done it before. This uncertainty needs to become more than just a stick to beat developers about the head and shoulders with. Most of the time the PMs understand this, but there have been many projects where they just don't get it. I have suffered great anxiety from being forced to give estimate…
Probably lost 10 years due to that.
Re: Dear Agile, I’m Tired of Pretending (2018)
#248> "So let’s get on board with continuous learning, and let’s stop pretending Agile was some sort of cure all."
Did anyone - who has seen shiney new panaceas come and go - believe it was a cure all? What it is, like MVP, is a way to mitigate risk. It doesn't eliminate risk. It can only mitigate it.
Furthermore, it still boils down to team and people. No tool will save a dysfunctional team. The key isn't the tool. The key is the key agreeing on the tool, and sticking to it. That is, tool is not a proxy for deep and solid team work.
Re: Dear Agile, I’m Tired of Pretending (2018)
#249I've been developing software for over 20 years, and I still can't estimate how long something will take me when I've never done it before. This uncertainty needs to become more than just a stick to beat developers about the head and shoulders with. Most of the time the PMs understand this, but there have been many projects where they just don't get it. I have suffered great anxiety from being forced to give estimate…
After many years in large infrastructure transformation projects, Johnny’s Rule of Threes now goes like this:
1. The first time you do something, you can guess how long it will take and what the detailed steps will be, but that is all. You should still plan it, but during execution of this phase you must take copious notes. Do not expect it to be correct.
2. After you have done something for the second time — using what you learned from the first time — you should end up with an accurate schedule. This schedule contains all of the steps required to do the thing along with accurate estimates of time and cost.
3. The third time you do the thing, you are able to do it to schedule and to budget.
Re: Dear Agile, I’m Tired of Pretending (2018)
#250Earlier quoted context omitted.
I feel as you should be able to provide an estimate even if it something that you have not completely done before. One should spend some time to gauge how much of this new thing is really "new" and what parts should be easy to figure out. Then, try to look at resources about those unknown parts, and that should allow to provide a rough estimate. And when road blocks come up just communicate early, and then if PM/boss…
Great! Please let us know when cancer will be cured. In other words, "I don't know" is sometimes a complete answer. I don't know. Period. This is supposedly one of the main points of this religion (agile). Some things are unknowable. So you move ahead a bit, and reassess. If you are scrumming, that is usually 2-3 weeks, and don't get me started on that arbitrary limit. But, you try to move forward for a bit, learn so…
Insisting on the estimate in that situation is basically a special case of the old trope of using something meaningless but easy-to-measure as a proxy for something important but hard-to-measure. It's hard to know how long something will take, and easy to ask someone how long they think it will take (or if it's you, to pull an estimate out of your butt).