I can estimate how long it will take me to drive to Des Moines, and be "close enough." There are lights, stops, traffic, weather to consider, but mostly it's me choosing route and rate.
Route has speed limits, traffic features, raw distance. Those are not up to me, really. I have limits, but the limits make the trip predictable.
The fewer items are under my control, the less likely the estimation.

Can I get to des moines in 3 hours? Probably, if you provide me a fast plane or fast helicopter and clear weather. Otherwise, no.
Now, how long will it take me to learn to dance ballet?
Learn music theory?
Or to come up with a diet that totally works for you to reach your ideal weight?
I've no idea. I don't know how readily I will learn what I need to know and develop what I need to develop along the path.
I don't know if I'm even capable of these things, and will have to wade in to find out. If I have to know before starting, I'll never start. I can't know.
Can I be a professional ballet dancer in a year? Probably not. Who knows?
Within a decade? Probably not, who knows?
Within a lifetime? Probably not.
Heck, I don't know how to play baseball or basketball. What do I know of acquiring physical grace?
"How long will it take you to do a thing you don't know how to do and have never done before, and for which you will have to acquire knowledge and skill along the way?" is a inherently non-estimable situation.
Somewhere inside that range is a software skill. I know a number of things, but not all the things. I'll have to learn about domain, tech stack, deployment, maintenance, etc. A lot of things are _not_ up to me, and some are. Is it semi-estimable?
Will I get it done faster by NOT getting the knowledge and skill that the work really requires, or by diving in and getting all the knowledge and skill that the work seems like it might need?
Is muddling through going to get a faster, safer, better result than developing expertise? Is it a sweeping difference or a marginal one?
How much does the choice to muddle, pre-skill, or JIT sklll affect the task? Can I know it?

Back to helicopter and fast planes: what would be the circumstance at which this could be done more quickly, the enablers and support needed?
Skilled partners who can act as sounding boards and mentors? An appropriate, well-selected framework? The right reading material and videos? Some kind of sandbox where I can try things and make mistakes freely?
Ah. If we work together and share skills, then the work becomes *more* estimable (or less inestimable).
If it becomes more predictable, and predictability is important, then working alone and muddling through (or preskilling for anything that may possibly arise) are both losing strategies.

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with "Agile Otter" Tim Ottinger

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @tottinge

Feb 18
"Ability To Do Work" is so ignored by many contemporaries. It's easier to assume that one person is pretty much the same as another, on average, and that work is done by individuals.
This way the math works out for linear gains from adding headcount.
"Capacity" has become a euphemism for headcount.
The "on average, a programmer is a programmer, a QA is just another QA" is not only wrong about individuals, it's dreadfully wrong about teams.
For people to be great soloists with equal capacity in solo work, each person has to have the same set of skills, habits, approaches, talents, knowledge as every other person. We know that isn't so. It will never be so.
Read 12 tweets
Feb 15
Don't say "capacity" when you mean "headcount"

A team's /capacity/ is how much they're capable of doing together.

Pretending they're equivalent is (foolishly) pretending that programming is mostly typing.
Capacity is the right idea, though.
What can you do to increase the ability to do work other than bumping up the number of developers.
But likely you can improve skills and focus and tooling and raise capacity, remove waits and queues and returns.
Your capacity isn't headcount.
BTW: if you're doing Angular but nobody really understands Angular, then maybe adding an Angular expert to the team will increase capacity. It's SKILL and FOCUS after all.
If you have individual assignments it won't help much, though.
Read 4 tweets
Feb 14
@eikonne I also find the pair-programming he’s referring to to be suboptimal.
For me to type all day while you criticize, or for me to criticize all day while you type (worker/watcher or worker/critique) is indeed a very dull and wasteful thing.

Pair Programming, on the other hand…
@eikonne … actual pair programming by co-creating code, switching roles frequently, switching partners a few times a day, is not only an excellent pedagogical tool but a great way to do work.
It also means you don’t break tasks down to individual skills, but work more whole features.
@eikonne I think that this is a classic (AKA "normal") case of confusing the antipatterns for the thing.

"Doing dishes sucks: all that food floating in dishwater"
"Dude, that's wrong. You're supposed to scrape and rinse them first."
"Oh, you purists and your No True Scotsman fallacy!"
Read 7 tweets
Feb 6
If you were born into tech in a modern corporation, you might think that “agile” is an estimation technique based on repetition and practice, or perhaps a workforce performance management system based on constant checkpoints.
Would they know it was about making software better?

Would they recognize the goals of healing the mgmt/dev divide, working within capacity, delivering early & often?

Would they recognize autonomous, cross-functional, self-managing teams as a bedrock concept?
If I were to transplant the original Agile Manifesto signers from 2001 into your shop on Monday, would they recognize anything of their work or intentions?
Read 4 tweets
Feb 4
The most difficult of all simple ideas to internalize is probably this: To be done sooner, do less.
This is true in the large and in the small.

Small: If I use the "rename" refactor, it changes all the references as I type the new name. If I don't, I have to carefully walk the code base, changing the name (spelling it correctly) every place.
Large: if we make a single-feature release, we can have it out in a few days. If we slice the feature e2e, it can be several releases a day for a few days.
Read 4 tweets
Feb 2
We assume that “Engineering == Production Engineering” and so we, as an industry, made the billion dollar mistake of attempting to improve the efficiency of software development by applying production-line techniques.
I need to apologize to everyone. I used a tool to post this and it makes it look like this is my own work. That's not the case, and I never meant it to be intellectually dishonest.

I thought it would be posted with the article link.

So: this isn't my words, but I admire them.
I will post the article link when I find it again.
Apologies to whomever's work I quoted accidentally without citation.
If that's you, please remind me of the link.
I feel awful about this.
Read 4 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!

:(