Tweet

"Agile Otter" Tim Ottinger

Jul 25 • 8 tweets • 2 min read

It was a lot, this #agile2022. There are people I would have liked to visit that I saw only in passing. I spent a lot of time in the company of people, and made new friends as well as hanging with long-established friends.

Overall, it was more people than I'm used to. I was rather exhausted as I'm not used to maintaining my energy. Being an introvert in a huge crowd takes some opportunism.

At least a few times last week, we pulled back the curtain a little too soon; we showed agility that people weren't ready to see.
People work hard building process, discipline, and clarity; much of that eventually can become cruft that teamwork sweeps away.

Going from "whatever came before" to a more carefully planned "agile" way of working can give benefits, and I won't argue against 5-step user story definition processes generally.
But if you're working in ensembles, that level of formality slows down the progress.

I'm sorry that it was hard to hear sometimes, and it's easy to dismiss as "poisoning the future" by "eliminating all discipline" but that's not what it is. That's what it sounds like, but in reality it's "continuous everything" -- which is hard to imagine.

If the people who would define and "pre-chew" the work are in the team, then you don't need it pre-chewed. You all can dig in together. If the approvers are in the team, you code it in an approved way.
I know this is hard to imagine, but it's powerful stuff.

If you need a user journey map and a story map and an example map and, and, and, and...

Well, these can be done just-in-time for the most part.

And, yes, you may find you don't need stories, story points, estimates, assignments, approvals, etc.

SO MUCH (too much) of modern org processes are built to cope with and survive people coding solo in silos with the limited information a person has in their head. A lot of pre-and post-work is necessary there.

Ensemble work doesn't NEED that.

• • •

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

This Thread may be Removed Anytime!

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

More from @tottinge

"Agile Otter" Tim Ottinger

@tottinge

Jul 7

So "The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization."

So....

If you find a scrum team that isn't self-managing or self-organizing, I guess that the team is either still in the course of an ongoing transition or the SM is committing malpractice?

And "The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices."

So... it's not scrum.

Read 7 tweets

"Agile Otter" Tim Ottinger

@tottinge

Jul 7

Nobody knows the whole system, nobody knows the whole stack, nobody knows the entire standard library for each of their *favorite* languages, nor the whole product community.

You need some advantages here...

When all you have is one head, you need to augment your intelligence as much as you can. Keep browsers open, sure, and look things up quickly, but also checkers, linters, security scanners, syntax highlighting, formatters all IN THE IDE so they're active WHILE YOU CODE!

You need to be able to look things up. If you feel guilty for every second you're not hammering code into that source file, you're not going to do enough research.
If you're happy going down every rabbit hole, you're never going to get that code written.
BALANCE.

Read 9 tweets

"Agile Otter" Tim Ottinger

@tottinge

May 18

Divide And Conquer never (outside of certain software teams) meant “let’s split up and go it alone.’ That’s like a bad horror movie strategy.

You divide the enemy/problem into small parts that you can more easily defeat, not yourselves.

The force that is divided is conquered.

This whole “let’s divide our forces so that we can be more easily defeated” idea is really quite daft. We don’t defeat the enemy by splitting up and going it alone.

If you have a big problem, divide the problem, not yourselves.
Your power is in combining your strengths.

Why do people get this backward?
And why do they get this backward all the time?
Who told them that “divide and conquer” worked that way?

Sigh.
This industry is keen to go hard on their misunderstandings of things, and to double down on them.

Read 4 tweets

"Agile Otter" Tim Ottinger

@tottinge

May 17

You have a program you have to use every day. It has 48 fields on one screen, and an "okay" button at the bottom.
What you get depends on which fields you fill in... 1/

If you fill in fields 1-4, 12, 32, and 48 (you may have to scroll a bit) then it will create a new account, but don't touch fields other than those or it will attempt to either update or delete the account listed in field 32. 2/

If you want to add a feature to the account, don't touch field 3 or it will fail outright without an error message.

Enter fields 1, and 5-8 if you want to transfer ownership of the account. Don't touch any of the other fields or it may transfer to a random account. 3/

Read 7 tweets

"Agile Otter" Tim Ottinger

@tottinge

May 16

I recall once when we built a huge distributed realtime system, and the client called in an analyst to perform a function point analysis.
The analyst said that there were only a dozen or so screens, & a handful of reports: the system should have taken a few weeks to build.

Teammates said "dude! The screens and reports are the *least* part of what we've done. This isn't a store-and-report business system! It is a distributed control system!

The analyst wrote a one-sentence statement "this is a control system, so FP may not tell the whole story."

So the report that was delivered said over 20 pages that it should have only taken a few weeks, with one sentence saying that that it "may not" be the whole story.

Read 5 tweets