Posts

I care about how my team manages their energy. Running faster than we can sustain leads to mistakes, rework, and slower progress overall. Experience shows time and time again, that the worst technical mistakes happen when we push through late-evening and frantic over-work. Projects are marathons, not sprints, so it’s important to maintain a Sustainable Pace. When teams preserve steady, focused effort, the code quality and morale stay high. If a manager pressures the team to speed up, the team must push back thoughtfully. The team’s endurance and the long-term health must be protected. ...

Eric Evans’ idea of Ubiquitous Language is simple but powerful: the team needs a shared model and vocabulary for the problem domain. That model should be understandable to everyone: the builders, managers, operations, and the customers. So that the conversations, designs, and tests all line up. Maintain a living “data dictionary” with concise terms that describe the data and the processes that change it. Discussions for your team Do we currently have names for the core domain concepts that make sense to everyone? Where can we capture and store terms in a shared glossary? Do we use this language in our acceptance tests?

Years ago it was the norm for teams to work together in the same office. In close proximity. These days, teams work remotely, or partially remote. The idea of “On‑Site Customer” was simple: put the right product owner or customer or end-user in proximity of the builders. Close enough so they could quickly shoot questions/answers and get clarity on things, ad-hoc. This resulted in questions getting answered in seconds, and potential misunderstandings caught early. ...

The acceptance tests are written by the business, and run by the builders. The business defines what success looks like, but it’s not their job to verify that the system delivers it; that responsibility belongs to the people who built it. Builders run acceptance tests, fix failures, and ensure the application delivers what has been asked for; before a story is considered done. Running those tests continuously is the only reliable way the team knows the story is complete. ...

I’ve seen teams rewarded for finding as many defects as possible. Better that the teams finds them, rather than end-user, right? Over time the culture and metrics rate a higher defect count as proof of the QA is doing well. Defects become a currency that some team members benefit from. The builders learn that if a high defect count isn’t a problem, then they can meet their delivery deadlines simply by announcing the work as complete before the expected due date (while quietly knowing that it’s imperfect) ...