| How do you do either of the following without spending any time at all on estimates? "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." If I was your colleague, had invested in your company, or was considering giving you money to deliver some product and you refused to tell me when you think it'll be done, it would be the last time any of the above ever happened. You wouldn't accept that from any service you were attempting to hire, so I don't know why it would be acceptable for software development. |
| |
| ▲ | wpietri 21 hours ago | parent [-] | | I feel like I've already answered the how question elsewhere. But the short version is a product-driven kanban-ish approach with frequent releases, small units of work, and engaged product management focused on actual real-world goals. This approach originated 25 years ago in Kent Beck's "Extreme Programming". Which did start with estimates, but teams doing well at it quickly realized (via said regular reflection) that they could do without it and still deliver well. That some random person on the internet who wouldn't have hired me anyhow will now not hire me is a blow I'll have to learn to live with. But I have literal decades of stakeholders happy working this way. One way that happens is that they pick a date and then we built what fits between now and then. So they get the date, but no promises about what will get delivered. In practice people like this better because beyond a certain very coarse level, estimates are about feelings of engagement and control. What this approach gives them instead is not just feelings, but actual engagement and control. What they get from me is not some unreliable bullshit date, but a commitment to deliver useful things early and often, so that we can together discover something better than their initial visions. And yes, of course I accept this from people who do work for me. My side hustle is starting a pinball museum. When volunteers take on repairing a just-arrived machine, I never ask them for estimates. I ask them to focus on doing it right. They discover problems, figure out how to fix them, and try it out to see if there are more problems. The work takes as long as it takes. Or I hired a friend to design the logo. I never asked for a date. We iterated on it, discovering an number of things along the way, including through user tests. It took a lot longer than I would have guessed, and that's great, because it turned out better than I could have hoped. I understand that this is unfamiliar to people, and apparently it's quite upsetting. But I swear this works. There are more things, Horatio. | | |
| ▲ | bpt3 20 hours ago | parent [-] | | It's not possible to do what you're describing (kanban/XP) for any commercial application or open source project that is intended to be taken remotely seriously without some amount of estimating involved. I saw elsewhere that you're defining estimating as a very detailed and involved process, which the author of the article did not, the person I originally claimed estimates are impossible did not, and I did not. I agree that's not necessary in most cases, if not all, to do the level of estimating you described. And you'll note that I didn't include "people who are doing me a favor" in the list of individuals I'd insist on an estimate from. You don't sound like you're one of these people, but I personally feel that software developers who act like they're performing special incantations over their keyboard and can't be expected to answer to anyone about their deliverables do us all a disservice, though maybe I should just be happy that they allow me to provide an alternative that is much easier to work with and results in additional business for me. | | |
| ▲ | wpietri 11 hours ago | parent [-] | | I am always fascinated when people tell me it is impossible to do something I have done. That plenty of people have done. For decades. But I shouldn't be surprised. Kuhn was not kidding around. And yes, I strongly believe in accountability to business stakeholders, customers, and colleagues. I just think the better way is not paper fantasies, but demonstrated realities. Focusing on working software, customer collaboration, and responding to change, one might say. But people have said it before and it didn't make much difference. | | |
| ▲ | bpt3 9 hours ago | parent [-] | | You aren't doing what you're doing without performing what is commonly known as estimating, you just avoid using what seem like triggering words to you and the one other person who is almost spamming responses to my comments with the same information. See "standard" vs. "schedule", and your very specific and formal definition of an estimate that is almost certainly not what anyone else has been using during this discussion and is not used in practice in most software development shops. Kudos to you for delivering working features on a consistent enough basis that you've earned enough goodwill that people basically leave you to your internal processes and trust that you'll come through for them. I believe that's necessary to have a healthy working environment where you don't end up with what you, I, and every other software developer on earth is trying to avoid, which is an acrimonious relationship with the people with the money where they dictate what, where, when, and how we do our job. But to claim that there is literally no estimating or scheduling taking place as you perform software development is just not true. You can post your disagreement on every single comment I've made on this topic if you want, your existing comments already speak for themselves on the matter. |
|
|
|
|
