Tweet

Agile Otter Tim

10 Aug, 7 tweets, 2 min read

Why don't you have tests?
Why don't you refactor?
Why is the code so bad?
Why can't we be responsive?
Why are we slowing down so much, so fast?

The problem with sprint packing (maximum amount of work per time box) is that people have to cut corners (including quality, design, testing) to make a tight deadline -- only to be given one equally tight or tighter.

Ad infinitum.

The kind of "go faster" that teams do to keep up with the work is like the driver ignoring warning lights, not getting tires changed, not washing the outside or throwing away trash.

It's an ugliness that piles up because there isn't time for caretaking.

It's because sprint packing is backward, misguided, foolish.
If we want more done, we don't get that by multiplying the effort required. That trick doesn't work for long and backlashes.

Instead, we increase the efficiency and capability of the team (not the headcount) and focus on making the work easier to accomplish, so that we can do more in a shorter time.

Then we put in the work that fills (some of) the time earned back by being efficient.

I hope that makes sense:

A: Pile on more work that the team can't complete and count on them to redouble their efforts without changing anything.

B: Focus on doing work well and easily, and use the time freed by their new efficiency to do more work.

Which?

Why bring this up? Yet another cohort has informed me that the reason they're not learning and improving at work is because
* They don't have time for it
* The business doesn't value improvement
* It looks bad to be seen learning at work

• • •

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

@tottinge

12 Jan

People often treat standardization as a self-evident good.
They want everyone to do everything the same way so it will be standard.
A short thread is in order here.

The primary reason we standardize things is for interoperability.

If we're not going to interoperate, then there's no point in standardizing.

If we ARE going to interoperate, then we need standard *interfaces* not standard everything.

This suggests that we don't need everyone on every team to work the same way, or for teams to operate (internally) the same way other teams interoperate.

Read 12 tweets

Agile Otter Tim

@tottinge

8 Dec 20

The most brilliant programmers alive working competitively in an ego-rich environment can’t get as much done as ordinary programmers working cooperatively as a self disciplined and self-organizing team. You need a process where team empowerment and collaboration thrive.

I'm very sorry that this quote didn't show up with quotations and a link. It should have. I'm not sure where it came from now.

This saddens me. I hope it's not lost.

agile-process.org
Don Wells

Read 4 tweets

Agile Otter Tim

@tottinge

3 Dec 20

You know what I don't do as a developer?
Memorize a big codebase.
I used to try, but then found I couldn't do it.
As a result, I have to make it scannable, discoverable, readable.

This has an unexpected benefit.

As it turns out, human memory is not a shared resource. There is an advantage to the person who knows how it all works, provided nothing changes (much).

But nobody else owns your memory, and it leaves with you.

I later found out that my "inability" to memorize a big code base is the reason people appreciated my code and found it useful and maintainable.

I didn't really do it for them at first, but as a survival tactic in a world where a lot of people had better memories than me.

Read 8 tweets

Agile Otter Tim

@tottinge

29 Sep 20

One of the standard issues with going to swarming or mob programming is always "How will we spot the bad programmers then? How will we catch the people who are loafing? How will we spot underskilled people if they don't do individual work?"

I went as far as to add it to my slide deck when I am teaching whole-team structures. It is going to come up anyway, and people are usually glad it's already in the topics list.

Of course, the first thing I say is "I don't know. I've not seen it yet. Swarms seem to keep everyone involved and interested pretty much all the time." This is true. It's hard for people to believe.

Read 11 tweets

Agile Otter Tim

@tottinge

4 Sep 20

We are once again offering the Technical Excellence Workshop as an open-enrollment experience this October.

It's an 8-week experience where we spend a few hours a week together, and we explore technical skills, perspectives, safety, behavioral skills, & leadership.

There is access to expert eLearning and there are exercises to perform during the week (some canned exercises, some live exploration) that will change how you look at your work and your organization.

Students from prior iterations have said that they had better interactions with their teams in the first week. Some claim that it made them better programmers. They have been able to initiate continuous improvement in their organizations.

Others learned to explain and teach.

Read 5 tweets