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?
This is not “look how you suck” but a request that you look at what your “agile” is like: where do you spend your time and energy? Is it in cross-functional, atomic, autonomous teams producing working software early and often to satisfy your product community?

• • •

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 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
Feb 2
In a crisis, people pull together and work together.
They share information, volunteer their skills and expertise, shoulder the burden for each other because of the shared stress.
When it's over, they go back to the pre-stress style: solo, disconnected, competitive even.
In the various early agile teams, there seemed to be this idea of working they way we work when we're in a stressful crisis, but without any of the stress, threat, or crisis.
We work productively and voluntarily when things go wrong, couldn't we work similarly without panic?
What keeps people from happily and joyfully working together in community when nothing bad is happening, when they're not under stress, not burdened with dire consequences, just because they like to?
Read 6 tweets
Jan 31
There is this legitimate, real tension between planning and action, between BDUF and winging it (in extreme cases), between roadmaps and evolution.

I don't think it's "enlightened people vs dumb clods"
If people don't agree on what they're doing together, then they tend to not have a solid, cohesive collaboration.

When is this agreement reached?
Let's assume that there is a problem big enough for many people to work on it.

For them to work independently async, they need to have a very solid agreement up-front so that they don't work at cross-purposes.
Read 14 tweets
Jan 4
A little lesson on testing.

I got my new UPS today. I intend for it to supply my internet gear (modem, router, mesh, storage).
I plugged it into the wall, plugged everything in.

Note: this could have been planned better - some of my cables are too short so I need a higher shelf for the unit, but we worked through that.

Everything is working okay... or so it seems.
Plugging every item in one at a time helped me ensure I have all the right cords to the right things. This is rather like industriallogic.com/blog/test-driv…
Read 13 tweets
Jan 3
This is such a simple idea. People often want to break up the three things, though.
#objectoriented @IndustrialLogic
The name is key here. What is this object for? Why would anyone look for it, or use it? When I'm programming, and I need a skiplist where can I find it, and what is it called there? What if it's not called skiplist?
Sometimes this is simple, like python 'datetime' contains 'date', 'time' 'datetime', 'timedelta', and more.

The name 'date' is scoped, so the name is really 'datetime.date' which is important to realize.
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!

:(