@johncutlefish
The more consistent one's experiences, the more one believes they understand "the real world."
The more insular one's experiences, the more consistent.
"Real world" is merely a descriptive term people use for the stories they tell themselves about their own experiences.
Just for the record:
* Agile doesn't require you to do sprints.
* agile doesn't require you to have a Product Owner
* agile doesn't require a scrum master
* agile doesn't require a backlog
* agile doesn't require estimates
Scrum might, but scrum is to agile as beagle is to dog.
For the next week or two, let’s do an experiment.
Whenever someone says “story point” or “velocity,” quietly in your own head translate it to “made up numbers.”
“I’ve noticed your made up numbers have dipped.”
“We need to raise our made up numbers.”
Mmmmhmmm.
Stop being the best developer on your team.
Just effing stop it. Today. If you’re “the best one”. Get out of your own way. You are stinking up the whole industry.
Instead, start being the reason everyone on your team is so great, acts so wisely, understands so much.
A: How long is a story point in real time?
B: How many did you do in your last sprint?
A: 23
B: Then, for you, it's a 23rd of a sprint
A: But the time before that it was 19
B: Then for you at the time it was 1/19th of a sprint.
A: But how long is it really?
B: We answered that.
A manager I know declared victory when he got the team to reduce the estimates from 3 months to 5 weeks. He was not as elated when it ran over, taking just over 3 months.
Moral: Getting a team to "commit" to a smaller estimate doesn't change the amount of work that must be done
The agile manifesto starts "We are uncovering better ways of developing software by doing it and helping others do it."
From the first sentence, it is a community on a constant search.
It's not a framework, method, or set of formalities.
It's an ONGOING SEARCH via PRACTICE.
There are a few pervasive fallacies that make software hard:
1. We need accurate, precise estimates
2. Low output is motivation-based
3. We need to get more work started
4. Throughput comes from isolated individual coders
5. We need to program faster
Once upon a time people argued that TDD is impossible.
You can't write a test first, obviously, because you can't test something that doesn't exist. It's obviously ludicrous.
But you change how you think about "a test" and it works just fine.
“I wouldn’t change the code just to make it easier to test” is a strange statement. “Just”?
Testability is a first-order concern.
It’s as important as making it run.
There’s no “just” there.
I don't like the whole Pull Request (PR) process. I think it's great for open-source projects, but not for corporations.
<deep breath>
There. I said it in public. It felt like a dirty secret until now.
I didn’t think this was going to be controversial the first time I said it, and I was wrong. So, let’s try it again here:
There is no need to have a morning “report your ticket numbers so we can update Jira” meeting.
There are better uses of your morning time than this.
I worked with a team for a few weeks.
People built using TDD or very tight test-after.
It was all trunk-based with continuous deployment.
They formed up squads/swarms/groups as needed to get work done.
They turned around improvements in a day usually.
1/
The hardest discipline for a software organization is generally this (tremendously hard) thing:
* Finish the thing you're doing before starting a new thing.
In Jira, a story can have only one developer.
In Jekyll, a blog post can have only one author.
Is there some weird societal blindspot that people have no idea of teamwork, partnership, and cocreation?
A: My teams don’t get all their work done every week.
B: Then it’s too much work.
A: I don’t think it’s too much work.
B: If they don’t finish it, then it’s too much.
A: I think they can do more.
B: What difference does that make?
I once worked with an org where a PM lamented about two things:
1) The team "misses their estimates" and "comes in late"
2) They are too conservative, and the PM would like to see more aggressive estimates.
The absurdity of having both complaints simultaneously was lost on them.
That brand of “agile” that is rooted in story points, timeboxes, epics, and individual assignments? It is like someone went through Agile’s trash can.
It is agile derived, as a junkyard is to a factory.
It isn’t the thing, it is the leftover artifacts only.
"Pair programming is two people doin the job of one; it is inefficient."
Look, the only reason you think the work they're doing is a one person job is because you like to assign it to one person. You've had individuals doing 2-to-7-person-jobs for years.
A: So how can we get the developers to work harder?
B: Take away their tools. Add more bureaucracy. Use slow computers and dead programming languages.
A: And that will bring up the velocity?
B: No. You asked how to make their work harder.
Perhaps the way many programmers like to think is too fragile to survive in a modern corporate context, where interruptions and interactions are common.
Let alone in Agile work where interactions are primary features.
How would you fix software thinking to be more robust?
It may be hard to believe, but most people simply don't know how to break work down for delivery.
They only break it down for development, so it can be assigned to different people.
This is the root of much dysfunction.
Your software delivery system isn’t just programming.
Often a 2-hour change takes weeks to make it to production.
If you could make the programmer go 2x as fast with no mistakes (so unlikely!) it would save one hour, not one week.
Where is the slowness, really?
People confuse assignment of tasks with planning.
The point of planning is to ensure we are progressing intelligently and transparently toward our goal, yes?
As opposed to making sure everyone has plenty of work to do?
It’s confusing to me to meet people who have entered the software world as agile coaches. It seems weird that someone is coaching but has never served on an agile team in any capacity and has never observed people doing the work before.
Can you help me understand?
As a person who's been in the Agile thing for a very long time, and who has taught/coached/transitioned many, and who is fairly well acknowledged as an expert, I want to confess:
Half the time when someone says "agile" I've no effing idea what they think it means.
People who don't understand incremental work think it means to serve raw chicken, then undercooked chicken, then the finished chicken.
That's not how it works.
You deliver a small amount of fully-cooked chicken right away, then adjust the recipe, deliver more fully-cooked.
Agile reminder for Wednesday:
Working Software is the Primary Measure of Progress
(for software projects).
Not estimates, not schedules, not % done in a ticket.
None, Some, or All of it works.
It's harsh, but it's right.
Speaker at a conference talked about how men in their mid-50s are not interested in new stuff; they’re just counting days until retirement.
Dear speaker: I’m keen AF, and changing the world still.
A prime reason people don't collaborate, refactor, or test is because they don't know how. A prime reason that they resist learning is because it requires them to admit not knowing. To be seen as non-expert is not affordable when your environment has more threat than safety.
There is this idea... I don't know who started it... that if you write code "the right way to begin with" that you'll never "have to" change it.
It's one of the most ridiculous ideas on software development, and the root of many dysfunctions.
Most people in software say "complex" but really mean "unfamiliar." Being hard to understand doesn't mean it's "complex" -- it may be only complicated, or it may be unexpectedly simple.
I try to say "unfamiliar" when I mean that.
“How long does a 2-point story usually take?”
“We peg story points to half-days so 2 points is one day.”
“Yes, how long does a 2-point story usually take?”
“One day.”
“Historically, or ideally?”
“One day.”
“Most of the features you released are over 40 days old.”
“But, um….”
“How can we go agile?”
“First, value individuals and interactions over processes and tools.”
“GREAT! Let’s install the process and a set of tools to enforce that process.”
“Wait... what about the individuals ...?”
“You’re right. Any people who resist, fire them.”
#notMyAgile
5-Whys meeting: the idea is not "why did you do this wrong" but "what made this seem like the right thing to do at the time to a reasonable and intelligent person in the situation?" -- Hard on systems. Soft on people.
Deadlines looming!
If you're 80% done with 100% of the features, you are screwed. You can't ship; maybe can't compile!
If, however, you are 100% done with 80% of the features, you have a qualified success on your hands. You can ship it!
Every single agile failure I've seen has been of the same kind: don't establish atomic, autonomous, self-organizing teams; do solo assignments in a two-week treadmill, and push for more ticket-closing constantly.
It's miserable and fails.
You know what I don’t like about my job?
When people expect/demand advocacy — that I should *convince* people to do things my way.
I’m not here to convince you against your will.
If you’re curious, I’ll show you. I’ll say why I do it.
You decide.
I'm often amazed that people would rather spend 20 minutes in a debugger than 3 minutes writing a test, and will refer to the preference as "more efficient."
Is it odd that EVERY principle and value of the Agile Manifesto and EVERY practice in XP is still controversial and shocking to the majority of companies and programmers?
Maybe the agile that has spread is a gentrified version that doesn’t have radical agile ideas in it.
Oh for Pete's sake, people.
We didn't stop doing Big Design Up Front (BDUF) because it is waterfall. We stopped doing it because it doesn't work well most of the time.
“I'm adding a new feature, and I see that the existing code is not structured in such a way that makes adding the feature easy. So first I refactor the code”
"I wrote this code in one day!"
"But you debugged it for 3, and it's come back from QA a couple of times, and it didn't pass code review."
"Sure, but I got it done in one day!"
"But it.."
"I got it done fast!"
Sometimes 'done' is a word rather casually used.
This is the least effective and rational personal software process I know:
1) Write all the code
2) Make it run
3) Hand-test it some, until you're confident
4) Write some automated tests
5) Have other people find bugs
Some people don't know any better.
HELP THEM.
@penelopew_
@GBGames
@ldrinkh20
Are you really going to float that ungrounded theory here?
I wouldn't bank on getting many followers that way.
;-)
ps: well played.
“We keep pushing the developers but it never helps!”
If, in your value stream map, actual coding is only 5% of the time, then you can only expect 1% or (rather unlikely) 2% improvement by speeding up the programmers.
See where the time really goes. It’s likely queues.
We have two big problems with our developers
1. They keep making their estimates too long: they aren't ambitious enough and we have to talk them into shorter number.
2. They never come in within the estimated time.
"I need to know that everyone is busy"
"Why?"
"Because they're paid to be busy."
"Okay. EVERYBODY! FOLD AND DECORATE 10000 PAPER AIRPLANES!"
"No! Wait? Why would you do that?"
"It will keep everybody busy all day."
"But..."
the most important things you can do with cards:
1) Delete them (throw them away)
2) Split them
3) Work on them together
Do you know how many ALM tools don't allow these three things?
The tools are supposed to work FOR us, we don't work for the tools.
Let's delete bad tools.
What is Unteaming?
That's where each person on a team is given a different thing to for them all to work on at the same time, so that they can't possibly collaborate.
Today I was once again told that estimates and sprints are the core components of Agile.
It is so very wrong to be so oft-repeated. Sometimes your local pundit doesn't know jack about agility.
Are you ready to quit estimating in story points as fibonacci numbers or powers of two and start estimating in dice?
This problem looks like about 3d6 of half-days.
Common misunderstanding: the agile methods grew out of the agile manifesto.
The opposite is true. The manifesto was written by people practicing the methods for years prior.
XP and scrum were known and used before 1996, for 2 examples.
Most disturbing mistaken belief about agile?
That it is predicated on having accurate estimates and assigning the maximum achievable load on each person in the team.
It's not even close. It's kind of the opposite.
But people think this is the ideal somehow?
I weep inside.
If your developers are kept busy with individual assignments, don't be surprised that the developers' personal workload takes priority over the needs of the team.
Nor should you be surprised that the team is not responsive to the needs of the broader organization.
Oooo....
Though I think that this applies to radical candor too.
Often people mistake psychological safety not so much as "impunity" but as "extreme restriction of expression" -- which it also is not.
Most people don't realize Psych Safety and Radical Candor are the same idea.
“Common sense” is a myth. Every time someone says “common sense” they mean “the set of things I already know, and have known for some time.”
It is 100% tied to your personal story.
It’s not “common.” Don’t blame someone for not being inside your headspace and experience.
To throw one more fallacy on the bonfire: CI is not the practice of running a building test server. It is the behavior of developers sharing all their code changes frequently, at LEAST once a day.
A: Why do you use a ticket tracker?
B: We have thousands of backlog entries.
A: wait... what? Why? How does that help?
B: If we don't store them, we may forget.
Periodic reminder:
The human being is not the bottleneck. This thinking creates blame and problems.
The human being is AT the bottleneck. This understanding opens up options for empathy, remedy, and improvement.
In organization, trust is expressed in autonomy.
Where autonomy is low, you can bet it is because trust is
low.
Where autonomy is high, you can bet it is because trust is high.
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.
If I say “TDD” and what you hear is either “unit testing” or “test coverage” then you aren’t hearing me and I need to find a new way to communicate with you.
When I say “TDD” I don’t mean ‘unit testing’ and/or ‘test coverage.’ How can I say it differently?
I don' t understand how people think they can do CI and CD without doing TDD/BDD/etc.
It seems that continuously integrating code that might have significant unrecognized defects is sketchy. To deploy that, doubly so.
So, your kanban has a horizontal lane per person?
How are people supposed to pair, mob, work consistently, avoid silos, kill queuing, lower WIP, and improve lead time if they are all doing "their own work"?
What is the point?