The single practice that is mandated is: “the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” We are constantly improving how we work (uncovering), which, to me, suggests that we add, remove, and change things, and we make those changes based on observation and assessment.

This attitude is particularly important when a radical new tool, such as an LLM, emerges. We improve “by doing it.” We use the new thing, then decide based on our experience. We don’t just sit back and say it doesn’t work because it’s not what we’re doing now, or because some moron has hyped it too much. Agility is scary. It requires constant personal experimentation with new ways of working. Some of those things work, some don’t, but you don’t know until you try.

The next important word is “ways,” plural. I’ve never seen any good come from everyone marching in lockstep to a specific process or framework. At best, that uniformity adds friction. At worst, it adds dysfunction. Every team, every story, every situation, is unique and requires unique ways of working. Create a set of values and principles, and as long as people adhere to those, you’re golden. The people who do the work are in the best position to figure out how to do the work. Of course, control-obsessed people high up in an organization hate that because they can’t control it. They call it “chaos.” Replacing control for trust is an essential element of becoming “Agile,” however.

Finally, the end of that initial sentence is “…and helping others do it.” We improve as a community through collaboration and communication. That can be fraught. E.g., the #NoEstimates tag began when Woody Zuill posted that his team had just finished a successful project without estimates and wanted to share their experience. Instead of “that’s interesting, tell me more,” the reactions were often hateful attacks that came down to “It’s not possible to work without estimates, so you’re an incompetent, irresponsible liar.” But it is possible. It did work. That was the whole point. Working is the starting point of the discussion. Your comments don’t hold much weight unless you’ve tried it. If you don’t know how to try it, talk to the people who have. Conversation and experimentation fill in the details. That’s how you learn and improve. That’s Agile.

Deming once said, “You can measure only 3% of what matters,” and this is one of those cases. All the “productivity” metrics I see measure output. You are not productive if you produce vast amounts of garbage quickly (PRs/unit time come to mind). Even “_value_ delivered over time” isn’t measurable, because you can’t measure value. Productivity matters. You can’t measure it, however.

Sometimes, a group of metrics taken together can help. The DORA metrics (deployment frequency, lead time, change-failure rate, and mean time to restore) taken together come to mind. None of these, in isolation, does anything useful. A team with a high deployment rate is productive only if it also has a low failure rate, etc. It’s all or nothing.

But even taken together, DORA metrics are not sufficient because they’re still output measures. Take lead time: the time from when a problem is identified to when the solution generates revenue. (Idea to the customer’s hands.) Some problems are just harder than others, so they take longer to solve. That extra time doesn’t mean you’re less productive, however. A simple lead-time comparison tells you nothing useful.

People talk about how AI assistance makes them more productive, but that’s particularly fraught because the “out of the box” code always needs to be inspected and refactored. People who check in unreviewed code are actually anti-productive because someone down the line will have to deal with the problems in that code. AI-generated code is also overcomplex, and if somebody doesn’t deal with that complexity, it will kill you down the line. I’m not saying that using AI is not a good thing. It does make people more productive. Just not in an easily measured way, and only if the programmers approach the generated code with scepticism.

Deming also said, “It is wrong to suppose that if you can’t measure it, you can’t manage it – a costly myth.” You can’t measure productivity, but you _can_ manage it. The best indicator I can think of is how long it takes to make a necessary change and how solid that change is (solid code stands up over time). “Solid” applies to everything from code quality to whether your solution to a customer problem is a good one.

When the change time is low, productivity is high. If the code isn’t solid, the constant fiddling with it lowers my productivity. We’ve all experienced code that’s hellish to work on, where a change that should take a few hours takes weeks. When I work in code like that, I’m not productive (and very unhappy). This is a relative measure. Some things—some changes—are just inherently difficult, so take longer than others.

So, even if I can’t measure my productivity, I can manage it by looking for things that slow down change and eliminating those things. There are many specific things that slow me down. Wrestling with bugs. Dealing with unnecessary complexity. Inappropriate or bad architecture. Bad overall code structure. Unhelpful names. Low quality in general. Code that doesn’t make what it does obvious when reading it. The list goes on. By dealing with those things, we become more productive. If you want to measure something, measure how many of those issues you address.

