Posts

We want steady velocity, not wild swings. Have you noticed how early in our projects we fly; but later, code messes pile up. That mess creates back pressure - the bigger the mess, the slower our team goes. And then our slow team faces even more schedule pressure, which encourages quick hacks that make the mess worse. That feedback loop can grind the team toward immobility. The “fix” is often, to add more people, but the new hires learn from the existing messy code base, and they often take on the same behaviors that produced it. ...

Some teams create a “stabilization” window after a sprint because features are half done, half tested, or half documented. This delivery delay frustrates customers. A better approach is to have systems in place that enables our software to always be technically deployable at the end of every iteration. From the builders’ point of view that means code is clean, tests pass, documentation up to date, and the implemented stories are stabilized. ...

It’s important to focus on delivering value quickly rather than starting something early. The last thing customers and managers expect is that it’s common for software building teams to unintentionally create artificial delays. Yet teams do this all the time by trying to build every feature at once. Half‑done or half‑tested features pile up and prevent deployment. Instead it’s better to prioritize the most important features first and finish them end‑to‑end. Deliver vertical slices and only call it “done” when an the code, the tests, and the docs are finalized. And consider using feature toggles when you must decouple rollout from completion. ...

As a team we should expect one simple thing from our work: We will not ship crap Managers, customers, and users reasonably expect high-quality systems with few defects. When we slack on quality, we betray that trust. The team must push practices that stop bad code: testing, refactoring, simple design, and continuous customer feedback. These are not ceremonies — they’re tools that make quality repeatable. Builders should treat them as nonnegotiable habits, not optional extras. Doing so keeps our work dependable and our reputation intact. ...

Look around now - how many computers are in the room? I count about thirty. Phones, the TV, my dyson heater, my headset, my oura ring, remote controls : nearly everything with a button on it runs software. That matters because every one of those devices needs code written by teams likes yours. Software touches law, health, transport, and food systems. And small mistakes can cascade into real harm. As software builders, we must treat our craft as responsible work: design carefully, test relentlessly, and assume our code has consequences beyond the screen. ...