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.
It will be a constant complaint that any agreements and documents shared up front won't be complete enough, or won't be accurate enough, or won't be clear enough, etc.
There will have to be alignment meetings often, and if there isn't enough CI there will be many merge conflicts.
The other side of it (not predesign) is to work on all the parts together and integrate continually/continously.
This requires constant communication - every work session is part meeting, part validation, part cocreation.
Two disasters:
* asynch work style without pre-design and alignment meetings.
* collaborative, low-predesign work without constant communication

There seems to be a balance issue here.
The more available the expert on the feature is, the less they need to pre-document and pre-split the work.
The more available team members are to each other, the less pre-design and alignment meetings they need to maintain alignment.
When people aren't available in the flow of work, the more they need a fully-competent/comprehensive document or a fully-competent/comprehensive proxy to stand in for them and answer all the questions they might have otherwise answered themselves.
In either case, though, some kind of chartering of the initiative/epic/feature is needed in order to create initial alignment. We need a shared intention if we're to make a difference: what problem it solves, what success looks like.
It can be a problem to solve and not much else, if we're all cocreating the solution. It requires communication in flow rather than a formalized and divided specification up front.
Comprehensive documentation vs collaboration, think of it as a slider: you have to find the right level, because wherever you put that slider determines how your team works and which set of risks and failure modes are constantly in their way.
If you set it according to how your team currently works, you're ensuring that they work that way.

It's a driver as much as an accommodation.

If you move it, the team moves accordingly.
Waterfall skewed (necessarily) toward pre-worked, comprehensively documented/contracted solutions, and individual work assignments.

Agile skews toward robust communication, feedback, co-creation, and evolutionary design rather than upfront planning.
ISTM that middle ground would have to be light up-front agreements + evolutionary groupwork. Charter and swarm?

• • •

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

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
Dec 29, 2021
Readability is a relationship between an artifact and an audience, and we all know that. It's not just the artifact, but here is a funky example.
I got a great new overdrive pedal for Christmas. It looks like this:
The weird bit is that usually the bass/treble EQ controls are together, and the volume/gain controls are together.
This time they're not and that was confusing to me.
Why such a weird order?
Read 11 tweets
Dec 29, 2021
so, OO, right?
What people are doing with Java typically is nothing like OO.
Imagine you're creating your own language specific to your problem domain and solution domain.
That's a beginning.
A language in which you can solve your problems in your domain and stack.
It doesn't exist, btw. Java, JS, Python, C#, Smalltalk -- they're not it. They're the language you build your language in. You don't implement the solution in Java. You implement your solution in the language you've built in Java.
The problem is that you have two locations in space, a bunch of roads, and you want to route a path from one place to the other.
Don't do that in ints, strings, functions, and doubles.
Do it in places, paths, and routes.
Read 9 tweets
Dec 27, 2021
The American superhighway system: 🧵
In other countries where you drive on the left, the rule is "say left except to pass" and this works. In the US (where we drive on the right) we don't do that. Cars are in all the lanes. There IS a system though.
The far-right lane (remember we drive on the right) is the "ramp lane." People are always slowing to get off the highway, or coming on slow and speeding up.
You'll be always accelerating/decelerating there, so don't drive this one. Go left.
Read 10 tweets
Dec 22, 2021
Including delivery/deployment in the definition of done I'm told is unfair because teams aren't in control of what gets delivered or when.
🧵
"Their work might be completed, but be only a fraction of some larger scatter-gathered effort, so it's not their fault."
"They may be dependent on work from another group, say FE or BE or database, or something, so it's not their fault the work isn't done."
Read 16 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!

:(