Thread by @jayharris

@housecor I could not possibly disagree more.
And many years of fixed-bid consulting refutes your claim.

But first, I must get the kids off to school...

@housecor I could not possibly disagree more. In fact, if I felt that one billing method—hourly or fixed—was more in conflict with Agile development, hourly billing is the destructive choice.

@housecor If there was one reliable question from new clients, it is "What is your hourly rate?" If there was one reliable need from new clients, it is knowing the total project cost.

@housecor If you need to have your entire house painted, inside and out, are you going to care about the hourly rate of your painter or is your budget going to be based on the total cost of the project?

@housecor You have a $3,000 budget. When you get two hourly bids, Shiny Paint Company for $300/hr and Fancy Paint Company for $50/hr, does that satisfy your budget? Are your needs met? Can you make a decision on this or is the hourly rate really just a false flag?

@housecor Under this scenario, most would go with Fancy Paint. "$300 an hour? I don't even make that much. That's ridiculous! I can't afford that."

@housecor In the end, more-expensive Shiny Paint has a robotic system that can paint your house in 8 hours. Fancy Paint is old school, and is going to complete the project in 80 hours. Not only is Fancy much more expensive, you blew your budget, and had prople in your house for two weeks.

@housecor But you didn't know any of that. You were just blinded by Fancy's hourly rate.

@housecor As an industry, we pontificate good design, about how difficult it is to re-architect poorly-designed software, about how much of a challenge it is to untangle the speghetti. But in practice, we "Agile" buy saying that it's better to get our hands dirty; figure it out as we go.

@housecor As a consultant, clients don't pay me to get started right away. Clients pay me to Make Awesome™. "How much do you bill per hour?" is a false flag to "What's this going to cost me?" "How soon can you start?" is a false flag to "How soon can this be completed?"

@housecor This ignorance of a plan, of an and game, and instead choosing to jump right in and figure out as we go isn't Agile; it is malpractice. We might as well get in our boat and row before even figure out where we are going. Or that we even need a boat to get there.

@housecor Development teams advocate to the business that estimates are irrelevant; the back log simly needs to be prioritized and the developers will knock out the ordered items as quickly as possible. If that were realistic, hourly billing would work great. But it is never realistic.

@housecor "Priority" is subjective based on too many factors, only one of which is perceived importance. Estimate—total cost—is one of these factors. You may prioritize new windows over replacing the furnace. You may prioritize a $5,000 furnace over $50,000 windows.

@housecor Though a client may perceive a feature as unimportant, it may be at the top of the list if it will only take you a day to build. An important feature may drop off the list if it will take you a month to build, cost prohibitive.

@housecor Am I advocating one massive bid for a massive 8-month project? No. Never. But I have also never experienced an 8-month project that didn't have multiple delivery points along the way; multiple phases, multiple versions, multiple releases.

@housecor Minimim Viable Product isn't just for manufacturing and start-up companies. Greenfield project or Brownfield project, every large vision will have a minimum viable product. Every effort will have notable levels and achievements along the way.

@housecor What is the least amount of stuff that we can put in the release that provides value to our client and their customers? _That_ is what we estimate. _That_ is what we build. _That_ is what we invoice.

@housecor We iterate on these releases—at @aranasoft we call them Phases—trimming down each phase into its own MVP. Everything outside of the current MVP gets backlogged for a new fixed-bid later, when we are ready to build Phase 2, and can benefit from everything we learned in Phase 1.

@housecor @aranasoft The client knows exactly how long it will take. The client knows exactly how much it will cost. We have very few Change Requests because: an MVP just isn't that big; we identified this MVP up front; and nearly every change can wait until Phase Next.

@housecor @aranasoft In Agile we teach about iterations. "Ok. You want this thing. We can build that. Is it a high enough priority to abandon the entire iteration and build this thing now, or can it wait until the next iteration?"

Same concept.

@housecor @aranasoft Yes, "We favor responding to change over following a plan." But that never, never, never means "We favor responding to change; we don't even need a plan."

Before you start rowing, know where you are going, have a plan of how to get there, and make sure you even need a boat.

</>

@housecor @aranasoft PS. Bill for the deliverable. If the deliverable is time, like a mental health practitioner or a meet-and-greet at a ComicCon, then bill for the time not the job. The deliverable a thing, like building a website or sewing my arm back on, bill for the job not the time it took.