Writing
How software teams actually operate and work together — from Agile and Scrum to how delivery really happens in big corps, startups, and outsourcing.
Practical, no-nonsense writing on how software teams actually work and collaborate: Agile and Scrum in practice, the "-Driven Development" family, and — crucially — how delivery, ownership, communication and decision-making really differ across company types, from enterprises to small and mid-size startups to outsourcing and software services. Written so anyone on the team — BA, PO, PM, developer, QA or newcomer — can read the environment they're in and operate well in it.
A daily standup can become a ritual of reporting yesterday, or a short strategy conversation about today. The difference is whether the team uses it to inspect flow, surface risk, and decide what needs attention next.
Agile is often declared dead because teams have seen too much ceremony without learning, too many boards without feedback, and too many meetings without trust. A calm reflection on why the branded version of Agile may deserve criticism, while the deeper habit of adapting through small, honest feedback loops is still worth protecting.
A practical introduction to Lean Business Analysis: why BA starts with value, how needs assessment protects teams from solving the wrong problem, and how a business case keeps decisions grounded without turning analysis into ceremony.
A practical guide to Lean BA planning: stakeholder analysis, predictive versus adaptive BA rhythms, elicitation planning, and the difference between collecting stated requests and uncovering the need behind them.
A calm, practical guide to requirements modeling: scope, process, rule, data, and interface models, with examples of how diagrams and structured descriptions help teams reason together before building.
A practical reflection on the later half of Business Analysis: requirement quality, prioritization, traceability, change control, UAT, rollout choices, transition, and evaluating whether the delivered solution actually worked.
A practical reflection on Software Measurement and Estimation: A Practical Approach by Linda M. Laird and M. Carol Brennan. The article focuses on the ideas engineers can use at work: measure from decisions, estimate as uncertainty instead of promise, track quality before release, and keep dashboards useful instead of decorative.
A practical reflection from Mike Cohn’s Agile Estimating and Planning on story points, velocity, planning poker, ideal days, and why estimates should expose uncertainty instead of pretending to remove it.
A second reflection from Agile Estimating and Planning, focused on release planning: prioritizing by value and risk, splitting stories into useful slices, using buffers for uncertainty, and communicating plans without pretending the future is fixed.
A practical reflection from Don Norman’s The Design of Everyday Things for software and product teams: discoverability, signifiers, mapping, feedback, conceptual models, and why a clear interface should not make users guess what it wants.
A second reflection from Don Norman’s The Design of Everyday Things on slips, mistakes, constraints, forcing functions, checklists, undo, root-cause analysis, and how product teams can design systems that absorb ordinary human limits instead of blaming users.
A practical reflection on Data: Harness Your Numbers to Go from Uncertain to Unstoppable, focused on how the EOS Data Component helps leaders move from anxious guesswork to clearer operating visibility. The article looks at data as a clean windshield: a way to test intuition, avoid hopeful fiction, connect Visionary and Integrator work, and turn numbers into leadership freedom rather than pressure.
A practical reflection on the Scorecard idea in Data and EOS: why a company does not need dozens of KPIs to understand its operating health, but a small set of measurables that are clear, consistent, predictive, and owned. The article looks at the Scorecard as a check-engine light, the difference between P&L and leading indicators, weekly cadence, reverse-engineering goals, range goals, and the traps of measuring too much or measuring what is easy instead of what matters.
A practical reflection on Everyone Has a Number from Data and EOS. The article treats role-level measurables as a gift of clarity rather than a surveillance tool: they help people understand how they win, help managers avoid vague judgment, speed up problem-solving, create healthier competition, and turn accountability into a foundation for trust.
A practical reflection on the Cash chapter in Data: why a business can sell well, show accounting profit, and still feel tight on cash. The article explains the difference between sales, profit, and cash; why financial literacy should extend beyond finance; how daily work connects to gross margin, rework, collections, expenses, and cash flow; and why understanding money requires clarity, rhythm, and real decisions more than complex formulas.
A pre-mortem is the quiet habit of imagining that a plan has failed before it begins, then working backward to find the reasons. This article explains the idea and shows how to use it in code, large systems, promotion planning, interviews, and personal goals without turning preparation into pessimism.
Two engineers with the same title can have completely different jobs — because the environment shapes the work far more than the title does. This is a field guide to the three worlds most software careers move through: big corp, startup, and outsourcing, compared along the dimensions that actually change day to day — where work comes from, who decides, how heavy the process is, how much you own, how you communicate, the pace and quality bar, and what gets rewarded. With a full comparison table and an honest guide to which environment suits you.
Joining a big company from a smaller one is a culture shock: you control very little of the system, and it works brilliantly anyway. That's the design — an enterprise optimises for scale and reliability, not your individual speed. This deep-dive explains how to work well inside the machine: where your work fits in the planning hierarchy, why alignment (not coding) is the real senior job, which process is earned and which is theatre, how to actually ship through review chains, the healthy side of stakeholders and politics, the failure modes that grind people down, and how to grow up a clear career ladder.
The startup promise — real ownership, ship today, watch it matter tomorrow — is largely true, but the recruiting page leaves out the ambiguity, whiplash, and instability that come from the same root cause: a startup is a company still searching for its business. This deep-dive is an honest guide to the trade, across small and mid-size startups: why speed of learning beats polish, what wide-and-shallow ownership really feels like, how to treat ambiguity as the work itself, taking technical debt consciously, communicating before knowledge-in-heads bites, the disorienting small-to-mid transition when process reappears, the failure modes (burnout, hero culture, whiplash), and how to thrive and grow.
Outsourcing is the most misunderstood of the three worlds — not a faceless code factory but, in a good services firm, a place where you build real products across more domains in two years than most product engineers touch in ten. The catch: you don't own the product, you deliver against a contract, and a second skill sits beside the engineering — managing the client relationship. This deep-dive covers the structural fact that reshapes everything, the two shapes of outsourcing work, why scope is sacred and the change request is your friend, billing and estimates and utilization, communication as a deliverable, time zones, quality under contract, the failure modes, and how to thrive and grow a services career.
TDD, BDD, DDD, ATDD, EDD, CDD, FDD — the "-Driven Development" alphabet soup confuses even experienced engineers, partly because they're not rivals: they answer different questions and compose together. This is a practical, example-rich guide for software engineers: what each one really means, the core loop or concept, concrete code and Gherkin examples, when to reach for it, the pitfalls — and a clear map of how they fit together on a single real feature.
Almost every software team says they "do Scrum" — and almost every one does it a little differently. This is a clear, practical field guide for everyone on the team, whatever your role: what an epic, story, task, and sub-task actually are; how status workflows really run; what story points mean (and the mistakes that ruin them); how to estimate and log work honestly; how to read burndown and velocity charts; and how to run planning, daily, review, and retro so they help instead of waste time. The standard, the common customizations, and how to operate it all well — enough to be genuinely useful from day one.
