Posts

A coding agent can turn a detailed plan into code, tests, configuration, and infrastructure before the next planning meeting. That can reduce the time and effort needed for implementation. It does not settle whether the team chose the right problem, has permission to use the data, understands the operational consequences, or can release the change safely. That gap can make a familiar delivery failure happen sooner. The risk is easy to miss because the first result looks convincing. The pull request is large. The test suite is green. The service starts. People can demo it. By then, a team may have invested enough in one approach that changing direction feels costly or politically difficult. ...

AI can make a small team more capable. Public evidence still does not show that three-person AI-native teams outperform well-designed cross-functional teams at scale. The data supports local acceleration: research, coding, testing, and delivery activity can all move faster. It does not establish a universal optimal team size. This article maps the four conditions that determine whether a team of two or three can work sustainably—and two stress tests that reveal where it will break first. ...

We went from early LLM experiments to broad use of chats and coding agents across a large engineering organization at Raiffeisenbank. This article is based on Raiffeisenbank’s experience adopting LLM tools and coding agents across roughly 500 engineers. On the adoption dashboards, everything looked healthy: people opened the tools, tried them, came back, brought examples, showed demos, and tech leads helped their teams learn. The flow metrics did not move for a long time. ...

TL;DR: An effective team is one that: Achieves its business goals Maintains psychological safety and team motivation Delivers predictably through stable flow metrics Three pillars. One triangle. The Premise Two fintech teams spent three months building limit management systems in parallel. One for credit cards, one for checking accounts. Each team: 7–8 people, costing ~$100K/month (average US/EU engineering salary $120–150K/year per person, fully loaded). At the quarterly review, they discovered 70% functional overlap. ...

77 bugs in the backlog. 60 of them without any due date. One month later: 18 bugs. Every single one with an ETA. No magic. No crunch. Just a policy. The Problem How were bugs prioritized before? Three criteria: Who screams loudest — the most frustrated stakeholder wins Which client has the biggest ARR — revenue drives priority How urgent it sounds — panic is contagious The result? A chaotic queue, broken promises, customer-facing teams losing trust in engineering, and engineers trapped in constant context-switching. ...

When examining real workflow data, there’s a common pattern: clusters of tasks that have aged significantly, some clearly stagnating beyond recognition acceptable timeframes. These cases point to one of the most important yet very often overlooked metrics in flow management: WIP Aging. WIP (Work In Progress) Aging measures the elapsed time that a work item has spent in active progress but remains incomplete. This metric serves as an early warning system for workflow problems, helping teams identify where work gets stuck before it significantly impacts delivery timelines. Unlike cycle time, which analyzes completed tasks retrospectively, WIP Aging provides real-time visibility into current work, making it the single most actionable metric for proactive flow management. ...

TL;DR: Once you can read Throughput, you can use it for probabilistic forecasting. Monte Carlo Simulation turns historical completed work into ranges, percentiles, and a better conversation about delivery risk. This is a follow-up to the Throughput article. If you need the foundation first, start with Throughput: the flow metric behind team predictability. Here I will not re-explain the metric. Here we turn historical completed work into a forecast. Now let’s get to the practical question management loves to ask: “When will this project of X items be done?” ...

Throughput is the entry point into team predictability. First read the flow: time period, variability, work types, and the constraints around WIP. Forecasting comes after that. Premise Imagine walking into a bar on a Friday evening, exhausted, and ordering a beer flight. The bartender thinks: “Over the past hour we completed 12 orders; there are 4 in progress; this will be the fifth. Your flight will arrive in 20–25 minutes.” ...

Over seven years of running Story Points workshops, I’ve seen the same pattern: teams learn the technique, apply it for a few sprints, then gradually drift back to old habits. At my current scale — 47 teams, around 400 people in IT — 60% use Story Points, 40% don’t. What’s interesting: those 60% who do use them do it completely differently. Even 3 months after the training, only 20-30% use Story Points correctly (as intended). The problem isn’t the tool itself, but how we use it and what we expect from it. ...

(Experience from an AI-Based Fintech KYC SaaS Startup Focused on LATAM and Africa) Your regular challenge: When Sales, Marketing and IT Speak Different Languages Our SaaS startup served emerging fast-paced fintech markets (it still is). Speed + compliance were existential. Since most startups live on venture capital with limited runway, every delay in shipping value to the market means lost clients and regulatory risk. It also a huge roadblock on your path to become self-sustainable. So you need to be super frugal and efficient. ...