Sep 27, 2018 15 tweets 3 min read Read on X
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

Sep 24, 2018
Self-care thought for the day: I can't be there for you if I'm not there.
I can't be a voice of reason if I'm unreasonable.
Can't show love, curiosity, openness, kindness if I don't have it in me.
That said, what I have, I can share.
Read 4 tweets
Sep 21, 2018
Often businesses run fast, in the unsafe fast quadrant of the graph. They end up so hampered by low quality that they are dragged into unsafe slow.
We refer to the unsafe-slow quadrant as "hell" - no matter how fast you try to go, things go wrong and you end up fixing and reacting to crises. And of course you get there through good intentions.
Sadly there is no easy trip from unsafe-slow or unsafe-fast to safe-fast.
Read 21 tweets
Aug 22, 2018
"If one of us is remote, we all work as if remote" is questionable. While it creates empathy/sympathy and urge to fix remoting problems, if one of us broke her wrist we wouldn't all type with non-dominant hand for 6 weeks.
Not reducing the value of empathy, but when I'm remote I accept that it is not as good a group experience and don't want everyone to give up their advantages. My choice to work as a remote shouldn't hobble everyone else.
If one of us is unfamiliar with the coding language, should we all write amateur-level code? If I become hard of hearing should you all wear earplugs to work?
Read 7 tweets
Jul 26, 2018
In the early 90s, a coworker named Dan conscientiously told us that he would be happy to help us with "our" work, but only after he finished "his work" because he won't put his reputation at risk for us.
At the time, I was working with almost everyone else on the team on "their" work while trying to finish "my" work. It was before we understood teaming, when everyone thought in "individual contributor" terms, but I had already been on two excellent real teams.
Dan wasn't *wrong*, and I wasn't *right*. We were operating from different systems and mindsets. Dan had a reason to work hard to prove his competence due to a diversity issue in the org, and he was playing the hand he was dealt masterfully.
Read 6 tweets
Jul 24, 2018
there is this idea floating about inverting business, to wit:

* There are people in your org who materially participate in delivery of goods/services/etc
* Then there are supportive functions provided as a service to material participants
* Then there is dead wood
It's interesting. It suggests that the people building, designing, and selling your cars are "the real business," managers and purchasing and HR and finance are supporting the primary functions, and anyone not supporting design/build/deliver are basically waste.
Likewise you would have software development, testing, delivery, operation, sales, and service in a software house as primary functions. Those who "give them the environment and support they need" are supportive, anything else may be waste.
Read 9 tweets
Jul 20, 2018
Simplification has a rule:
1) Make the thing unnecessary
2) Then get rid of it.

Don't throw away the crutch while you're leaning on it.
This has relevance to every #No<thing> hashtag. If you reduce or eliminate a need, you can reduce or eliminate a practice or role.
Maintaining unneeded practices and roles is waste.
Anytime you recognize that you're not leaning on the crutch, it might be time for step 2
Read 5 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!

:(