Tech Industry

The One About the Chickens and The Pigs (aka What Stand-up Is and What Stand-up Isn’t)

There’s an old adage in scrum software development about chickens and pigs at stand-up. Chickens are product managers and pigs are developers.

You don’t hear it too often anymore, probably because these days it feels a little sexist. (It’s not lost on anyone anymore how gendered the roles of product manager and developer feel in most tech companies— the product people being women and the developers being men.)

It takes a leap of faith to understand what it means, and what even is the question it’s asking anyway.

The question is fairly basic: Who participates at your morning company or engineering stand-up?

That is, I mean, really: who speaks and who does not speak. I know it sounds rigid and those of us to talk about it get called a “scrum bullwhip” (a title I proudly wear). Pigs speak at stand-up. Chickens (product managers, CEOs, and stake-holders), if they come to stand-up (and generally only product managers should) aren’t supposed to speak unless spoken to.

What? It sounds like some kind of renaissance classism like people used to say: “children shouldn’t speak until spoken to,” but to understand the chicken & pig adage is to learn something core about scrum and the stand-up meeting itself.

  • Standup is about managing the work, not the people.

What the F does this have to do with chickens and pigs, you might be asking? (I warned you it’s a long way around with this one.) Well, the idea is that we’re making breakfast. We’re all making breakfast together.

The end result is the breakfast. How we get there matters, but not everybody’s contribution is equal.

The scrum process forces the engineers to prioritize working on the very most important thing first (hopefully, the one task they have assigned to them).

Most product people, stakeholders, and CEOs being unfamiliar with the concept of “stand-up,” incorrectly assume or treat engineering stand up as a “management meeting” and think it’s their opportunity to talk or get what they want.

Sadly, this is, in fact, the opposite of scrum. Instead, scrum is about aligning your engineering efforts with your organizational-wide goals.

These days many of the millennials, born of the gadget generation, have grown in jobs where they can hide their high-functioning adult ADHD (Attention Deficit Hyperactive Disorder).

A high-performing engineering team works in total contrast to this ADHD, attention-switching, always-on-call mentality: The thing to work on is the one thing right in front of you, never anything else.

If that thing that you’re working on isn’t the most important thing, then the CEO or product owners haven’t correctly prioritized the backlog. When product people and CEOs come to scrum and participate it’s like a group of people trying to make breakfast when some other people trying to plan for lunch or dinner or tomorrow’s meals. The appropriate response you’ll get from the developers is: “Hey, back off, we’re making breakfast now, come back when we’re done and we’ll talk about lunch.”

The chickens lay eggs. The pigs are slaughtered. After breakfast is made, the chickens are still alive.

It’s a grotesque metaphor and one that can even be insulting to product people because it makes them feel like their contribution isn’t valuable. Well, that’s part of the crux of it too:

It isn’t that the product development contribution as a chicken (product owner) isn’t valuable, it’s that software development is a moving train.

As a developer, so that I can achieve flow, I should have the materials needed to do the ticket (story) I’m working on without a lot of back and forth with the stakeholder.

In fact, the correct amount of back and forth with the stakeholder is 0 (zero).

Each and every back and forth costs wait states — that is, times when the flow of the craft (that is, building the software) has to wait for someone else in the chain. If this is you then your process is most definitely held back by wait states.

What does this have to do with chickens not speaking at standup? It’s not that chickens aren’t actually supposed to literally be quiet, it means that they don’t have a turn when you go around each “giving” your stand-up.

Why don’t chickens have a turn? Because stand-up is about 1) what code we accomplished yesterday, 2) what we’re working on today, and 3) removing blockers.

The chickens don’t actually accomplish coding tasks. They contribute to the coding tasks (things like wireframes, mockups, designs, written user stories, business cases)— these are called artifacts. But these artifacts, although they can help the process, aren’t actually the finished result of working production-quality code. (Except, arguably, in the case of web designs where the designs are translated into working code.)

It’s a really old, sexist, and out-dated adage that comes from the 90s and in 2020 it’s probably insulting to most.

I haven’t yet thought of a good replacement, because the core of the adage (which I admit is kind of nonsense on many levels when you really try to lay it all out) is about the fact that the production of the code is what matters. Or, if you will, the end result (which in software development is working code.)

Scrum assumes and prioritizes high-performance engagement. At the same time, it shines a light on low-performing tools, processes, and people. It is the “sunlight” that will disinfect any broken engineering process.

It ain’t easy, and it ain’t for everyone, but when practiced right, it remains the most engaged and accelerated form of software discipline today.


TDD, Agile & Teams Videos

Teaching Functional Programming to Noobs — Rob Martin

Mob Programming, A Whole Team Approach

TDD For Those who Don’t Need it (GopherCon SG 2017)

TDD The Bad Parts — Matt Parker (Aug 2019)

Matt Parker, a Pivotal Labs developer, explores some of the downsides of test-driven development. Unmanageably large test suites, suites that don’t pass. “TDD is a means to an end.” “Go Fast Forever.” Clean code. Being slowed down by bad code.

Problem #1: The BDD proponents say “move from the outside in.” Parker argues that this is misunderstood to mean that the outside is the GUI. (He says it is not.)

Problem #2: Misapplied mocking: Everything gets mocked out. One the one hand, the tests are very fast. On the other hand, the tests are meaningless because they test implementation and not behavior.

In particular, he says people should start with SOLID principles and understand the five types of test doubles before getting too entralled with mocking, hench it will lead to over-mocking.

Problem #3: Misapplied unit testing. “Every class should be paired with a well-designed unit test.” or “Every public method should be paired with a well-designed unit test.” Problem: This creates test coupling. The tests become aware of the design pattern you are using underneath. By coupling your tests to those design patterns, you’ve made it harder to refactor away from those design patterns when the time comes. Instead, every behavior should be paired with a well-designed unit test.

My take: Parker presents some good points about the pitfalls, particularly with behavioral patterns that early developers can fall into. Most of these can be summed up as extremity positions, which is typically where developers go wrong. It’s a short and to-the-point talk worth watching but exists in the realm of ‘identify-without-solving’ in that it identifies certain bad behaviors without offering the alternatives.

The Three Laws of TDD (Featuring Kotlin) — Uncle Bob Martin

The talk in which Uncle Bob Martin pedantically pontificates on the merrits of test-first development, specifically advocating the common argument that testing first leads you to write better code.

He also pontificates on other topics too (mocking, coupling, static type checking, testing accross module boundaries), so although this is long it is worth a watch.

In the middle of the video he does the Prime factors problem, quite impressively and somewhat quickly, in fact, in Kotlin. This is something great for Kotlin enthusiasts— as well as any programmer who wants to check out this famous CS problem. (He implements it in a matter of 5 minutes and then goes on to claim he “did not have the algorithm pre-planned” comes off as disingenuous.)

ITT 2016 – Seven Ineffective Coding Habits of Many Programmers — Kevlin Henney

GPTP 2017 The Dehumanisation of Agile and Objects — James Coplien

Extreme Programming 20 Years Later — Kent Beck