Agile

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. ...

Методология: Extended Search Research · 8 потоков · 17+ источников · 2025-2026 Классические фиче-команды и платформенные команды с переходом к Product Engineer проблем не вызывают: «все учат делать всё», стек однородный, AI-агенты подстраховывают. Проблемы начинаются в гибридных командах, где комбо из принципиально разных стеков: Прикладная разработка + дата-инженерия (Java + Trino/Airflow/ClickHouse) Прикладная + коробка + стриминг Карточный процессинг: Java + данные + COTS + персонализация Команда внутри разбивается по системам и стеку. И главный вопрос: как в такой конфигурации выглядит Product Engineer? ...

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. ...

Hey everyone, here’s my list of resources and literature for getting prepped for the PSM II examination. I would be tremendously happy if you share yours :) *Sidenote: if you are “certificates are overvalued” type of person - I’d agree. This is especially true when it comes to CSM / PSM I - because that certification only mentions that you have been introduced to the basics. However, when it comes to PSM II you need to rely on your experience as a Scrum Master. No more “shu” (of shu-ha-ri), just your experience and daily understanding of agile values. * ...