A Buddhist monk (yes, seriously) once told me that suffering is the distance between the way things are and the way we think they should be. Productivity works the same way. The smaller the gap, the more productive we are. Productivity is a relative delta, not a hard number. Narrowing that gap reduces our suffering 😄.

Don’t get me wrong, the world does have a use for a degree that focuses on the mathematics that underlies computing, algorithm design and analysis, NP completeness, and the other things that go into a Computer Science degree, but that stuff has little or nothing to do with the production of software. Put another way, computer science is to software development what materials science is to architecture. The connection is tenuous, and a degree in the first does not prepare you for a job in the second.

In the current job climate, the CS curriculum is a tragedy. Learning software engineering on the job to make up for educational deficiencies is a luxury that requires a strong economy and companies with money to burn. We don't have that. Sure, a university is not a trade school, but I'm talking about basic essential knowledge and skills, not the details of using specific technologies.

If AI requires the thinking of a "senior" and the schools don't teach the things a "senior" knows, even though they could, then they're failing as educational institutions. There's no reason for that. Similarly, there's no reason for schools to churn out people with no experience or knowledge of how to create real software. They can teach that, too. They can require significant projects as a graduation requirement. They can support and encourage internships (see: Drexel, Cal Poly, VCU). It's a truism that the only constant in software engineering is change, but that doesn't make it any less accurate. A hidebound university system (with a few notable exceptions) is failing us. The fact that many of the CS-degree requirements are the same now as they were when I was in school, back when dinosaurs roamed the earth, says nothing good.

PS. To address a misreading of the above that's popped up elsewhere: I am not saying that universities should teach a tech stack. I am saying that they should teach software engineering: how to work in teams, how to write production-quality programs that people can use, how to work incrementally, software architecture, basic processes like CI/CD and testing, and nowadays, AI-assisted software engineering. None of this has to do with specific tech.

We need to rethink the role of a Computer Science (a narrow specialty) degree in hiring and instead focus on Software Engineering degrees. Universities that don't offer a true Software Engineering degree are not really doing their jobs, in my opinion. They are not teaching an essential discipline.

I think there’s a good analogy in men’s watches—bear with me 😄 . I usually mentally roll my eyes when somebody says, “My $20 Timex keeps time just as well as that <expensive watch>.” It’s both a sort of snobbery and a failure to grasp the concept. Particularly in a cell-phone era, watches have nothing to do with keeping time. They are jewelry—the only tasteful everyday jewelry men can wear other than wedding or class rings. For engineers in particular, mechanical watches can be delightful—the charm of artful complication in a computer age. Watches also make a statement about the wearer: ostentation vs. elegance; skeletonized complexity vs. railroad-watch simplicity, gold vs. titanium; smart vs. mechanical. All these things matter, and they all tell us something about the wearer (as does that Timex) and, like vibe coding, bring out our feelings. They are also internal: they symbolize how we see ourselves.

The way we code is like the watches we wear. The practical concerns (telling time, creating code) are secondary to the statement our coding systems make about ourselves and the delight we take in the process. Some people delight in hand-crafting, others in the cybernetic futurism of machine assistance. Some people take no delight at all—which is itself a statement (they don’t wear watches). Vibe coding or not, the work is about the same (all watches tell time), but the way we go about doing the work matters to us because it makes a statement about ourselves. So, of course, emotions can run high. It’s not about the tooling, it’s about being “modern” or “cool” or “a craftsperson.”

It’s also about social groupings. The gold Rolex crowd forms a social group, as do the smartwatch and Timex crowds (as does the Patek Philippe crowd, but that’s management 😄.) I can’t overemphasize the role that social groups play in technical decision-making and the development process. We don’t want to alienate our friends, and the “wrong” tooling or technical decisions—ones not approved by the group—can do that, so we resist other ways of working. Our social nature drives us in a particular direction. The technical arguments—telling time—are secondary. It is wise, I think, to never forget that we are social animals and that software development is, first and foremost, a social activity. If we want to change the tech, we first have to look at the social system that will resist (or, in some cases, encourage) that change.

An “experiment” in which you change only one thing (e.g. remove the standup) will fail unless you change the other parts of the system that were dependent on that one thing (e.g. replace scatter/gather with an ensemble). You can’t apply a debugging strategy (change one thing at a time) to organizational improvement.