Ways of Working
Daily standup : rapport d'état ou stratégie du jour ?
Un daily standup peut devenir un rituel de reporting, ou une courte conversation stratégique sur le flux, les risques et l'attention du jour.
Articles
Ways of Working
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.
Ways of Working
Agile is Dead, Long Live Agile
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.
Ways of Working
Lean Business Analysis: Start from Value, Not Requirements
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.
Ways of Working
Lean BA Planning: Stakeholders, Elicitation, and the Questions Behind Requirements
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.
Ways of Working
Requirements Modeling: How BA Turns Messy Conversations into Shared Pictures
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.
Ways of Working
Requirements Quality, Traceability, and Solution Evaluation: Keep the Promise After Sign-off
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.
Ways of Working
Software Measurement and Estimation: Fewer Gut Feelings, Better Engineering Decisions
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.
Ways of Working
Agile Estimating and Planning: Estimates Are Conversations, Not Promises
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.
Ways of Working
Agile Release Planning: Plan with Value, Risk, and Real Feedback
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.
Ways of Working
The Design of Everyday Things: Make the Interface Explain Itself
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.
Ways of Working
The Design of Everyday Things: Human Error Is Often System Design
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.
Ways of Working
Data: Data Is a Windshield for Operators
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.
Ways of Working
Data: A Scorecard Is a One-Page Early Warning System
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.
Ways of Working
Data: Everyone Has a Number Is Not Surveillance
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.
Ways of Working
Data: Revenue Is Not Cash, and Profit Is Not Breathing Room
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.
Ways of Working
What Is a Pre-Mortem? Seeing Failure Early to Build Better Systems and Careers
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.
Ways of Working
How Software Teams Really Work: Big Corp vs Startup vs Outsourcing
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.
Ways of Working
Working in a Big Corp: Alignment, Process, and Getting Things Done at Scale
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.
Ways of Working
Working in a Startup: Speed, Ambiguity, and Wearing Many Hats
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.
Ways of Working
Working in Outsourcing & Software Services: Clients, Scope, and Delivery on Contract
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.
Ways of Working
TDD, BDD, DDD, and the Rest of the "-Driven Development" Family, Explained for Engineers
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.
Ways of Working
Agile & Scrum in Practice: How Teams Really Run It vs. How It's Meant to Work
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.