[{"content":"This page documents the full methodology behind the Deep Research Benchmark.\nWhat Are We Comparing? Three fundamentally different approaches to AI-powered research:\nPerplexity Deep Research — a black-box hosted service (sonar-deep-research). You send one prompt, it autonomously plans, searches, reads, iterates and synthesises. ~50 sources, 2-5 minutes. Extended Search Pipeline — a custom 7-step pipeline where we control every stage. Each step is a separate LLM call in a separate sub-agent. Full transparency, full control. Single-Agent Pipeline — the same 7 steps, the same prompts, but executed in one continuous session without spawning sub-agents. Context grows, but there\u0026rsquo;s zero spawn overhead. We also tested optimisations (cheap models, lightContext, minimal steps) that turned out to be dead ends.\nThe 7-Step Pipeline Both Extended Search and Single-Agent share the same algorithm. The difference is orchestration (sub-agents vs single session), not the steps.\nUser query │ ▼ ┌──────────────────────────────┐ │ Step 1: PLANNING │ │ Dimensions of Understanding │ │ → Search Threads │ │ LLM call: 1-2 │ └──────────────┬───────────────┘ │ ▼ ┌──────────────────────────────┐ │ Step 2: FIRST-PASS SEARCH │ │ Top-10 results per thread │ │ LLM call: 0 (mechanical) │ └──────────────┬───────────────┘ │ ▼ ┌──────────────────────────────┐ │ Step 3: RELEVANCE FILTERING │ │ LLM judges each URL │ │ Min 2, max 5 per thread │ │ LLM call: 1 │ └──────────────┬───────────────┘ │ ▼ ┌──────────────────────────────┐ │ Step 4: DEEP READING │ │ web_fetch + text extraction │ │ Retry: 3× exponential backoff │ │ LLM call: 0 (mechanical) │ └──────────────┬───────────────┘ │ ▼ ┌──────────────────────────────┐ │ Step 5: GAP ANALYSIS │ │ Per-thread summary (N calls) │ │ Cross-thread gaps (1 call) │ │ Contradictions + blind spots │ │ LLM calls: N + 1 │ └──────────────┬───────────────┘ │ ▼ ┌──────────────────────────────┐ │ Step 6: ITERATIVE SEARCH │ │ Round 1: up to 5 follow-ups │ │ Round 2: up to 2 (critical) │ │ Drill-down top 2-3 objects │ │ LLM call: 1 (prioritisation) │ └──────────────┬───────────────┘ │ ▼ ┌──────────────────────────────┐ │ Step 7: SYNTHESIS │ │ Draft (1 call) │ │ Critical review (1 call) │ │ Final revision (1 call) │ │ LLM calls: 3 │ └──────────────────────────────┘ Step 1: Planning — Dimensions \u0026amp; Threads Two-level decomposition. The query is first broken into what to understand (dimensions), then into how to find it (search threads).\nDimensions of Understanding A dimension is NOT a search query. NOT a section header. NOT \u0026ldquo;tell me about X\u0026rdquo;. It is a specific type of question about the topic. Dimensions must be heterogeneous — each one looks at the topic from a fundamentally different angle.\nType Purpose Required? Factual What exists? Catalog, inventory, prices ✅ Always Mechanistic How does it work? Cause-effect, internals, specs ✅ Always Critical Where is data contested? Studies contradict? Spec vs reality? ✅ Always Practical Can I actually use/buy this? Availability, service, cost Optional Contextual Historical roots, cultural significance, market trends Optional Minimum viable set: 3 dimensions (factual + mechanistic + critical).\nKey design choice (H2): Threads must be heterogeneous by type. Not all \u0026ldquo;find facts about X\u0026rdquo;. At least one thread targets criticism/contradictions, at least one targets mechanisms. This is what gave Extended Search an edge over Perplexity in our initial benchmark — Perplexity catalogued, but didn\u0026rsquo;t challenge.\nSearch Threads Each dimension produces 1-2 search queries. The agent decides based on breadth:\n1 query if the dimension is narrow (e.g. \u0026ldquo;service centres in Ufa\u0026rdquo;) 2 queries if broad (e.g. \u0026ldquo;neurobiology of chanting\u0026rdquo; → landscape query + specific evidence query) Never more than 2 per dimension Drill-down is NOT planned here. If specific products/models surface from the factual dimension — great, but we don\u0026rsquo;t pre-plan searches for \u0026ldquo;Bosch Serie 6 noise review\u0026rdquo;. That happens later, driven by gap analysis.\nLanguage: determined by the query. English fallback only for academic dimensions where the query language yields insufficient results.\nLLM calls: 2 (one for dimensions, one for threads). Output is structured JSON.\nExample output for the kitchen task:\n{ \u0026#34;dimensions\u0026#34;: [ {\u0026#34;name\u0026#34;: \u0026#34;Catalog\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;factual\u0026#34;, \u0026#34;priority\u0026#34;: \u0026#34;core\u0026#34;, \u0026#34;question\u0026#34;: \u0026#34;Which brands/models available in Ufa mid-range?\u0026#34;}, {\u0026#34;name\u0026#34;: \u0026#34;Specs\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;mechanistic\u0026#34;, \u0026#34;priority\u0026#34;: \u0026#34;core\u0026#34;, \u0026#34;question\u0026#34;: \u0026#34;How do mid-range hoods/ovens differ technically?\u0026#34;}, {\u0026#34;name\u0026#34;: \u0026#34;Reality check\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;critical\u0026#34;, \u0026#34;priority\u0026#34;: \u0026#34;core\u0026#34;, \u0026#34;question\u0026#34;: \u0026#34;Where do specs diverge from real-world performance?\u0026#34;}, {\u0026#34;name\u0026#34;: \u0026#34;Service\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;practical\u0026#34;, \u0026#34;priority\u0026#34;: \u0026#34;core\u0026#34;, \u0026#34;question\u0026#34;: \u0026#34;Authorised repair in Ufa, parts availability?\u0026#34;} ], \u0026#34;threads\u0026#34;: [ {\u0026#34;dimension\u0026#34;: \u0026#34;Catalog\u0026#34;, \u0026#34;query\u0026#34;: \u0026#34;встраиваемая вытяжка индукция духовка комплект средний сегмент 2025 2026\u0026#34;}, {\u0026#34;dimension\u0026#34;: \u0026#34;Reality check\u0026#34;, \u0026#34;query\u0026#34;: \u0026#34;отзывы владельцев встраиваемой вытяжки шум реальный vs заявленный проблемы\u0026#34;}, {\u0026#34;dimension\u0026#34;: \u0026#34;Service\u0026#34;, \u0026#34;query\u0026#34;: \u0026#34;сервисный центр Уфа ремонт Bosch MAUNFELD Gorenje гарантия\u0026#34;} ] } Step 2: First-Pass Search Mechanical step — no LLM call. Each search thread is executed as a web_search(query). Top 10 results per thread are collected.\nExecution: parallel (with rate-limit fallback to sequential, 5-10 sec pauses) Deduplication: by URL across all threads Total: 3-5 threads × 10 results = 30-50 URLs before filtering Output: list of URLs with titles and snippets Step 3: Relevance Filtering The LLM evaluates every URL against the dimensions and decides: read deeply or skip?\nSelection rules:\nSelect URLs that directly help answer the thread\u0026rsquo;s goal Prefer: academic papers, official docs, detailed reviews, primary sources Deprioritise: SEO aggregators, listicles with no depth, paywalls, product cards without reviews If the same URL appears in multiple threads → select once, under the most relevant thread Constraints:\nParameter Value Reason Min per thread 2 If less → flag as gap Max per thread 5 Hard ceiling Max total 20 Budget control Why not read everything? Cost. Filtering is ~$0.01/URL; deep reading is ~$0.10/page. 50 pages = $5 in fetch + LLM processing.\nLLM call: 1 prompt with all URLs + dimensions → filtered list with one-sentence justification per selection.\nStep 4: Deep Reading Mechanical step — no LLM call. web_fetch(url) for each filtered URL. HTML → text extraction.\nRetry policy: 3 attempts, exponential backoff (10s, 20s, 40s) Min content threshold: 200 characters (below = skip; likely a login wall or JS-only page) Failed pages: logged as gaps for Step 5 Output: raw text per page Step 5: Gap Analysis This is the step that separates our pipeline from Perplexity Deep Research. Instead of just summarising, the LLM explicitly identifies what\u0026rsquo;s missing, where sources contradict, and what blind spots exist.\nTwo-pass process:\nPass 1: Per-thread summary (N LLM calls, one per thread) Each thread\u0026rsquo;s gathered content is summarised structured by dimension:\n2-3 sentences of key findings per dimension Specific data points found (numbers, names, dates — not general statements) Contradictions: do any sources disagree? What\u0026rsquo;s missing: what we hoped to find but didn\u0026rsquo;t Pass 2: Cross-thread gap analysis (1 LLM call) All summaries are combined. The LLM answers three questions:\nUncovered dimensions — which dimensions have significant gaps? For each: what\u0026rsquo;s missing + suggested follow-up query Contradictions — where do sources explicitly disagree? Is this resolvable with more data, or a genuine disagreement? Blind spots — what important aspects did NO thread cover, even though they should have? Output:\nGAPS: - {dimension}: {what\u0026#39;s missing} → follow-up: \u0026#34;{query}\u0026#34; CONTRADICTIONS: - {topic}: {source A} vs {source B} BLIND SPOTS: - {thing we should have investigated but didn\u0026#39;t} VERDICT: - Dimensions fully covered: N/total - Critical gaps (must fill): [list] - Optional gaps (nice to have): [list] LLM calls: N + 1 (one summary per thread + one cross-thread analysis)\nStep 6: Iterative Search Targeted follow-up searches driven by gap analysis. Not random — only gaps that matter.\nPrioritisation (1 LLM call): rank gaps by severity → assign to rounds:\nParameter Round 1 Round 2 Max follow-up queries 5 2 Max URLs per query 2-3 1-2 Trigger Always (if gaps exist) Only if a core dimension is STILL uncovered Drill-down objects Top 2-3 — Drill-down criteria: if specific objects (models, brands, people) surfaced in Round 1, the agent picks the top 2-3 for deep investigation based on:\nFrequency of mention across sources Contradictoriness of data around the object Category leadership (best-selling, most discussed) The rest go into the catalogue as references, not deep-dives.\nStop condition: all core dimensions covered OR budget exhausted. What comes first.\nEach round repeats search → relevance filter → deep reading, then updates the summaries.\nStep 7: Synthesis Three-pass process.\nPass 1: Draft (1 LLM call) The LLM writes a narrative research report from all gathered content. Not a list of sections per dimension — a flowing article that weaves findings together.\nRules for the draft:\nSpecific data over general statements (\u0026ldquo;48-65 dB\u0026rdquo; not \u0026ldquo;varies\u0026rdquo;) If sources contradict → present both sides, don\u0026rsquo;t pick a winner Flag weak evidence (\u0026ldquo;only one study\u0026rdquo;, \u0026ldquo;manufacturer claim without independent verification\u0026rdquo;) Structure: opening (why it matters) → body (organised by logic, not by dimension) → gaps (what we couldn\u0026rsquo;t find) → key takeaway Pass 2: Critical review (1 LLM call, isolated sub-agent) A separate agent with NO access to previous steps\u0026rsquo; history — only the draft and dimensions. Cross-model verification is possible (default: same model; can switch to a different one).\nThe reviewer answers:\nCoverage check: is each dimension substantively addressed with data? (scored 1-3: token / adequate / deep) Weak claims: which claims lack support? Logical gaps: where does the argument jump? Missing perspective: what would a skeptical expert say is missing? Specific suggestions: not \u0026ldquo;make it better\u0026rdquo; — \u0026ldquo;add data on X\u0026rdquo;, \u0026ldquo;the claim about Y needs a source\u0026rdquo; Pass 3: Final revision (1 LLM call) The main agent receives the review and rewrites, addressing specific suggestions.\nLLM calls: 3 (draft + review + revision)\nArchitecture Comparison Aspect Perplexity Deep Research Extended Search (multi-agent) Single-Agent Pipeline Orchestration Black box Sub-agents per step One continuous session Planning Internal Dimensions → Threads (2 LLM calls) Same Search ~50 sources, parallel 30-50 URLs, parallel, deduped Same Relevance filter Internal LLM judgment (1 call), 20 URL max Same Deep reading Internal web_fetch + 3× retry Same Gap analysis ❌ None ✅ Per-thread summary + cross-thread analysis (N+1 calls) ✅ Same Iteration Internal, unknown depth 2 rounds max, gap-driven, drill-down criteria Same Synthesis Internal Draft + isolated review + revision (3 calls) Same Total LLM calls 1 (opaque) N+10 (fully logged) N+10 (fully logged) Transparency None Full step logs, JSON state files Full step logs Context overhead N/A ~$0.50 per sub-agent spawn Grows linearly Key difference: Perplexity does something similar internally, but doesn\u0026rsquo;t expose gap analysis. Our pipeline\u0026rsquo;s advantage is the explicit \u0026ldquo;what are we missing?\u0026rdquo; step between search rounds, and the isolated critical review of the final draft.\nDRACO Evaluation Framework Every experiment was scored using the DRACO benchmark:\nDimension Weight What it measures Factual Accuracy 50% Are specific claims (prices, specs, model numbers) correct? Spot-checked by independent verification. Breadth \u0026amp; Depth 25% Did it cover all aspects? Surface-level mentions vs thorough analysis. Presentation 15% Is the output well-structured, readable, actionable? Citation 10% Are claims backed by sources? Are the sources real and accessible? Scores were assigned by an independent review agent that had no access to pipeline internals — only the final output.\nCost Measurement Costs are measured by provider balance delta (balance before → balance after each experiment), not by token counting.\nToken-based estimates systematically undercount real cost by 3-22× because they miss:\nSub-agent spawn overhead: each spawn copies full context (~50K tokens × number of sub-agents) Context accumulation: in long sessions, each subsequent LLM call is more expensive than the last Cached tokens ≠ free: cheaper, but still billed Experiment Token estimate Real balance delta Discrepancy Exp 2 $0.08 $1.75 22× Exp 3 $0.21 $2.07 10× Exp 4 $0.50-0.80 $2.03 3-4× Exp 5 $0.30 $1.26 4× Exp 6 $0.05-0.10 $0.47 5-9× Lesson: token-based cost formulas are off by an order of magnitude. Measure real balance changes.\n","permalink":"https://maratkee.com/deep-research-methodology/","summary":"\u003cp\u003eThis page documents the full methodology behind the \u003ca href=\"/deep-research-benchmark/\"\u003eDeep Research Benchmark\u003c/a\u003e.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"what-are-we-comparing\"\u003eWhat Are We Comparing?\u003c/h2\u003e\n\u003cp\u003eThree fundamentally different approaches to AI-powered research:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003ePerplexity Deep Research\u003c/strong\u003e — a black-box hosted service (\u003ccode\u003esonar-deep-research\u003c/code\u003e). You send one prompt, it autonomously plans, searches, reads, iterates and synthesises. ~50 sources, 2-5 minutes.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eExtended Search Pipeline\u003c/strong\u003e — a custom 7-step pipeline where we control every stage. Each step is a separate LLM call in a separate sub-agent. Full transparency, full control.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSingle-Agent Pipeline\u003c/strong\u003e — the same 7 steps, the same prompts, but executed in one continuous session without spawning sub-agents. Context grows, but there\u0026rsquo;s zero spawn overhead.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eWe also tested optimisations (cheap models, lightContext, minimal steps) that turned out to be dead ends.\u003c/p\u003e","title":"Methodology: How We Compare Research Architectures"},{"content":"Методология: Extended Search Research · 8 потоков · 17+ источников · 2025-2026\nКлассические фиче-команды и платформенные команды с переходом к Product Engineer проблем не вызывают: «все учат делать всё», стек однородный, AI-агенты подстраховывают. Проблемы начинаются в гибридных командах, где комбо из принципиально разных стеков:\nПрикладная разработка + дата-инженерия (Java + Trino/Airflow/ClickHouse) Прикладная + коробка + стриминг Карточный процессинг: Java + данные + COTS + персонализация Команда внутри разбивается по системам и стеку. И главный вопрос: как в такой конфигурации выглядит Product Engineer?\nДва полюса Полюс 1 — «Системный PE» (границы ответственности = своя система). Продукт инженера — его система. Java-команда владеет Java end-to-end. Data-команда владеет данными end-to-end. Не лезут в чужой стек. Плюс: реалистично, T-shape ограничивается ролями, а не ландшафтом. Минус: колодцы. Настоящего end-to-end нет. Но можно рассматривать как transition.\nПолюс 2 — «Истинный LeSS». Один бэклог на большую команду. PE работает в любом стеке, независимо от системы и коробки. Звучит утопично — по крайней мере, по коробкам. Но если дойти до этого состояния, получится крайне гибкая и эффективная конструкция.\nИндустрия 2025-2026 не пришла к одному ответу, но выкристаллизовала паттерн: «PE с ограниченными границами ответственности» — это не провал, а валидное transition-состояние. Team Topologies прямо подтверждает его через концепцию Complicated Subsystem Team.\nКаркас: Team Topologies как основа Четыре типа команд, и для каждого — своя конфигурация PE.\nStream-Aligned Team — основной тип Команда, владеющая потоком ценности от бизнес-потребности до прода. Здесь PE работает наиболее нативно: полный lifecycle фичи в руках одной команды.\nSAT + PE Сильные стороны Истинный E2E; минимум хэндоффов; ownership = accountability; быстрый feedback loop Риски Требует зрелого T-shape у всех; высокая когнитивная нагрузка; работает только при ограниченном стеке Границы ответственности Весь стек команды Где применимо Java-сервисы без data-части; однородные прикладные команды Platform Team — внутренний продукт Предоставляет self-service-инструменты другим командам. Принцип: снижение когнитивной нагрузки у SAT, а не контроль над ними.\nPlatform Team + PE Сильные стороны Платформа = внутренний продукт с пользователями (другие команды); product thinking встроен органично Риски PE должен понимать нужды downstream-команд, а не только технологию; риск «платформы ради платформы» Границы ответственности Data-платформа, streaming, CI/CD как продукт Где применимо Kafka/ClickHouse/Trino-инфраструктура — кандидаты на Platform Team Complicated Subsystem Team (CST) — глубина там, где нельзя обойтись без неё Создаётся вокруг компонента, который требует экспертизы, нереалистично распределяемой по всем командам. CST снижает когнитивную нагрузку у SAT через взаимодействие X-as-a-Service.\nCST + PE Сильные стороны Специалисты по коробке/ML/data сосредоточены там, где нужно; SAT не перегружена «чужим» стеком Риски Может превратиться в «чёрный ящик»; зависимость SAT от CST = потенциальный bottleneck; нет полноценного E2E Границы ответственности Своя подсистема: коробочное решение, ML/персонализация, сложный data-стек Где применимо Именно сюда попадают COTS/вендоры и персонализация Enabling Team — временный тренер Не строит фичи. Помогает другим командам освоить новые технологии и уходит. Механизм перехода к «настоящему LeSS».\nEnabling Team + PE Сильные стороны Временные затраты с чётким ROI; растит T-shape у SAT без постоянной зависимости Риски Требует выделенных экспертов; эффект через 2-3 квартала; не работает для vendor-specific коробок Границы ответственности Нет собственного продукта; фокус на передаче компетенций Где применимо Enabling Team из дата-инженеров поднимает Java-PE до «умею базово работать с Airflow/ClickHouse» Конфигурация 1: Платформа документов (Java + Data) Контекст: Фича-тимы делают Java-сервисы платформы. Отдельная команда — хранилища, Trino, Airflow, ClickHouse. Java-разработчики про данные слышали краем уха, дата-инженеры — про Java.\nКарта команд Подсистема Тип команды Роль PE Java-сервисы (документная платформа) Stream-Aligned Team PE = классический, E2E в Java-стеке Хранилища + Trino/Airflow/ClickHouse Platform Team или CST PE = Data Domain PE (внутренний продукт) Что делает Java-PE Владеет потоком ценности: от требования бизнеса до работающего сервиса на проде. Пишет код, покрывает тестами, деплоит, мониторит. AI-агенты помогают с шаблонным кодом, тестами, ревью. Не обязан глубоко знать ClickHouse — но должен уметь прочитать контракт data-платформы и корректно интегрироваться.\nЧто делает Data PE Владеет data-платформой как внутренним продуктом. «Пользователи» — Java-команды. Обеспечивает self-service: Data Contracts, SLA на данные, документированные API. Пишет DAG\u0026rsquo;и в Airflow, проектирует схемы в ClickHouse, оптимизирует запросы под нагрузку — то, где AI-агенты пока ошибаются.\nКак они координируются Два Complicated Subsystem с разными границами ответственности PE. Пересекаются на integration points: Data Contracts, event schemas, SLA. Требовать от каждого знания чужого стека нереалистично даже на горизонте года.\nМеханизмы:\nData Contracts как формальный интерфейс: Java-команда объявляет, какие данные нужны и в каком формате; data-команда обязуется доставить с определённым SLA Совместный refinement на эпиках, затрагивающих оба стека Community of Practice (Spotify-модель): Data Guild, где Java-PE постепенно расширяет горизонтальную полосу T Что меняет AI Агенты сокращают время на освоение «чужого» синтаксиса: Java-PE может с помощью AI написать базовый запрос к ClickHouse или простой DAG в Airflow. Но не убирают необходимость в специалисте там, где агент ошибается — оптимизация под нагрузку, tuning производительности, edge cases.\nПуть к LeSS Сейчас: два домена ответственности PE, чёткие Data Contracts +1 квартал: Enabling Team из дата-инженеров поднимает базовую data-грамотность у Java-PE +2-3 квартала: Java-PE может самостоятельно писать простые data-пайплайны; data-PE — базовые Java-сервисы Цель: единый бэклог, где PE берёт задачу в любом стеке (кроме сложных data-задач — они остаются за CST) Конфигурация 2: Карточный процессинг (Java + Data + COTS + Персонализация) Контекст: Собственная разработка на Java, хранилище + стриминг, коробочное решение, персонализация — «вещь в себе». Самый сложный гибрид: четыре принципиально разных домена.\nКарта команд Подсистема Тип команды Роль PE Java-сервисы (процессинг) Stream-Aligned Team PE = классический, E2E в Java Стриминг (Kafka и пр.) Platform Team PE = Streaming Platform PE Коробочное решение CST PE = Integration Layer PE; глубина — Vendor Specialist Персонализация / ML CST PE = ML-Product PE; отдельный карьерный трек Почему коробка — навсегда отдельный домен ответственности Никакой LeSS не учит всю команду внутренностям вендора. Индустрия выработала паттерн Integration Layer PE + Vendor Specialist:\nIntegration Layer PE знает «как использовать» коробку: конфигурирует, интегрирует, расширяет через API, обеспечивает end-to-end delivery фич, связанных с COTS Vendor Specialist знает «как устроено» внутри: сертифицирован вендором, понимает внутреннюю архитектуру, решает нетривиальные проблемы Это разные люди. И Integration Layer PE — это полноценный Product Engineer: владеет бэклогом своей подсистемы, понимает бизнес-контекст, принимает решения. Но его «продукт» — не весь карточный процессинг, а слой интеграции и кастомизации коробки.\nПерсонализация как CST BCG (2025) выделяет ML/AI-специалистов в отдельный трек — «AI-augmented specialist», который не растворяется в generalist. Причина: ML требует глубокой экспертизы (feature engineering, модельный тюнинг, A/B-тестирование), которая не «размазывается» по команде. PE в этом CST владеет product-аспектом персонализации: какие метрики, какой impact, как приоритизировать ML-задачи. Но в глубину моделей не лезет — для этого ML-инженер.\nКоординация в конфигурации 2 Сложнее, чем в конфигурации 1, потому что четыре домена вместо двух.\nМеханизмы:\nОдин Product Owner на весь карточный процессинг (LeSS-принцип), приоритизирующий единый бэклог Integration contracts между доменами: API-шлюзы, event schemas, SLA Общий Sprint Review — все команды показывают интегрированный инкремент Principal Engineer как кросс-доменный координатор: не привязан к одной команде, синхронизирует архитектурные решения, создаёт virtual squads для эпиков, затрагивающих несколько доменов Путь к LeSS (реалистичный) Сейчас: четыре домена ответственности PE, единый PO, Principal Engineer как «клей» +1-2 квартала: Enabling Team поднимает кросс-стековую грамотность там, где стеки пересекаются (Java + стриминг) +3-4 квартала: Java-PE и Streaming-PE могут подменять друг друга на простых задачах Коробка и ML — остаются CST навсегда. Это не переходное состояние, это правильная архитектура. Что говорит индустрия (2025-2026) AI-агенты не отменяют специализацию 95% инженеров используют AI еженедельно (Pragmatic Engineer, фев 2026). 46% кода генерируется AI (Anthropic, 2026). Но индустрия сходится: AI компенсирует shallow knowledge, но не заменяет deep domain expertise. AI-агент напишет DAG в Airflow, но не спроектирует архитектуру data-платформы под нагрузку.\nModel Builder + Reviewer По данным VirtualCoders и Rivista State of AI (2026), формируется модель разделения:\nBuilders — инженеры с product-инстинктами и навыками промптинга, способные довести фичу от brief до продакшена с помощью агентов Reviewers — senior-инженеры и архитекторы, оценивающие AI-сгенерированные решения на соответствие стандартам качества, безопасности и масштабируемости Это усиливает PE с ограниченными границами ответственности: Builder может работать шире своего стекового домена, но Reviewer с глубокой экспертизой всё равно нужен.\nCOTS + Agile: пять уроков Отчёт Agile Alliance по спасению COTS-проекта подтверждает:\nCOTS-эксперты должны быть встроены в команду, а не работать как внешние консультанты PO уделяет проекту минимум 50% времени — must have для COTS Solution architect владеет декомпозицией: коробка vs кастом vs с нуля Configuration + Development = одна команда с одним бэклогом Интеграции привязываются к фичам, а не планируются отдельно Hub-and-Spoke для data-команд Для гибридных стеков рекомендуется hub-and-spoke (центр компетенций + embedded в команды), а не полностью централизованная или децентрализованная модель. Data-platform команда обеспечивает инструменты и стандарты, продуктовые команды имеют встроенных data-инженеров.\n80% ценности AI = редизайн работы PwC (2026): технология даёт ~20% ценности AI-инициативы. Остальные 80% — это редизайн работы вокруг того, что агенты могут делать, и фокус человеческого таланта на том, что не могут. AI усиливает компетентного инженера, но не компенсирует плохую оргструктуру.\nПять обнаруженных противоречий AI как решатель vs AI усиливает плохую структуру. Сначала оргдизайн, потом AI. Если команды разобщены, AI-агенты лишь ускорят передачу мусора между колодцами.\nFull-stack PE vs специализация. Для гибридных стеков глубокая специализация + product mindset реалистичнее. Поверхностный full-stack инженер не принимает архитектурных решений в сложном домене.\nAgile-идеал vs enterprise-реальность. LeSS feature teams идеальны, но enterprise не готов к радикальной реорганизации. Эволюционный подход через Team Topologies надёжнее.\nСтратегическая уверенность vs операционная готовность. 42% компаний считают AI-стратегию «готовой», но чувствуют меньше уверенности в операционной готовности (Deloitte, 2026). Инвестировать в data-инфраструктуру и governance нужно до AI-масштабирования.\nАвтономия vs выравнивание. PE хочет автономии, но гибридные команды требуют координации. Разрешение: чёткие интерфейсы (Team Topologies) + общий Sprint Review + единый PO.\nИтоговая карта конфигураций Подсистема Тип команды Роль PE Переходный статус Java-сервисы Stream-Aligned PE = классический E2E Стабильно Data (Trino/Airflow/ClickHouse) Platform или CST Data Domain PE Стабильно, с расширением через Enabling Стриминг (Kafka) Platform Streaming Platform PE Стабильно Коробочное решение CST Integration Layer PE + Vendor Specialist Навсегда CST Персонализация / ML CST ML-Product PE Навсегда CST Переход к единому бэклогу Enabling Team → LeSS Feature Team Инвестиция на 2-3 квартала Временный Источники # Источник Дата 1 Rivista AI — The 2026 State of AI 2026 2 VirtualCoders — How AI Coding Agents Are Changing the Role of Product Engineers 2026 3 Salesforce — 2026 AI Predictions Ноя 2025 4 Pragmatic Engineer Survey Фев 2026 5 Anthropic — Agentic Coding Trends Report 2026 6 PwC — 2026 AI Business Predictions 2026 7 Deloitte — State of AI 2026 8 BCG — Machines That Manage Themselves 2025 9 Agile Alliance — Rescue COTS Public Sector Project 2023 10 Team Topologies (Skelton \u0026amp; Pais) 2019/updated 11 LeSS.Works — Large Scale Scrum Framework ongoing 12 Business Insider — AI Jobs: Product Engineers \u0026amp; Managers Апр 2026 13 HatchWorks — AI Development Team of the Future 2026 14 LinkedIn — New T-Shaped: How Specialized Roles Converge (Jeffrey Monnette) 2026 15 EPAM — T-Shaped Developer in an AI Age 2026 16 dev.to — Software Engineer Career Levels Мар 2026 17 Atlassian — Team Topologies Framework 2025 ","permalink":"https://maratkee.com/research-digests/2026-05-15-product-engineer-hybrid-teams/","summary":"\u003cp\u003e\u003cstrong\u003eМетодология:\u003c/strong\u003e Extended Search Research · 8 потоков · 17+ источников · 2025-2026\u003c/p\u003e\n\u003cp\u003eКлассические фиче-команды и платформенные команды с переходом к Product Engineer проблем не вызывают: «все учат делать всё», стек однородный, AI-агенты подстраховывают. Проблемы начинаются в \u003cstrong\u003eгибридных командах\u003c/strong\u003e, где комбо из принципиально разных стеков:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eПрикладная разработка + дата-инженерия (Java + Trino/Airflow/ClickHouse)\u003c/li\u003e\n\u003cli\u003eПрикладная + коробка + стриминг\u003c/li\u003e\n\u003cli\u003eКарточный процессинг: Java + данные + COTS + персонализация\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eКоманда внутри разбивается по системам и стеку. И главный вопрос: \u003cstrong\u003eкак в такой конфигурации выглядит Product Engineer?\u003c/strong\u003e\u003c/p\u003e","title":"Product Engineer в гибридных IT-командах: паттерны перехода 2025-2026"},{"content":"TL;DR: An effective team is one that:\nAchieves its business goals Maintains psychological safety and team motivation Delivers predictably through stable flow metrics Three pillars. One triangle.\nThe 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).\nAt the quarterly review, they discovered 70% functional overlap.\nLosses: over $600K in duplicated effort. A 1–2 quarter delay to market. Technical debt from building two systems instead of one. And then it turned out neither was actually needed.\nNobody reading this will be surprised. We\u0026rsquo;ve all seen parallel bicycles.\nThe industry data is just as grim:\nOnly 9% of employees agree that their team\u0026rsquo;s goals are aligned with company goals (Axios HQ, 2025) The remaining 91% optimize their own slice and hope someone needs it Meanwhile, 27% of executives believe their teams are well-coordinated (McKinsey) Global losses from strategy-execution misalignment: $2 trillion/year (PMI) The Model After 10+ years working with teams and their leaders, a pattern emerged. Three factors determine whether a team is truly effective — and they form a triangle. If one corner is broken, everything leaks out.\nThe Three Pillars Pillar 1: The team must achieve business goals (Goal Achieving Team)\nThe team\u0026rsquo;s work is tied to revenue, conversion, NPS — what matters for the business.\nHealth metric: did they achieve the goal or not? Not \u0026ldquo;do they understand the goal\u0026rdquo; — but \u0026ldquo;did they deliver the result?\u0026rdquo;\nUnderstanding is necessary. But we measure results.\nPillar 2: The team must be sustainable (Sustainable Team)\nPeople are motivated, not burning out, and can speak openly about problems. There is psychological safety — you can admit a mistake without fear of punishment.\nWhen people are afraid, problems accumulate. Then the pressure valve blows: attrition, low productivity, burnout, missed deadlines, damaged employer brand.\nPillar 3: The team must be predictable (Predictable Team)\nWork moves predictably. The team can answer \u0026ldquo;when will it be done?\u0026rdquo; with reasonable accuracy. Flow metrics (Throughput, Lead Time, WIP) are stable and transparent.\nIf the flow is chaotic, planning and commitments are impossible. (Well, technically possible — just with questionable outcomes.)\nWhy a Triangle? Each pillar reinforces the others:\nClear goals reduce anxiety → people feel safer Healthy people can speak honestly about problems → the flow becomes transparent Predictable flow builds confidence → easier to focus on goals And conversely — when one pillar collapses, it drags the others down.\nWhy Order Matters: Goals → People → Flow The prioritization sequence is deliberate, backed by independent research.\nThe most influential finding comes from Richard Hackman\u0026rsquo;s model at Harvard. In his \u0026ldquo;5 Conditions for Team Effectiveness,\u0026rdquo; Compelling Direction (a clear purpose) comes before supporting context, team structure, and coaching.\nWithout direction, everything else is pointless. A team can be perfectly structured — but if it doesn\u0026rsquo;t know where it\u0026rsquo;s going, it\u0026rsquo;s just moving fast in the wrong direction.\nOthers reached the same conclusion:\nAmy Edmondson (Harvard) — the \u0026ldquo;Set the Stage\u0026rdquo; method begins with the purpose question, not with safety McKinsey — calls direction clarity \u0026ldquo;the first and most forgotten step\u0026rdquo;; companies with clear direction are 2x more likely to be profitable CIPD (2024) — leaders who set mastery goals create environments of psychological safety; goals generate safety, not the other way around Google Project Aristotle — psychological safety explains 43% of team effectiveness variance, but without clear goals it becomes comfort without results Pillar 1: Goals — The Foundation What We Measure Effectiveness here = achievement of business results:\nDid revenue grow or not? Did conversion improve or not? Did NPS increase or not? Goals can be binary (yes/no), relative (%), or quantitative (from X to Y). Visualized with traffic lights or OKR progress. Reviewed at QBRs or Sprint Reviews.\nThe Real Problem: Misalignment Goals often exist. They\u0026rsquo;re just not reaching the people doing the work.\nHow it typically breaks down:\nCEO formulates strategy Strategy becomes OKRs OKRs cascade down the hierarchy At each level, context is lost An engineer receives a Jira ticket with no connection to any goal The result: someone completes a task but has no idea how it affects the business. Tasks multiply that the business doesn\u0026rsquo;t need.\nGreat Metrics ≠ Business Results A team can show excellent flow metrics. Stable Throughput. Decreasing Lead Time. Green dashboards.\nAnd still miss every business goal.\nReal example: a team spent 6 months building a beautifully architected API with stellar documentation. The client needed a simple Salesforce integration. They didn\u0026rsquo;t wait — went to a competitor who shipped in 2 weeks.\nPillar 2: People — Sustainability Psychological safety is the belief that you can speak up without fear of punishment. Combined with sustainable motivation (financial, interesting work, skill growth), this determines whether a team can perform over time.\nThe Edmondson Paradox High-performing teams report more errors than low-performing ones. Because they\u0026rsquo;re not afraid to talk about them.\nLow-performing teams hide mistakes → mistakes accumulate → explode in production High-performing teams surface mistakes immediately → fix faster → learn Connection to Goals When goals are clear, fear drops. People understand the criteria by which they\u0026rsquo;re evaluated. Less uncertainty → less anxiety.\nWhen goals are fuzzy, everything becomes subjective. People play it safe, hide problems, avoid risk.\nClear goals → less fear → more honesty → faster feedback.\nPillar 3: Flow — Predictability Here we measure predictability — the team\u0026rsquo;s ability to answer \u0026ldquo;when will it be done?\u0026rdquo; with reasonable accuracy.\nKey Metrics Metric What It Measures Throughput How many items completed per period Lead Time Time from creation to completion WIP How many items are in progress simultaneously The relationship is described by Little\u0026rsquo;s Law: Lead Time = WIP / Throughput\nWant to go faster? Reduce WIP. It\u0026rsquo;s counterintuitive, but mathematically proven.\nThe Key Insight: No Correlation Between Goals and the Other Pillars! Over 7 years of data from ~75 teams:\nCorrelation between good flow metrics and achieving business goals: below 0.60 Correlation between high motivation and achieving business goals: below 0.60 This means: you can have a motivated, cohesive team that delivers fast and predictably — but builds the wrong thing.\nFlow metrics and motivation surveys are necessary but not sufficient. Without connection to goals, it\u0026rsquo;s a fast flight in the wrong direction with a beautiful dashboard.\nThree Traps When Metrics Come First Trap 1: Optimizing speed instead of direction The team chases Throughput. Hires more people, closes more tickets. But if tickets aren\u0026rsquo;t connected to goals — it\u0026rsquo;s useless activity.\nTrap 2: Metrics as the goal (Goodhart\u0026rsquo;s Law) When a metric becomes a target, it ceases to be a good metric. The team inflates Throughput by slicing tasks thinner, closing them \u0026ldquo;formally,\u0026rdquo; ignoring quality. Metric goes up, value goes down.\nTrap 3: Local optimization The team optimizes its own area, but handoffs to other teams remain bottlenecks. Example: an ATM channel team shows 20-day cycle time. 14 of those days — waiting for a vendor response. The team isn\u0026rsquo;t slow. 70% of their cycle is idle time at the boundary.\nCheck Your Team Goals Team achieves its business goals Clear connection between team\u0026rsquo;s work and business outcomes Priorities are clear — team knows what matters most Less than 30% of sprint tasks are unrelated to business goals Ask the team: \u0026ldquo;How does this task affect the business goal?\u0026rdquo;\n\u0026ldquo;Directly impacts conversion\u0026rdquo; — great \u0026ldquo;It\u0026rsquo;s tech debt blocking feature X\u0026rdquo; — acceptable \u0026ldquo;I don\u0026rsquo;t know\u0026rdquo; — problem \u0026ldquo;It doesn\u0026rsquo;t, but it\u0026rsquo;s important\u0026rdquo; — big problem People Retrospectives openly discuss mistakes and failures People ask questions and propose alternatives New team members aren\u0026rsquo;t afraid to admit what they don\u0026rsquo;t understand Conflicts aren\u0026rsquo;t swept under the rug Flow Team can forecast with ±30-40% accuracy WIP is limited and controlled Metrics are stable from sprint to sprint Blockers are visible and escalated quickly What to Do Next Diagnose — walk through the checklist, find the weakest pillar Fix goals first — if they\u0026rsquo;re unclear, nothing else matters Create traceability — from task to sprint goal, from sprint goal to quarterly objective Sync leaders — parallel bicycles are caught at this level Related Zero Bug Policy: From 77 Bugs to 18 in One Month — a Flow practice (Pillar 3) that only works with Pillars 1 and 2 in place Boosting Efficiency with WIP Aging — practical tools for Pillar 3 Monte Carlo Simulation for Throughput Forecasting — predictability in action Try it with your data: predictable.team — free tool for analyzing your team\u0026rsquo;s flow metrics Russian version: Хабр: Модель эффективной команды «Эчпочмак» ","permalink":"https://maratkee.com/posts/2026-05-15-triangle-of-team-efficiency/","summary":"\u003cp\u003eTL;DR: An effective team is one that:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eAchieves its business goals\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMaintains psychological safety and team motivation\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDelivers predictably through stable flow metrics\u003c/strong\u003e\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eThree pillars. One triangle.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"the-premise\"\u003eThe Premise\u003c/h2\u003e\n\u003cp\u003eTwo 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).\u003c/p\u003e\n\u003cp\u003eAt the quarterly review, they discovered \u003cstrong\u003e70% functional overlap\u003c/strong\u003e.\u003c/p\u003e","title":"The Triangle of Team Efficiency: Goals, People, Flow"},{"content":"77 bugs in the backlog. 60 of them without any due date.\nOne month later: 18 bugs. Every single one with an ETA.\nNo magic. No crunch. Just a policy.\nThe Problem How were bugs prioritized before?\nThree criteria:\nWho 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.\nSound familiar?\nThe Solution: Zero Bug Policy Simple rules, rigorously enforced.\nPriority Levels Priority Action Critical Drop everything. Fix immediately. Moderate Next sprint. 30% of capacity reserved. Backlog \u0026gt; 2 sprints Stop new features. Fix bugs until caught up. SLAs Type Triage Pickup Resolution Critical Immediate \u0026lt; 2 days \u0026lt; 2 days Moderate 48 hours ≤ 20 days ≤ 10 days The Golden Rule Every bug has a Due Date or an “ETA for ETA.”\nNo bug lives in the backlog without a commitment.\nIf we can’t commit to fixing it, we either:\nClose it (won’t fix) Escalate it (need resources) Schedule it (next quarter) But we never leave it floating.\nWhy It Works 1. Predictability The customer knows when to expect a fix. No more “we’ll get to it eventually.”\n2. Transparency Support and CSM teams see the real picture. They can set expectations with customers.\n3. Discipline The team can’t ignore quality. Bugs are first-class citizens, not afterthoughts.\nCleaning Dead Weight Once you have a policy, you’ll notice something interesting:\nHalf your backlog is garbage.\nBugs that have been sitting for 6+ months without action. Features nobody asked for twice. Ideas that seemed good at the time.\nThe Dead Weight Audit:\nGo through every item older than 90 days. For each one:\nStatus Action Still relevant + actionable Keep, assign due date Relevant but unclear Clarify with stakeholder this week Nobody remembers why it’s here Close Superseded by other work Close Nice-to-have, no champion Close In our case: 40% of the backlog was dead weight. Closing it freed mental space and made the real priorities visible.\nThe Capacity Allocation Here’s how we split the sprint:\nThis isn’t negotiable. Every sprint, bugs get their slice.\nWhen bug backlog exceeds 2 sprints of work at 30% capacity, we flip:\nBugs get 70% Features get 30% Until we’re caught up.\nThe Cultural Shift The numbers (77 → 18) were impressive.\nBut the real change was cultural:\nBefore:\nQuality was an afterthought “We’ll fix it later” meant “never” Engineers dreaded bug duty After:\nQuality became part of Definition of Done Bugs were addressed systematically Engineers saw impact immediately As one stakeholder put it:\n“Zero Bug Policy significantly bolstered the trust of teams interacting with customers.”\nHow to Start (4-Week Plan) You don’t need a company-wide initiative. Start with your team.\nWeek 1: Audit Count bugs by age Identify items \u0026gt; 90 days old Close dead weight (get stakeholder sign-off) Week 2: Triage Assign priority to remaining bugs Set due dates (or ETA for ETA) Reserve 20-30% of next sprint for bugs Week 3: SLAs Define response times by priority Communicate to stakeholders Start tracking SLA breach rate Week 4: Review Check: how many bugs missed SLA? Adjust capacity if needed Celebrate wins Metrics to Track Metric What It Tells You Bug count Total open bugs Age distribution How many are rotting? SLA breach rate Are we keeping promises? Time to triage How fast do we respond? Bugs per release Is quality improving? Connection to the Triangle of Team Efficiency Zero Bug Policy is a Flow practice (Pillar 3: Predictable Team).\nBut it only works when:\nPillar 1 (Goals): Quality is explicitly a priority. Leadership says “bugs matter” and means it.\nPillar 2 (People): Engineers aren’t afraid to report bugs. The Edmondson Paradox applies — if it’s unsafe to raise issues, bugs stay hidden.\nWithout goals and safety, Zero Bug Policy becomes empty process.\nWith them, it becomes a transformation.\nKey Takeaways Every bug needs a Due Date or “ETA for ETA” Reserve 20-30% of sprint capacity for bugs When backlog exceeds 2 sprints: pause features, fix bugs Dead weight audit: close 90+ day items nobody champions Track SLA breach rate weekly The real win is cultural: quality becomes part of Definition of Done Part of the Triangle of Team Efficiency series: The Triangle Model — The Edmondson Paradox\n","permalink":"https://maratkee.com/posts/2026-05-15-zero-bug-policy/","summary":"\u003cp\u003e77 bugs in the backlog. 60 of them without any due date.\u003c/p\u003e\n\u003cp\u003eOne month later: 18 bugs. Every single one with an ETA.\u003c/p\u003e\n\u003cp\u003eNo magic. No crunch. Just a policy.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"/images/zbp/zbp-cover.png\"\u003e\u003cimg loading=\"lazy\" src=\"/images/zbp/zbp-cover.png\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"the-problem\"\u003eThe Problem\u003c/h2\u003e\n\u003cp\u003eHow were bugs prioritized before?\u003c/p\u003e\n\u003cp\u003eThree criteria:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eWho screams loudest\u003c/strong\u003e — the most frustrated stakeholder wins\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eWhich client has the biggest ARR\u003c/strong\u003e — revenue drives priority\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eHow urgent it sounds\u003c/strong\u003e — panic is contagious\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eThe result? A chaotic queue, broken promises, customer-facing teams losing trust in engineering, and engineers trapped in constant context-switching.\u003c/p\u003e","title":"Zero Bug Policy: From 77 Bugs to 18 in One Month"},{"content":"When examining real workflow data, there\u0026rsquo;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.\nWIP (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.\nThe power of WIP Aging lies in its ability to surface risks immediately. The longer a task ages in the workflow, the higher the probability that it will become obsolete for the business, accumulate dependencies, or lose its value entirely. By monitoring aging work continuously, teams can intervene before cycle times balloon and while there\u0026rsquo;s still opportunity for corrective action.\nUnderstanding WIP Aging Fundamentals The definition of when work enters \u0026ldquo;in progress\u0026rdquo; varies by team, but typically begins when an item is pulled into your active workflow system. From that moment, the aging clock starts ticking. An aging chart visualizes this metric by displaying workflow stages on the horizontal axis and the number of days items have spent in progress on the vertical axis.\nThe chart incorporates percentile zones—commonly 50th, 70th, 85th, and 95th percentiles—representing historical completion patterns. These zones function as health indicators: if a work item\u0026rsquo;s age surpasses the 85th percentile, it\u0026rsquo;s taking longer than 85% of previously completed work at that stage, signaling potential trouble. Research shows that items positioned above the 95th percentile are at high risk and demand immediate attention.\nWhy WIP Aging Matters More Than Other Metrics WIP Aging stands apart as the most crucial metric for teams beginning their flow measurement journey because it\u0026rsquo;s the one metric teams can directly influence in real-time. While lead time, cycle time, and throughput are valuable, they represent lagging indicators—measuring what has already happened. WIP Aging, by contrast, is a leading indicator that enables intervention while work is still active.\nConsider the relationship between metrics: if tasks age excessively in the process and complete only after prolonged delays, cycle time metrics will skyrocket. However, by the time elevated cycle times become apparent, the damage is done. WIP Aging catches these issues early, allowing teams to take corrective action before delivery commitments are jeopardized.\nAdditionally, all other flow metrics improve as a byproduct of effectively managing WIP Aging. Teams that gain control over aging work naturally see improvements in cycle time, lead time, and throughput without explicitly targeting those metrics.\nCommon WIP Aging Patterns and Their Implications Teams encounter several distinctive patterns when analyzing aging charts:\nSteady Growth: WIP Aging increases uniformly across the workflow, indicating a stable process with appropriate WIP limits. This pattern suggests the team has achieved predictable flow.\nPlateau or Congestion: Aging accelerates sharply at specific workflow stages, revealing bottlenecks or oversized work items requiring decomposition. Research shows bottlenecks occur when a stage\u0026rsquo;s capacity cannot handle incoming workload, disrupting flow and extending lead times.\nWave-like Fluctuations: Periodic acceleration in aging suggests external dependencies or team instability issues. These patterns often indicate work waiting on third-party inputs or resource availability problems.\nExponential Growth: A clear signal of WIP overload, where new tasks start faster than existing ones complete. This pattern indicates violated WIP limits and requires immediate intervention to restore flow.\nTask Decomposition Signals: When aging indicates stuck work items, best practice dictates breaking them into smaller, more manageable pieces. Research confirms that similarly sized work items stabilize flow and improve process metrics.\nSlice work items into smaller (yet end-2-end) pieces\nIntegrating WIP Aging with Other Flow Metrics While WIP Aging provides the most immediate insights, combining it with complementary metrics creates a comprehensive understanding of workflow health.\nLead Time represents the historical Service Level Agreement (SLA)—the total time from customer request to delivery. It encompasses both waiting time and active work time, providing the customer\u0026rsquo;s perspective on responsiveness.\nCycle Time measures only the active work phase, from when a team begins a task until completion. This metric isolates team efficiency from external factors and queue times.\nThroughput quantifies completed work items per time period, directly measuring team delivery capacity. Combined with WIP Aging, throughput helps forecast future capacity using probabilistic methods.\nThe relationship between these metrics becomes clear when considering Service Level Expectations (SLEs). An SLE is a probabilistic forecast—for example, \u0026ldquo;85% of work items will complete in 10 days or less\u0026rdquo;—derived from historical cycle time data. WIP Aging enables real-time comparison against this expectation: if an item\u0026rsquo;s current age approaches the SLE threshold, the team knows it risks breaching their target and can act accordingly.\nPractical Application and Tools Several tools facilitate WIP Aging analysis.\nThe Jira Metrics Plugin is a free Chrome extension that generates aging charts from Jira data\nPredictable.Team provides similar visualization capabilities for both Jira and YouTrack exports (not integrated into Jira directly).\nWhen implementing WIP Aging monitoring, teams should establish clear intervention thresholds. Many organizations use the 85th percentile as a trigger point: when items age beyond this threshold, teams investigate root causes and consider decomposition. For teams preferring conservative planning, the 95th percentile provides a safer target.\nBest practices for WIP Aging management are:\nSetting WIP limits slightly below maximum team capacity to allow flexibility for unexpected work. Starting with team size plus one to team size multiplied by two as a guideline range, then iterating based on results.\nUsing aging data during daily standups to focus attention on at-risk items. This practice transforms standups from status updates to flow management sessions.\nCombining WIP limits with SLEs to create a comprehensive flow management system. WIP limits control input; SLEs establish output expectations.\nBreaking down work items that exceed aging thresholds, particularly those above the 85th percentile. Research demonstrates that similarly sized work items improve flow stability and metric reliability.\nAvoiding rigid enforcement of limits—WIP limits should guide behavior, not create artificial constraints that harm delivery. Context matters: urgent work may justify temporary limit violations if properly communicated.\nThe Cumulative Flow Diagram Perspective The Cumulative Flow Diagram (CFD) provides an alternative view of WIP Aging through workflow visualization. This chart displays time on the horizontal axis and cumulative work item count on the vertical axis, with colored bands representing workflow stages.\nThe vertical distance between a band\u0026rsquo;s arrival and departure lines shows WIP quantity at each stage, while the horizontal distance reveals average cycle time. Parallel bands indicate stable flow; widening bands signal bottlenecks; narrowing bands suggest underutilized resources. The CFD effectively displays three core metrics—WIP, cycle time, and throughput—on a single visualization.\nMoving Beyond Synthetic Data (!) A critical principle when working with flow metrics: never simulate or create synthetic data for analysis or visualization. Fabricated data provides false legitimacy and renders analysis useless. If real data is unavailable, acknowledge this limitation rather than generating representative numbers based on high-level trends. The trustworthiness of flow metrics depends entirely on their foundation in actual workflow data.\nStarting Your WIP Aging Journey For teams beginning flow measurement, WIP Aging offers the most immediate value.\nStart by establishing your workflow boundaries—when does work enter \u0026ldquo;in progress\u0026rdquo; for your context—then begin tracking elapsed time from that point.\nMonitor your aging chart daily, ideally during team synchronization meetings. When items approach or exceed the 85th percentile, investigate causes: Are items too large? Are dependencies blocking progress? Are team members overcommitted?\nAs patterns emerge, your team will develop intuition about healthy versus problematic aging.\nThis understanding enables proactive flow management, preventing issues before they cascade into broader delivery problems. Combined with cycle time analysis for retrospectives and throughput data for forecasting, WIP Aging creates a complete flow measurement framework that drives continuous improvement.\n","permalink":"https://maratkee.com/posts/2025-10-29-boosting-efficiency-with-wip-aging-insights-and-tools/","summary":"\u003cp\u003eWhen examining real workflow data, there\u0026rsquo;s a common pattern: clusters of tasks that have aged significantly, some clearly stagnating beyond \u003cs\u003erecognition\u003c/s\u003e acceptable timeframes. These cases point to one of the most important yet very often overlooked metrics in flow management: WIP Aging.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"/images/photo_2025-10-29-11.15.31.jpeg\"\u003e\u003cimg loading=\"lazy\" src=\"/images/photo_2025-10-29-11.15.31.jpeg\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eWIP (Work In Progress) Aging\u003c/strong\u003e 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.\u003c/p\u003e","title":"Boosting Efficiency with WIP Aging Insights and Tools"},{"content":"TL;DR: Forecasting team Throughput is super-easy and much more reliable than traditional methods, if you limit your work in Progress. Reliability confirmed by research data.\nWe\u0026rsquo;ve already extensively covered Throughput (one of the flow metrics), how to analyze Throughput data from 3 key angles. And why it\u0026rsquo;s better for forecasting than storypoints.\nNow let\u0026rsquo;s get to essentials and practical questions that our management looooves to ask: \u0026ldquo;When will you guys finish this project of X items\u0026rdquo;?\nFoundations of Probability-Based Forecasting Any forecast always involves 3 essential bits:\nProbability\nSpread\nAssumption that future work resembles historical patterns\nSaying “This epic (10 tasks) will take exactly 6 weeks” is misleading. A more accurate forecast: 10 tasks in 5–7 weeks, where:\n5 weeks = 50th percentile (half of runs finish by then)\n7 weeks = 85th percentile (85% of runs finish by then)\nHow Monte Carlo Simulation Works Disclaimer: Here and further on I\u0026rsquo;ll be using charts built with Predictable.team (my vibe-coded react app that visualises and forecasts team performance based on Jira / Youtrack CSVs).\nLet\u0026rsquo;s imagine that we need to understand when will the next 10 items be ready.\n1. Collect historical throughput data\nImagine you have information about how many items your team finishes every day for a consistent period of time. Always count all days, including the ones with 0 deliveries.\nLet\u0026rsquo;s say our dataset is 90 days. A random number should be generated in the range from 1 to 90, because each of those randomly generated numbers represents a day from that dataset.\n2. Run 1,000–10,000 simulated scenarios. For each simulation (code sample below):\nGenerate random number. This random number will represent a day from our stats (one of those 90). Record how many items have been delivered during that day Let's say we got 20, and on 20th day from our dataset we've delivered 1. That means that so far we have 1 item delivered.\nContinue generating random numbers until you get 10 (since we wanted to know when we\u0026rsquo;ll deliver next 10 items).\nVoila, your first scenario is ready. Thousands more to go!\n3. Display a probability distribution of completion times\nTake a look at 50th pp (50% of simulations had 10 items be finished at this number of days or less). You can plan at 50th pp as long as you have WIP limits and control aging within your system. Take a look at 85th pp (85% of simulations show that 10 items would be delivered by that day) 85th pp is a conservative estimate, which strikes great balance between risk and speed. You can also forecast saying 50pp-85pp as a range, since all forecasts have range, probability and assumption that our work would be similar in the future. Example for 10 tasks:\n50% probability: 39 days\n85% probability: 50 days\n95% probability: 58 days\nPresent to stakeholders: “Forecast: it will take 39-50 days.” Using the 85th percentile offers a safer buffer, though planning at the 50th percentile is common practice.\nHigher throughput stability (lower variation) means the 50th and 85th percentiles converge, tightening the forecast.\nAs per David Andersen, proper predictability is 98pp/50pp \u0026lt; 5.6\nFactors Affecting Forecast Quality Task breakdown: End-to-end slices yield better forecasts than component-only slices.\nHistorical window: Avoid using data older than six months.\nZero-throughput days: Include them to reflect weekends, holidays, sick days.\nCalendar vs. work days: Always use calendar days to account for non-working periods.\nAlso: Garbage-in, Garbage-out. If your data is bad, not full\nWIP is essential for reliable forecasting Monte Carlo forecasts require enforced WIP limits. As Daniel Vacanti warns:\n“No WIP limit = no flow, which means no predictability.”\nForecasting should always be updated Run fresh simulations every 1–2 weeks to adapt to changing conditions. Just like during weather forecasts on forest fires, earthquakes, traffic forecasts and other systems, we can\u0026rsquo;t and never will account for all parameters in the equation, hence we need to update our forecasts using our latest data.\nAre there better models than just random MCS sampling? Prateek Singh of ActionableAgile made a research proved that explained here \u0026ldquo;random\u0026rdquo; method actually produces the best forecasting results compared to more sophisticated day-matching algorithms.\nYou can read the research at the link above or watch recent their episode of Drunk Agile (kudos for the guys on that name):\nhttps://www.youtube.com/watch?v=gO3Uw7CG04I\nWhy Throughput Works By the law of large numbers, sufficient throughput history smooths out random variation in work size and type, converging on a stable average performance metric.\nThat\u0026rsquo;s applicable not only in relying on Throughput and forecasting via MCS (Monte-Carlo Simulation), but thinking about outcomes of you DnD fights :)\nNifty things Monte-Carlo Forecasting tools Predictable Team - safe stateless web app. Ingests CSV / XLSX from jira and youtrack. Visualizes Throughput from the file + performs Monte-Carlo Simulation based on your data (When will be project finished, how many items to take in a sprint, when will the epic be done).\nTWIG from Actionable Agile. Super-awesome app that is de-facto industry standard together with getNave. Visualizes metrics + does MCS.\nSome reading references \u0026ldquo;Monte Carlo Simulation Analysis of Team Strategies and Backlogs\u0026rdquo; - Matthew Croker, 2023 - Replication study of Prateek Singh\u0026rsquo;s experiment using 10,000 simulations, showing specialized strategies deliver faster short-term results but generalized approaches prove more effective long-term.\n** **\u0026ldquo;All Models are Wrong, but Some are Random\u0026hellip;\u0026rdquo; - Prateek Singh, 2021 - Back-testing study comparing five different Monte Carlo sampling models, proving simple random sampling consistently outperforms Markov chain and weekday-matching approaches.\n\u0026ldquo;Agile project status prediction using interpretable machine learning\u0026rdquo; - Forouzesh-Nejad et al., 2023 - Achieved 97% accuracy in agile project forecasting using team throughput data, significantly outperforming traditional methods.\n\u0026ldquo;Empirical findings on team size and productivity in software development\u0026rdquo; - Rodríguez et al., 2012 - Large-scale empirical study with 195+ citations analyzing team productivity factors critical for throughput-based forecasting accuracy.\n","permalink":"https://maratkee.com/posts/2025-09-16-monte-carlo-simulation-forecasting-throughput-and-project-timelines/","summary":"\u003cp\u003e\u003cstrong\u003eTL;DR: Forecasting team Throughput is super-easy and much more reliable than traditional methods, if you limit your work in Progress. Reliability confirmed by research data.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"/images/image-10.png\"\u003e\u003cimg loading=\"lazy\" src=\"/images/image-10.png\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eWe\u0026rsquo;ve already \u003ca href=\"https://kiniabulatov.com/2025/09/10/throughput-the-flow-metric-for-team-management/\"\u003eextensively covered Throughput (one of the flow metrics), how to analyze Throughput data from 3 key angles.\u003c/a\u003e And why it\u0026rsquo;s better for forecasting than storypoints.\u003c/p\u003e\n\u003cp\u003eNow let\u0026rsquo;s get to essentials and practical questions that our management looooves to ask: \u0026ldquo;When will you guys finish this project of X items\u0026rdquo;?\u003c/p\u003e","title":"Monte Carlo Simulation: Forecasting Throughput and Project Timelines"},{"content":"Today we\u0026rsquo;ll talk about Throughput metric. Why is it so important, how to read it\u0026rsquo;s patterns and what to be cautious about.\nPremise\nImagine walking into a bar on a Friday evening, exhausted, and ordering a beer flight. The bartender thinks:\n“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.”\nThere are no subjective complexity estimates - only historical data to forecast wait time. Wouldn’t it be great if an IT team could plan as simply, honestly, and predictably? Ha-ha, you wish\nWhat Is Throughput and Why It Matters Throughput is the number of items completed per unit of time. If a team closes eight work items in one week, throughput = 8 items/week. Objective, simple, and tamperable if required (of course you can hack any metric).\nSuper simplified example, 15 user stories completed in two weeks → throughput = 7.5 stories/week.\nThroughput by Bi-weekly intervals (not necessarily sprints). Looks rather steady.\nOther key flow metrics include Cycle Time, WIP.\nThree Views on Throughput Analysis 1. Time Granularity Choosing the right period is crucial for meaningful analysis. Relying on sprint-level velocity yields only ~26 data points per year. This is for two-week sprints. This amount is barely enough for basic trend detection.\nOn weekly periods the Throughput looks slightly different\nWeekly measurements: ~52 data points/year—captures broader trends\nDaily measurements: ~260 data points/year—reveals weekday patterns\nDynamics show that at the very peak days team just closed many items. And all of a sudden it didn\u0026rsquo;t have any flat periods in may (during golden week)\nExample of weekly patterns:\nMonday: 0 items (planning)\nTuesday: 1 item (ramp-up)\nWednesday: 3 items (peak)\nThursday: 2 items (reviews)\nFriday: 2 items (releases)\n2. Variability: A Stability Indicator **Variance example on week of june 2-8. Team is doing +-104% of work from the previous sliding window of 4 previous periods. **\nForecasts require stable throughput. The coefficient of variation quantifies this:\nCoefficient of Variation = (Standard Deviation / Mean) × 100%\n\u0026lt; 15%: very stable\n15–30%: reasonably stable\n30–50%: needs attention\n50%: critically unstable\nExamples:\n“Roller coaster” team: throughput 15 → 2 → 18 → 1 → 16 (87% variation)—uncontrolled process\n“Predictable” team: throughput 7 → 8 → 6 → 7 → 8 (12% variation)—highly predictable\nKeep in mind that smart people (Mr. Vacanti) state, that Throughput data may not be normally distributed. In such cases, the mean might not be reliable. It is sensitive to outliers and skewness. Percentiles, such as the median (50th percentile), are often more robust. The 85th percentile provides better insight into values distribution. They are unaffected by outliers. They can offer a clearer picture of system performance. This makes them more practical for understanding behavior under varying conditions. Therefore, using percentiles is often more informative for non-normally distributed data.\nan example in visualizing percentiles. We can see that on week 27/07/2025-02/08/2025 team\u0026rsquo;s delivered 2.5-5.1 items which is in many cases enough to forecast more realistically than in simple average number\n3. Work Type Distribution Different work types affect throughput. Completing 4–5 large user stories versus 10–15 small bug fixes yields different counts. Analyze throughput by work category to understand these effects.\nIn greenfield projects, before the MVP, the team might gain some throughput of 10-15 items per week. Right before the release, they may have 20-25 items. Most of these are bugs. Throughput is higher, but at what cost? There is less value and more fixing.\nTeam started new phase of their product in Q2. Number of research items (spikes) and stories increased. No. of tech tasks and defects on the other hand decreased.\nEssential Constraints Metrics Don’t Label Teams “Good” or “Bad” In case your work items don\u0026rsquo;t contribute to team/org goals, they are pointless. Metrics must align with team goals. Learn how to tie them together: Product Operations: simple steps to build transparent Feature Pipeline to dramatically lower Lead Time.\nExcellent numeric stability doesn’t guarantee the right outcomes. And vice versa: stable throughput is not necessarily a pattern of a healthy team.\nThroughput is a starting point; balance it with WIP limits, Cycle Time, and qualitative indicators like system reliability.\nAnd here we come to Little\u0026rsquo;s Law, which binds it together.\nLittle’s Law: The Flow Theorem Flow metrics are interrelated.\nLittle’s Law formalizes this:\nLead Time = WIP / Throughput\nWIP: work in progress\nThroughput: completed items per period\nLead Time: time from commitment to delivery\nThis only holds with enforced WIP limits. Without limits, the system becomes chaotic, invalidating forecasts. Please start with at least your current numbers or review how to set up WIP Limits at getNave.\nWhy Story Points Fall Short Ok, let\u0026rsquo;s finally address the elephant in the room! Why the hell do we need the Throughput if we have Story Points?\nThe thing is: Story Points don\u0026rsquo;t really correlate with the Lead Time. This is the time it took for an item to be completed starting from the commitment point. That means that 5 SP often is finished within the time required for 2 SP. And items estimated in 8 SP are inconsistent when we look at the absolute time it took to finish them.\nOne of the researches at University College London (PhD Vali Tawosi, 2023) reviewed 500,000+ items and shown no correlation between Story Points and real time of development. And Daniel Vacanti (the Author of When Will it Be Done?) has a similar case in Siemens.\nThe cherry on top is Vasco Duarte\u0026rsquo;s (NoEstimates book) experiment. He basically asked \u0026ldquo;What will happen with forecasts, if we remove Story Points out of the work items? What will happen, if all of those twos, threes, fives, eights and thirteens would be converted to ones?\u0026rdquo;. Forecasts with Story Points deviated 20% from the final result. Forecasts based on Throughput (Issue Count) deviated only 4%!\nThe main idea is simple. Forecasting based on the number of work items finished gives the same or better result. It requires less effort!\nAs I wrote: Story Points is a great technique to align in understanding work item context during PBR. However, it is less effective for forecasting.\nIn my experience in large Fintech and Digital organizations, Story Points are used by around 50-60% of teams. This is also true in smaller startups. Moreover, all of those teams are using them differently from their original intent. Dedicated Scrum Master or Agile Coach roles could prevent this. But these roles are extremely costly.\nVisualization Tools Jira Metrics Plugin: This Chrome extension provides real-time flow metrics. It hooks up to your Jira in one click. It is safe and secure to use within enterprises.\nPredictable Team: my own Jira/ Youtrack/ Freeflow CSV analyzer with basic flow metrics visualization, recommendation system and Monte Carlo simulator for forecasting\nTWIG by Actionable Agile: Industry-standard tool (VPN required in some regions)\nTeam summary instrument at predictable.team - compare your team\u0026rsquo;s performance within time periods to support data-driven result authorisation and decision making.\nThanks for reading and i hope that was helpful! Cheers mates.\nThis post is also available in ru at Habr.com\n","permalink":"https://maratkee.com/posts/2025-09-10-throughput-the-flow-metric-for-team-management/","summary":"\u003cp\u003e\u003cstrong\u003eToday we\u0026rsquo;ll talk about Throughput metric. Why is it so important, how to read it\u0026rsquo;s patterns and what to be cautious about.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003ePremise\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eImagine walking into a bar on a Friday evening, exhausted, and ordering a beer flight. The bartender thinks:\u003c/p\u003e\n\u003cp\u003e“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.”\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"/images/generated-image-3.png\"\u003e\u003cimg loading=\"lazy\" src=\"/images/generated-image-3.png\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eThere are no subjective complexity estimates - only historical data to forecast wait time. Wouldn’t it be great if an IT team could plan as simply, honestly, and predictably? \u003cdel\u003eHa-ha, you wish\u003c/del\u003e\u003c/p\u003e","title":"3 key data slices to understand your team's Predictability through Throughput (pun intended)."},{"content":"Over seven years of running Story Points workshops, I\u0026rsquo;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\u0026rsquo;t. What\u0026rsquo;s interesting: those 60% who do use them do it completely differently.\nEven 3 months after the training, only 20-30% use Story Points correctly (as intended). The problem isn\u0026rsquo;t the tool itself, but how we use it and what we expect from it.\n1. Without a Scrum Master, Story Points Quickly Degrade The Problem: Story Points are a facilitation tool for discussing complexity, risks, and uncertainty. Without constant coaching, teams start using them mechanically — just to \u0026ldquo;slap a number on it\u0026rdquo; and move on.\nWhat Happens: Teams go through training, estimate tasks \u0026ldquo;correctly\u0026rdquo; for a few sprints, discussing details and identifying risks. Then the process simplifies: people silently assign numbers without asking questions or aligning understanding.\nWhat to Do: If you don\u0026rsquo;t have resources for dedicated Scrum Masters, consider simpler approaches. Flow metrics require less coaching and provide objective data automatically.\n2. Story Points Don\u0026rsquo;t Reflect Real Work Flow The Problem: Even perfectly estimated tasks can get stuck in the system. Backlog items \u0026ldquo;age\u0026rdquo; regardless of their Story Points. A 3-point task might hang in Code Review for a week, while an 8-point task flows through the entire cycle in a day.\nWhat Happens: Story Points estimate task \u0026ldquo;complexity/risk/effort\u0026rdquo; but don\u0026rsquo;t show how work moves through the system. They don\u0026rsquo;t account for bottlenecks, dependencies, priority changes, and other systemic factors.\nWhat to Do: Supplement Story Points with flow metrics:\nCycle Time — time from start to completion\nThroughput — number of completed tasks per period\nLead Time — time from request to delivery\nAging — how long tasks sit in the system\nAll of the dots are 5-Story Point estimated items. Stuck in respective statuses for different reasons.\n3. Story Points Create an Illusion of Precision The Problem: Teams use Story Points for precise short-term forecasts, though they weren\u0026rsquo;t designed for that. Research shows: if you assign \u0026ldquo;1\u0026rdquo; to every task instead of Story Points and count throughput, forecasts are often equally accurate.\nWhat Happens: An average velocity of 20 Story Points doesn\u0026rsquo;t ensure exactly 20 will be done in the next sprint. It\u0026rsquo;s similar to Mike Cohn\u0026rsquo;s basketball example: averaging 98 points per game doesn\u0026rsquo;t promise 98 in the next game.\nWhat to Do:\nFor long-term planning: use average velocity understanding its variability\nFor precise forecasts: statistical methods based on historical data (Monte Carlo simulations)\nFor business answers: honest ranges with probabilities, not exact dates\nExample from one of the teams I worked with. Different colors = different estimations in SP. 1 (red) ,2 (yellow), 3 (green), 5 (blue) ,8 (violet)\n4. Story Points Don\u0026rsquo;t Scale Between Teams The Problem: In large organizations, each team \u0026ldquo;calibrates\u0026rdquo; Story Points differently. One considers 5 SP medium complexity, another considers it high. This makes cross-team performance comparison or product-level planning impossible.\nIt\u0026rsquo;s my perspective from the past jobs when I work at scale: you need to assess the team\u0026rsquo;s predictability. You also need to evaluate their accuracy in planning, and fast.\nWhat Happens: Without unified standards and constant alignment, Story Points become a \u0026ldquo;Tower of Babel\u0026rdquo; — each team speaks its own estimation language.\nWhat to Do: For cross-team planning, use objective metrics: Throughput, Cycle Time, Lead Time. They don\u0026rsquo;t depend on subjective interpretation and provide comparable data. And it would be good to see Planning Accuracy (how has been Completed/Committed rate over the past 6 periods).\n5. Story Points Don\u0026rsquo;t Help Improve the Process The Problem: Story Points don\u0026rsquo;t show where work gets stuck. They don\u0026rsquo;t provide insights for identifying bottlenecks and improving processes. A team can perfectly estimate all tasks while having serious flow problems.\nWhat Happens: Focus on precise estimation distracts from analyzing how work moves through the system. Velocity stays stable, but customers don\u0026rsquo;t get value on time.\nWhat to Do: Analyze work flow using cycle time scatterplots, and aging metrics. This reveals real problems and improvement opportunities.\nPractical Approach: Separating Tools and Goals The problem isn\u0026rsquo;t Story Points themselves, but mixing tools and purposes.\nStory Points — for internal team planning:\nDiscussing complexity and risks within the team\nAligning understanding of tasks\nRevealing hidden assumptions and dependencies\nFlow Metrics — for forecasting and improvement:\nReliable business forecasts\nBottleneck and process problem analysis\nObjective data for decision-making\nEvidence-based approach: As Vasco Duarte states, try both methods for several sprints, compare forecast accuracy. Let data show what works better in your context.\nConclusion Story Points are a valuable tool for teams. They need to be used properly for effectiveness. I still do workshops on them. They are useful and effective for discussion and internal team planning. If your goal is reliable forecasting, flow metrics often deliver better results. They also improve process and scaling with less effort. We\u0026rsquo;ll dig into that in some other post.\nBe honest with business. Instead of false precision, provide realistic ranges with probabilities based on actual data, not subjective estimates.\nWant to compare forecasts based on Story Points vs. flow metrics? Try Predictable.Team — a tool for analyzing flow metrics from your data.\n","permalink":"https://maratkee.com/posts/2025-06-26-5-reasons-why-your-story-points-arent-working-and-what-to-do-about-it/","summary":"\u003cp\u003eOver seven years of running Story Points workshops, I\u0026rsquo;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\u0026rsquo;t. What\u0026rsquo;s interesting: those 60% who do use them do it completely differently.\u003c/p\u003e\n\u003cp\u003eEven 3 months after the training, only 20-30% use Story Points correctly (as intended). The problem isn\u0026rsquo;t the tool itself, but how we use it and what we expect from it.\u003c/p\u003e","title":"5 Reasons Why Your Story Points Aren't Working (And What to Do About It)"},{"content":"(Experience from an AI-Based Fintech KYC SaaS Startup Focused on LATAM and Africa)\nYour 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.\nNot our case though. Our 85th percentile feature lead time (from creation to shipping) was 244 days. That is eight months from idea/proposal to production for most important features. Sales enabled our growth and promised features to close deals, engineering juggled shifting priorities, deadlines were missed. It’s really nothing new in our industry so here’s how we turned the ship around.\nHow We Broke the Cycle: Collaborative STATIK Workshop Ever heard of Kanban-method? It’s a huge topic, but we’ll take the very starting part of applying it. I regularly host meetups on Kanban and metrics, so it’s natural for me to apply the method to anything.\nAt the time I was responsible for Product Ops at Metamap on a quest to create transparent system that helps our org of 500 people work super-aligned. So initiated a Value Stream Mapping workshop with the hint of STATIK (Systems Thinking Approach to Introducing Kanban) workshop. It’s a facilitated session that brought together Sales, Product, and Engineering. Here’s how you do it:\nOrganize a collaborative session in miro/figjam or offline.\nMap out the real workflow of how you ingest feature requests.\nReflect and agree how you evaluate and process Feature Requests at every single stage.\nInclude artefacts, roles, and events required.\nOur key was to understand concerns and work towards mutual goals as one team.\nWe mapped the real workflow. We surfaced pain points. We made visible the choke points that were slowing us down (As Is). Then discussed what adjustments need to be made, for the process to be transparent and efficient (To Be). This collaborative approach ensured everyone-from Sales to IT-understood and trusted the process. Here are the outcomes:\nStep 1: Centralize Requests with a Single Source of Truth Tools: Jira Product Discovery integrated with Salesforce and Gong.\nIntake: Every feature request should have a linked Feature Intake ticket in Jira. You can automate creation from Salesforce or Gong (linked to client deals or call notes), but essentially just make sure that you have required relevant info in your task-tracker: *Linked Client* (Active/Churned/Prospect, synced from Salesforce) Expected ARR Impact (from Salesforce deal size)\nClient Tier (Enterprise, MSME, or high-risk segment)\nLive status: If a client churned, their linked requests were automatically moved to *Parked*. Sales, Product, and Engineering all saw the same real-time status, eliminating shadow requests and misalignment. Note that we used Jira product discovery due to our Engineering using Jira. There\u0026rsquo;s also a neat feature called \u0026ldquo;Insights.\u0026rdquo; You can connect integrations and link where merchants asked for a feature in an Email, Slack, or Salesforce. This provides you with an overview of all requests related to the feature.\nStep 2: Triage with the \u0026ldquo;3x3 Rule\u0026rdquo; A feature advanced only if:\n3+ active or prospect clients requested it Ideally, with an **Expected ARR ≥ $X (you can agree on what an X can be. At the very least it should align with [your ROI calculations](https://kiniabulatov.com/2023/09/20/initiate-data-driven-shift-from-feature-factory-to-product-led-saas-with-an-easy-to-use-feature-roi-check/)).** The logic here is to ensure you filter out small merchants requests. You can review the stats for your company on churn rates for Small, Medium, and Enterprise businesses. This will help you understand why filtering out smaller merchants\u0026rsquo; requests with small ARR is critical. Direct alignment to at least one North Star Metric (NSM) How it worked:\nWeekly cross-functional triage meetings for reviewing Inflowing Feature Requests (Sales+Marketing, Product, IT)\nFeatures scored with ICE (Impact, Confidence, Ease) - but\nIf a feature failed any rule, it was parked or dropped\nSurely there are exclusions - e.g. it's a huge enterprise unlocker for us, even at negative ROI, but this should happen rarely - no more than once in 5-6 months) This helped Sales to quantify value and ensured IT only worked on what truly mattered for growth and retention.\nStep 3: Visualize and Govern with Throughput Metrics Key metrics:\nThroughput: Features shipped per month.\n85th percentile lead time: Tracked and shared (goal: ≤90 days - since we lived in Quarterly Planning Roadmaps)\nNSM-aligned work: Target ≥70% of shipped features\nHow we governed:\nWork-in-Progress (WIP) limits: No more than 2 features per team (cross-functional 7-9 person) at a time\nReal-time analytics: Stats on throughput and utilization of team\u0026rsquo;s resources were visible to everyone. This visibility showed how new requests would affect delivery timelines.\nThis transparency enabled honest trade-offs: if someone wanted a new feature, they saw what would be delayed or dropped. Data clearly helped us to see that Engineering can process only 1/4th of Feature Inflow. That gives you great leverage. You can prioritize what’s really moving the needle for our Product Goals. This includes not only finance metrics but also our longer-term vision.\nWe used T-Shirt sizes and feature lead time to understand which capacity we had, but there are plenty other options.\nStep 4: Validate Before You Build There are plethora of methods, but I find the easiest ones are:\nFake Door Tests: Add a button or UI element to gauge client interest before building the full feature\nConcierge MVP: Manually deliver the feature for a few clients to confirm value\nMain point is features should be only moved to development after validation with real clients. If a client churned during validation, the feature should be dropped or de-prioritized.\nStep 5: Post-Launch Accountability Every feature had a field with when it\u0026rsquo;s expected to generate desired outcome. General idea was to prove its impact within 90 days of release, although enterprise deals can take 180-240 days to ratify:\nAdoption rate: Did clients actually use it?\nEffect on NSM: Did it move retention, revenue, or product metrics?\nClient feedback: Were there measurable improvements in satisfaction or churn?\nFeatures that failed to deliver impact were sunset or re-evaluated. Because supporting them also requires hefty dev + CSM effort.\nWe reviewed our Feature Outcomes at Monthly Business Reviews (MBR) and Quarterly Business Reviews (QBR). We assessed how each feature contributed to our OKRs.\nThe Results: Trust, Speed, and Predictability 85th percentile lead time: Dropped from 244 to 93 days-now features could reliably (welp, more or less :) ship within a quarterly planning cycle\nTransparency: Sales, Product, and Engineering shared a single view of priorities, status, and trade-offs\nAlignment: 76%+ of shipped features were directly tied to North Star Metrics and active client demand\nTrust: Sales stopped overpromising, and IT regained confidence and morale\n3 Rules for Building Trust and Speed Integrate your systems: Connect Salesforce, Gong, or whatever you use to your ticketing system. This could be Jira or some other stack. This integration ensures client status and value are always visible and relevant.\nEnforce prioritization discipline: Only build what’s validated by multiple clients and aligned to your North Star. We often focus too much on building what clients want. This can move us further away from Strategic Vision. Retail the balance.\nMeasure relentlessly: Track throughput and lead time, and make the numbers visible to all. It removes emotions and assumptions, helps to build data-driven culture.\nYour First Step Audit your current feature pipeline:\nHow many requests are tied to active, high-value clients?\nWhat’s your real 85th percentile lead time?\nAre Sales and IT working from the same source of truth?\nIf the answers are uncomfortable, you’re not alone. But you can fix it-one step at a time. You can review your data from jira or any other system using https://predictable.team — an app designed to give you insights on your team’s performance.\n","permalink":"https://maratkee.com/posts/2024-05-07-the-go-to-workflow-for-feature-requests-that-builds-trust-and-cuts-lead-time-by-4x/","summary":"\u003cp\u003e\u003cem\u003e(Experience from an AI-Based Fintech KYC SaaS Startup Focused on LATAM and Africa)\u003c/em\u003e\u003c/p\u003e\n\u003ch3 id=\"your-regular-challenge-when-sales-marketing-and-it-speak-different-languages\"\u003eYour regular challenge: When Sales, Marketing and IT Speak Different Languages\u003c/h3\u003e\n\u003cp\u003eOur \u003ca href=\"http://metamap.com/\"\u003eSaaS startup\u003c/a\u003e served emerging fast-paced fintech markets (it still is). Speed + compliance were \u003cmark\u003eexistential. 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. \u003c/mark\u003e\u003cmark\u003e\u003cstrong\u003eSo you need to be super frugal and efficient.\u003c/strong\u003e\u003c/mark\u003e\u003c/p\u003e","title":"Product Operations: simple steps to build transparent Feature Pipeline to dramatically lower Lead Time"},{"content":"The startup scene in 2022 and 2023 has been tough. This \u0026ldquo;Startup Winter\u0026rdquo; has seen less funding, many layoffs, and startups closing down. The hopeful times of 2020 and 2021, driven by big investments, feel far away now. Add to this the global events and banking decisions, and we\u0026rsquo;re in a tricky spot.\nI\u0026rsquo;ve helped startups for 10 years, and one thing is clear: now isn\u0026rsquo;t the time to just keep making new features. Look at fintech and other SaaS areas. A startup that keeps adding features for every small need is very different from one that focuses on the big needs and does them really well. In these tough times, guess which one stands strong (spoiler: neither, but second is more sustainable)?\nThe Problem with Just Making More Features\nRecently, many SaaS businesses, including fintech, became feature factories. They kept making new features, but many of these weren\u0026rsquo;t even used or took too long to check. The idea was: \u0026ldquo;more features = more value.\u0026rdquo; But smart tech leaders know this isn\u0026rsquo;t always true.\nTech Leaders often fall into the trap to make your engineering work better, deliver faster. But, it\u0026rsquo;s a problem if you only improve one department and miss the big picture (which is called Local Optimisation in Systems Thinking). It\u0026rsquo;s like giving a car a new paint job while not changing the oil inside the engine. It might look good for a bit, but it won\u0026rsquo;t last.\nUsing Product Leadership to Guide Engineering\nBeing smart with money doesn\u0026rsquo;t mean cutting corners or outsourcing all the time. It means using your resources, like engineering, in the best way. This means focusing on big product goals, not just single features. And aligning of distributed teams with unified goals is super important, because as you roam over the globe when collaborating - context and end value is easily lost in communication (cultural, async, indirect).\nI\u0026rsquo;ve worked with tech leadership within the last couple years to move in this direction. We\u0026rsquo;ve come up with simple tools to check how features are doing and if they\u0026rsquo;re worth the money spent. Here are two main tools:\n1. Feature ROI Check: This tool helps you see how your features are doing out in the real world. For each feature, you can see:\nHow much you spent to make it.\nWhen it was released.\nHow customers interact with it.\nHow many new customers it brings in.\nIf it helps sell more.\nIf it impacts your yearly income.\nHow many users are using it and how they use it.\nImagine you\u0026rsquo;re deliberating on introducing a new feature to provide Automatic Fraud Evaluation for new Contracts. Sure, it sounds fantastic on paper. However, what if, after the feature’s deployment, the adoption rate is significantly lower than the projected number? Wouldn’t it be prudent to have these insights sooner, to pivot or optimize accordingly?\nWith this tool and information, you can see which features are really helping your business. The simplicity of this approach removes complexities, such as ARR Projections usually gaining traction within a year+ (especially for enterprise clients). However, nothing prevents you from keeping track of ROI so far, Quarter-on-Quarter.\n2. Engineering Cost Check: This calculator provides a detailed breakdown of the investments behind each feature. It evaluates: (1) The upfront technical investment, which encompasses development hours, resources used, and any third-party tools or services acquired specifically for the feature. (2) Time, measured by the date of the feature\u0026rsquo;s release and the total duration from inception to launch. (3) Resource allocation, including both human and technological resources. (4) Effort, which includes dev-days, and any additional support and enablement to bring the feature to fruition. I\u0026rsquo;m using industry-standard ratio of QAs, DevOps, Managers per Developers. But your company may have it different, so feel free to change that!\nThe logic of this calculator is to combine these factors, offering an overview of the total cost to develop a feature. This calculated total then is used to evaluate the ROI by comparing it against the feature\u0026rsquo;s revenue generation or other success metrics.\nClick here to navigate to Simple ROI Calculator, and Engineering Cost Calculator. Each field comes with the note and explanation, to help you. This would give you solid data to talk to your team and make smart choices. For example, if a feature to make online payments easier has low interest after some time, you need to think about why.\nMoving Forward\nBecoming product-led is tough. Your product and sales teams might not like the changes, and may not be aligned with Product Vision. Top-level leaders might have different ideas and steer the wheel (or OKRs) into different directions. But it\u0026rsquo;s important to think beyond just making more features. For startups, especially in changing areas like fintech, every decision must make sense. Every feature should have a clear purpose, and all decisions should be part of a big plan.\nAs we hope for better days after the Startup Winter, let\u0026rsquo;s be smart. Not just by saving pennies but by making smart choices with what we have and lead with solid products, backed by real data and a clear goal.\n*All company names are coincidal. *\n#okr #featurefactory #productops #mbr #qbr #startups #fintech #saas #venture #vc #winter #budgeting #roi #engineeringcost\n","permalink":"https://maratkee.com/posts/2023-09-20-initiate-data-driven-shift-from-feature-factory-to-product-led-saas-with-an-easy-to-use-feature-roi-check/","summary":"\u003cp\u003eThe startup scene in 2022 and 2023 has been tough. This \u0026ldquo;Startup Winter\u0026rdquo; has seen less funding, many layoffs, and startups closing down. The hopeful times of 2020 and 2021, driven by big investments, feel far away now. Add to this the global events and banking decisions, and we\u0026rsquo;re in a tricky spot.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"/images/image-1.png\"\u003e\u003cimg loading=\"lazy\" src=\"/images/image-1.png\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;ve helped startups for 10 years, and one thing is clear: \u003cstrong\u003enow isn\u0026rsquo;t the time to just keep making new features\u003c/strong\u003e. Look at fintech and other SaaS areas. A startup that keeps adding features for every small need is very different from one that focuses on the big needs and does them really well. In these tough times, guess which one stands strong \u003cem\u003e(spoiler: neither, but second is more sustainable)\u003c/em\u003e?\u003c/p\u003e","title":"Stop being a \"Feature Factory\", you can't afford it! Shift to Product-Led SaaS with an easy-to-use Feature ROI check"},{"content":"My latest tenure of 2.5 years is closely related to Designing and Adopting Incident Management Framework (as part of Program Management org). This activity was driven with two primary objectives in mind:\nReach and maintain system uptime of 99.99% (our APIs and SDKs).\nEnsure engineering is always firsthand source of information for any potential outage that can result in downtime.\nIn our foundational days, we lacked a comprehensive alerting and monitoring system. Establishing the Network Operations Center (NOC) Team was our strategic move to shape a robust system and take charge of Incident Management. We not only touched the 99.98% uptime benchmark but also heightened our proactivity from spotting 60% of incidents ahead of our merchants to a resounding 95% and higher.\nThis post is about the core set of metrics for the Network Operations Center team, with its relation to Incident Management Process. Together with common anti patterns, and measures for improvement.\nMetrics that Steered Our Success and Measures to Improve Them\n1. First Time to Respond\nContext: Rapid response times can make or break product reliability.\nIndustry Standard: 10-15 minutes.\nOur Vector: An ambitious SLA of 1 minute.\nAntipatterns: Over-optimizing can stretch the NOC team thin. Sometimes, it\u0026rsquo;s wiser to slightly breach SLA and strategize better future responses.\nImpact: A delayed response can seriously impair the product\u0026rsquo;s dependability.\nMeasures for Improvement: Regularly refining our alert sources. The optimal range is 3-5 sources. This involves identifying system bottlenecks, monitoring typical patterns around these, and continuously refining our alerting mechanism to reduce false positives and consolidate dashboards.\n2. Time to Acknowledge\nContext: The initial acknowledgment sets the path for problem assessment and repair strategies.\nIndustry Standard: 10-15 minutes.\nOur Vector: A 3-minute SLA.\nImpact: The acknowledgment speed directly correlates with user trust.\nMeasures for Improvement: Similar to the first metric, we focused on refining our sources of alerts, ensuring that the NOC team isn\u0026rsquo;t overwhelmed with too many data points.\n3. Time to Assemble\nContext: Quick and appropriate team assembly means faster problem-solving.\nIndustry Standard: 30-45 minutes.\nOur Vector: A 15-minute SLA.\nAntipatterns: Summoning any team, rather than the right one, can be detrimental.\nImpact: Swift and relevant team assembly leads to efficient problem resolution.\nMeasures for Improvement: Establish clear escalation paths and alert tags. Automation, using tools like PagerDuty with Jira, is essential once alerts have clear ownership and false positives are minimized; Regular training and drills to ensure the team is always prepared. Involving the team in decision-making processes also provides a fresh perspective on the framework.\nhttps://giphy.com/gifs/the-avengers-chris-hemsworth-jeremy-renner-rj12FejFUysTK\n4. Proactive Engineering Detection Rate\nContext: Understanding issues even before they manifest as incidents ensures a platform\u0026rsquo;s reliability.\nOur Metric: The percentage of times engineering identified potential issues before they became incidents, against those reported externally.\nPatterns \u0026amp; Impact: A low percentage (\u0026lt;80% for downtime-related incidents) indicates a reactive approach. High proactiveness, as evidenced by our journey assured platform reliability.\nMeasures for Improvement: Fine-tuning alerting and monitoring, and maintaining transparency and feedback loops with customer-facing teams.\n6. Number of Critical False Positives\nContext: False positives can drain the productivity and morale of the NOC team. They detract from real issues and can potentially desensitize the team to genuine threats.\nOur Metric: At the outset, we grappled with an astounding 40% of critical alerts being false positives. Our relentless push brought this down to a mere 5%.\nAntipatterns: Over-alerting can spread the NOC team too thin, with a risk of missing a genuine alert amid the noise.\nImpact: Lowering the false positive rate paves the way for scalable and effective automation. A high rate can not only impede automation but also compromise the quality of incident responses. The alert fatigue can cost fintech platforms like ours, similar to Stripe, Plaid, or Square, dearly in terms of both platform reliability and team morale. False positives in alerting might seem innocuous, but they can slowly erode the efficiency of your response mechanism. A disciplined and data-driven approach, much like the one we practiced, can turn this around. It\u0026rsquo;s not just about the quantity of alerts but the quality, ensuring each alert is actionable, relevant, and steers the platform away from potential disruptions.\nMeasures for Improvement: We embraced a weekly rigorous analysis of all alerts and escalations. Each stage of the alert funnel was scrutinized to ensure that every alert served a genuine, preventative purpose against potential incidents. This consistent refinement not only brought down false positives but also refined our entire incident management strategy.\nConclusion\nMetrics are more than mere numbers; they\u0026rsquo;re the compass guiding our path to excellence. Within Fintech-domain, serving millions of users these metrics and our proactive steps have been instrumental in delivering a platform that users trust implicitly. Building isn\u0026rsquo;t just enough; it\u0026rsquo;s about crafting with insight, dedication, and continuous learning.\n#okr #incident #framework #noc #networkoperationscenter #uptime #outage #alerting #monitoring #management #programmanagement #devops\n","permalink":"https://maratkee.com/posts/2023-09-19-5-essential-noc-metrics-to-reach-high-uptime-and-detect-potential-outages/","summary":"\u003cp\u003eMy latest tenure of 2.5 years is closely related to Designing and Adopting Incident Management Framework (as part of Program Management org). This activity was driven with two primary objectives in mind:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003eReach and maintain system uptime of 99.99% (our APIs and SDKs).\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eEnsure engineering is always firsthand source of information for any potential outage that can result in  downtime.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eIn our foundational days, we lacked a comprehensive alerting and monitoring system. Establishing the Network Operations Center (NOC) Team was our strategic move to shape a robust system and take charge of Incident Management. We not only touched the 99.98% uptime benchmark but also heightened our proactivity from spotting 60% of incidents ahead of our merchants to a resounding 95% and higher.\u003c/p\u003e","title":"5 essential NOC Metrics to reach high uptime and detect potential outages"},{"content":"\nOver the past 2 years, I\u0026rsquo;ve been working as Program Management lead at Metamap.com, helping to set up OKR framework among other things. As challenging as just working with OKRs is, we are a distributed team, spanning from PH / SG to the very west coast and even Hawaii :)\nThe common issues we\u0026rsquo;ve found and discovered led me to creating this blog post. So without further ado, It\u0026rsquo;s time to delve into the captivating world of OKRs - Objectives and Key Results. These are the guiding stars that lead your organization to its true north. Embarking on this journey can sometimes make you feel like you\u0026rsquo;re treading choppy waters. In today\u0026rsquo;s post, we\u0026rsquo;ll chart a map of these common pitfalls and equip you with an Agile compass to help navigate with confidence.\nOKRs: Refresher Just to ensure we\u0026rsquo;re all aboard the same ship, let\u0026rsquo;s quickly recall that OKRs comprise two main elements: Objectives – your ambitious goals, and Key Results – concrete, measurable steps to reach those goals. Sounds simple, but as anyone who\u0026rsquo;s navigated a maze will tell you, the reality can be trickier.\n1. Lack of Understanding and Training: Picture this: A soccer team trying to score a goal, but half the players think they\u0026rsquo;re playing basketball. The result? Chaos, and certainly no goals scored. An unfamiliarity with OKRs can lead to a similar mismatch in your organization.\nSolution:\nOrganize detailed training sessions explaining the OKR framework.\nExplain the difference between Objectives (qualitative goals) and Key Results (quantitative measures).\nBring or be an OKR coach to guide your team, explaining how to formulate effective OKRs.\nConduct workshops with hands-on exercises for creating and aligning OKRs.\nShare examples of successful OKRs from other organizations for reference.\n2. Misalignment of OKRs: Imagine a choir where each member sings a different song. The result? A far cry from harmony. Misaligned OKRs can create a similar dissonance in your organization.\nSolution:\nUse Scrum Events or Agile ceremonies like sprint planning and retrospectives to align OKRs.\nDuring sprint planning, ensure each team\u0026rsquo;s OKRs align with the company\u0026rsquo;s main objectives.\nIn sprint Reviews, review OKR performance and realign as necessary.\nEncourage cross-departmental communication to avoid working in silos. Try having multiple-team Sprint Review, where each measures their contribution towards the Key Result!\n3. Setting Unrealistic Key Results: We all love superheroes, but expecting to fly like Superman is unrealistic (unless you\u0026rsquo;re wearing a VR headset!). Similarly, Key Results that aim for the moon without a rocket can leave teams feeling disheartened.\nSolution:\nUse Agile\u0026rsquo;s principle of incremental progress.\nSet smaller, achievable Key Results aligned with each sprint goal.\nMeasure progress after each sprint, adjusting targets as necessary.\nEnsure teams have the necessary resources and support to meet their Key Results.\n4. Overcomplicating OKRs: Ever tried to solve a Rubik\u0026rsquo;s cube while bouncing on a pogo stick? It\u0026rsquo;s overwhelming! Similarly, complex or excessive OKRs can feel like juggling flaming torches.\nSolution:\nKeep OKRs simple and lean, following the Agile spirit.\nLimit the number of OKRs for each team to keep focus sharp.\nMake sure each Key Result is specific, measurable, and time-bound.\nReview and simplify OKRs regularly to ensure they remain manageable and meaningful.\n5. Poor Communication and Transparency: Imagine playing a game of telephone with a 5-meter long tin can string. The message is going to get a little garbled, right? Poor communication can lead to similarly distorted OKRs.\nSolution:\nLeverage Agile communication practices such as daily stand-ups and sprint reviews.\nUse these platforms to discuss OKR progress and address any issues.\nMaintain a transparent OKR dashboard where everyone can see each team\u0026rsquo;s Objectives and Key Results.\nEnsure leaders actively participate in OKR discussions, providing clarity and encouragement.\nThere you have it! Remember, every journey encounters a few storms, but with the right Agile compass, your OKR ship can weather any challenge. Keep sailing, and soon your organization will shine like a polished gem!\nI\u0026rsquo;d would love to hear about your OKR journey. Have you faced any of these challenges? How did you steer your ship back on course? Share your experiences in the comments section!\nUntil our next adventure, keep your sails high, and navigate with confidence! Happy OKRing, folks!\n","permalink":"https://maratkee.com/posts/2023-06-22-navigating-okr-challenges-common-pitfalls-and-agile-solutions/","summary":"\u003cp\u003e\u003ca href=\"/images/image.png\"\u003e\u003cimg loading=\"lazy\" src=\"/images/image.png\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eOver the past 2 years, I\u0026rsquo;ve been working as Program Management lead at Metamap.com, helping to set up OKR framework among other things. As challenging as just working with OKRs is, we are a distributed team, spanning from PH / SG to the very west coast and even Hawaii :)\u003c/p\u003e\n\u003cp\u003eThe common issues we\u0026rsquo;ve found and discovered led me to creating this blog post. So without further ado, It\u0026rsquo;s time to delve into the captivating world of OKRs - Objectives and Key Results. These are the guiding stars that lead your organization to its true north. Embarking on this journey can sometimes make you feel like you\u0026rsquo;re treading choppy waters. In today\u0026rsquo;s post, we\u0026rsquo;ll chart a map of these common pitfalls and equip you with an Agile compass to help navigate with confidence.\u003c/p\u003e","title":"Navigating OKR Challenges: Common Pitfalls and Agile Solutions"},{"content":"Hey everyone, here\u0026rsquo;s my list of resources and literature for getting prepped for the PSM II examination. I would be tremendously happy if you share yours :)\n*Sidenote: if you are \u0026ldquo;certificates are overvalued\u0026rdquo; type of person - I\u0026rsquo;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 \u0026ldquo;shu\u0026rdquo; (of shu-ha-ri), just your experience and daily understanding of agile values. *\nBy the time I write this post, there are 6793 PSM II holders.\nPreparation for PSM II As Denis @ Agile Expat wrote in his blog in russian, it would be a great starting point to pass scrum.org open assessments at 100% before getting to PSM II exam:\nPSPO open - because there are questions related to an understanding on how to coach PO and how to work with value. (might I say that you can easily pass PSPO exam in case you\u0026rsquo;ll pass PSM II) PSM I - since you MUST know everything in it by heart. Values, roles, events, artifacts. PAL-E - so that through coaching you could understand higher management, metrics, organizational maturity. PSK open - foundations of working with the flow. Nexus open - foundations of official scrum.org scaling solution, although not the most popular one. Other tests should be treated with the grain of salt. The internets provide you with a wide variety of preparational test suites: some of them are more oriented for passing PMI-ACP (and are overall PMBoK-skewed); other ones should be avoided at all costs as they mutilate the very basic principles of scrum and sabotage your preparation - stay aware.\nCoaching, books, training Lyssa Adkins: Coaching Agile Teams - rather easy-to-read and universal cookbook for Scrum Master\u0026rsquo;s stances of an agile coach, facilitator, teacher. It perfectly complements your personal experience.\nThere\u0026rsquo;s a small section on conflicts, which I find useful (in case you don\u0026rsquo;t want to dive deep into the science of conflicts). By the way, the book in my experience is greatly enhanced by ICAgile: ATF (Agile Team Facilitator), ICAgile ACC (Certified Agile Coaching) training courses.\nA lot of reviews mention that the book is giving you nothing, in particular, it\u0026rsquo;s dull. I would argue that it works perfectly when it comes to your personal experience context.\nGunther Verheyen\u0026rsquo;s Scrum Pocket Guide - must-read-and-re-read book, that you get back to rather frequently. It covers and decomposes agile principles, scrum events, roles, and artifacts. You can\u0026rsquo;t pass the exam for PSM II if you don\u0026rsquo;t know Scrum Values and Agile Principles. You must be able to reel it all off! So truly a pocket guide for any occasion. The Scrum Master Way by Zuzana Sochova. Professional development vectors for SM, different stances for SM. Scrum master\u0026rsquo;s service to an organization -\u0026gt; all is found here.\n**8 stances of a **scrum master is a whitepaper from Barry Overeem about the stances that SM can be. It\u0026rsquo;s a treasure chest for fruitful answers to PSM II questions. And a treasure chest for your self-reflecting scrum master-career. Because it\u0026rsquo;s essential to understand what stances are correct, and what\u0026rsquo;s unexpected. And when unexpected stances happen, there is a disconnect between what an organization wants, and what Scrum Guide tells us to do :)\nSerious Scrum blog - collaborative blog from industry experts, with a lot of cases and solutions for situations far from trivial.\nActionable Agile Metrics - great to read a book about metrics.\nLiberators whitepaper on scrum - oh you know those guys are not only people behind PSM II training design but also have their own visual and vivid way of explaining complex things in an easy and engaging way.\nTrainings - even on some basic level you should personally try the teacher\u0026rsquo;s stance of the scrum master: as a teacher on team, individual or organizational level. It doesn\u0026rsquo;t matter whether you are doing a workshop on flow visualization, helping with pair debugging / mob debugging for DevOps team, or teach scrum basics for a couple of hours. What matters is that you gain experience \u0026amp; understanding of how agile values develop and appear through day-to-day actions, how teams behave in different situations, and that during the training you get feedback loop on all of that much faster.\nCynefin I personally think that it\u0026rsquo;s important to be introduced to Dave Snowden\u0026rsquo;s framework on decision-making across different types of systems. There are no silver bullets, and scrum is not one.\nLong Story Short: there is an algorithm of making a decision depending on system complexity. And Dave Snowden of Wales perfectly explained it (well, still works on decomposing and explaining) bit by bit. And when you learn the foundations there is yet another level deeper: categorization inside of a chaotic quadrant. Whoa, whole new microworld awaits.\nRead more here (post) \u0026amp; and here\u0026rsquo;s the video from Snowden himself .\nTechnical Excellency Foundations This is rather huge topic, that closely entwines with Continuous Improvement -\u0026gt; engineering practices that help develop / build processes and distribute knowledge more efficietly. Pair programming, mobbing, TDD, dealing with technical debt - it all falls into technical excellency foundations.\nZillions of blogs (Kent Beck, for example, you know him right? :)), Scrum \u0026amp; XP from the Trenches by Kniberg (which I like for his real-life simple examples), Extreme Programming Explored (good, but not godlike), Books by Martin Fowler, if you want something more technical, Uncle Bob and his books, like Agile Development, where he links Agile Values and development practice. I don\u0026rsquo;t think you need that much of a literature. The one and only take here: you need to understand different engineering practice approaches from the angle of agility and how deep they inherit the very core of Agile-manifesto principles. Just to reiterate: no need for knowing all the bits, just Agile-values at the very core. (btw, almost anything common-sense-related revolves around them anyway).\nDevOps You need to understand the mindset. That automation and packing routine things into templates that are not dependant on possible human factors is how you can mitigate risk. Familiarize yourself (and if you\u0026rsquo;re working in IT you most likely know this, especially if you\u0026rsquo;re going to pass PSM II) with Continuous Delivery, Deployment - all that stuff. A note though: often an organization utilizes DevOps specialists as a separate team. Don\u0026rsquo;t forget that DevOps is about a mindset, not a team of SysAdmins-on-steroids. When it comes to Agility, we always link this mindset as a way to expand the development team\u0026rsquo;s cross-functionality. DevOps mindset across software engineers (it\u0026rsquo;s called Dev+Ops for a reason, right) is a horizon-broadening opportunity to gain new experience, learn more optimal paths to deliver the best value for the beloved customer. Separate DevOps teams are more of a step back to functional silos and component teams. Better augment DevOps engineer within each feature team, or up the skills of the development team itself.\nAll in all, just as with any engineering practice, I urge you to just see the source of agile thinking principles and empiricism. Any iterative process, that is followed by analyzing how to become better, plans this improvement and implements it is good. It\u0026rsquo;s always great to automate the routine and make it foolproof. And the sooner we see issues - the better.\nRead and agree on how close this post is to agile manifesto in it\u0026rsquo;s core\nEvidence-Based Management Evidence-Based Management.\nYou shouldn\u0026rsquo;t wait for any complex questions on EBM, because scrum.org just recently published a guide related to this topic. This is about working with metrics and understanding company positions across the market. I think if you visited any pieces of training on Business Agility from ICAgile, or just coach management/organizations for Business Agility / or simply familiar with the topic, it should be pretty straightforward. In a nutshell, EBM attempts to answer questions such as how to effectively measure team improvement, delivery time, and relate this with market niches and potential lost profit. Maturity-models You certainly don\u0026rsquo;t need to know PALe maturity canvas by heart, not precisely that scale yet for PSM II. However, it would be amazing that by the time you get to passing PSM II / A-CSM you overall get an understanding of Maturity-models (KMM, Scrum Maturity Model, Agile Leadership Maturity). This will help to map your organization on maturity canvases - it\u0026rsquo;s always great to self-reflect :) If you\u0026rsquo;re familiar with spiral dynamics - it kind of also (IMO) nicely adds up to the understanding company\u0026rsquo;s agility and survivability agenda. Kanban-practices Kanban for Scrum Teams (here\u0026rsquo;s the guide from the last year), or in my case KMP II helped a lot (thanks to my trainers Alexey Pikulev and Alexey Pimenov of RealResult). You need to understand principles of working with the flow, why WIP limits are important, the value of finishing started work first, and the harms of 100%-utilization.\nIn today\u0026rsquo;s world (IMO) there\u0026rsquo;s a trend of taking a system approach. In my opinion, right now it\u0026rsquo;s not incorporated at the very heart of scrum officially (well, it\u0026rsquo;s a framework and it doesn\u0026rsquo;t mandate which particular things to use, apart from what\u0026rsquo;s in scrum guide), unlike at Kanban it\u0026rsquo;s lives in the very core. What I mean is that you need to understand the value of system thinking, system approach, the theory of constraints, queueing theory, downsides of local optimization. By the way, Kanban formally familiarizes you with Cycle Time, Lead time metrics, Cumulative Flow Diagram, Spectral Analysis Chart reading. This is beneficial, cause, in reality, zillions of teams just use burndown as the holy source of how well they are performing, while the toolbox of charts and instruments should be constantly expanded.\nYou\u0026rsquo;d also be familiar with some of the terms if you played featureban / getKanban / changeban - Kanban simulation games. Scaling frameworks: Less, SAFe, Nexus (well, and DaD for some :) Nexus (and the guide) knowledge is needed as the least minimum, and there are resources available from scrum.org itself. All in all, I find Nexus the easiest to understand given that it\u0026rsquo;s the same scrum, but with small additions. SAFe - you need to be introduced with the framework (on the level of videos with explanations) because this is the most popular Enterprise Agile framework in the world. LeSS / LeSS Huge - because this is something much more lightweight than SAFe, and at the same time much more popular (than Nexus). It\u0026rsquo;s an intuitive framework without many roles, with the very same values as in Scrum at the very heart. DaD (Disciplined Agile Delivery) - if you live in PMBoK world that recently transitioned into the Agile domain through connecting via Scott Ambler\u0026rsquo;s framework :)\nNote: as per Nexus, scaling starts at 2 or 2+ teams.\nI personally don\u0026rsquo;t have a lot of experience with scaling, thus would finish with this section.\nLast, but not least Experience, experience, and only experience: the understanding and practice of creating Sprint Goal, forging Definition of Done, understanding what\u0026rsquo;s meant with Definition of Ready (although it\u0026rsquo;s not an official terminology). How to work with teams in creating those helpers for artifact transparency.\nThe same applies to scrum events, why and how to facilitate, who can attend, which event provides formal opportunities for certain things.\nIt\u0026rsquo;s important to know approaches to order items in backlog (starting from 2017 guide). Ordering (not prioritizing). Because an item with first maximum value in many cases needs to be unblocked first, and this blocker may be lower in value -\u0026gt; hence the ordering. A note on certified training for PSM II (you still need to pass the exam, training is not the requirement) If you need to order your knowledge, or you just want to network and discuss a lot of cases with your trainer - you\u0026rsquo;re welcome. In a nutshell training for PSM II is systematization of everything that you\u0026rsquo;ve already faced in your day-to-day scrum master routine if:\nYou have 2+ years working as a scrum-master You have experience working with conflicts You\u0026rsquo;re experienced in facilitating agile-events and meetings You can explain how Agile-principles and Scrum Values are working out in real life Basically, you remember what Scrum Guide says through your own experience, and in addition cover the basics for metrics, Evidence-Based Management, coaching, and facilitation, working with conflicts, proper and fake stances of a scrum-master, and scaling frameworks. In case it\u0026rsquo;s a good trainer you also get familiarized with Liberating Structures and dive into Kanban basics.\nThis all is great, fun and very productive, cause you usually cover real-life cases for 70-80% of the time. But the training is not a required step towards the exam, and it doesn\u0026rsquo;t give you any perks for having a lower passing score or anything like that. Experience is the ultimate perk.\nExam itself A page for getting the exam attempt: https://www.scrum.org/professional-scrum-master-ii-certification\nPrice, time, passing score are the same: $250, 90 min, 85%. There\u0026rsquo;s more than enough time, and since 2018 the test became easier. Personally, I passed it to 97%, with one mistake.\nPhew, hope that my post helps you. Be confident and remember about agile values! There\u0026rsquo;s nothing extraordinary in this exam!\n","permalink":"https://maratkee.com/posts/2020-06-01-preparing-to-psm-ii-professional-scrum-master-certification/","summary":"\u003cp\u003eHey everyone, here\u0026rsquo;s my list of resources and literature for getting prepped for the PSM II examination. I would be tremendously happy if you share yours :)\u003c/p\u003e\n\u003cp\u003e*Sidenote: if you are \u0026ldquo;certificates are overvalued\u0026rdquo; type of person - I\u0026rsquo;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 \u0026ldquo;shu\u0026rdquo; (of shu-ha-ri), just your experience and daily understanding of agile values. *\u003c/p\u003e","title":"My experience in preparing to PSM II (Professional Scrum Master) certification"},{"content":"Last week me and Alex Pikulev of Agilix recorded Trust Stories podcast episode, on Growing Team Trust in Distributed Teams. Courtesy of In Teams we Trust website\nhttps://www.youtube.com/watch?v=Pq82aFap1rc\nMain bullets are: Growing trust in distrubited teams is hard, but nevertheless as important as in co-located team. Team itself creates an atmosphere of trust in itself. Our task, as a scrum master, coach, manager - is to help and highlight needed areas. XP and especially Pair Programmingи helps in growing trust. Intrateam trust, from the informal side (skype beers, navigating as a guest to your colleagues in other locations, bike fixing via the webcam, ordering stuff on flea market in your city and sending it over to a colleague) helps a lot. More freedom for the team, for collaborative work and motivation. More trust! Work harder on understanding the context and value of features implemented. More details (rus) / tg channel : https://t.me/inteamwetrust_rus/35 Video: https://youtu.be/Pq82aFap1rc\n","permalink":"https://maratkee.com/posts/2019-07-08-trust-stories-growing-trust-in-distributed-teams-ru/","summary":"\u003cp\u003eLast week me and \u003ca href=\"https://www.facebook.com/alexey.pikulev\"\u003eAlex Pikulev\u003c/a\u003e of \u003ca href=\"http://agilix.ru\"\u003eAgilix\u003c/a\u003e recorded \u003ca href=\"https://inteamwetrust.com/trust-stories/\"\u003eTrust Stories\u003c/a\u003e podcast episode, on Growing Team Trust in Distributed Teams. Courtesy of \u003ca href=\"https://inteamwetrust.com\"\u003eIn Teams we Trust websit\u003ca href=\"https://inteamwetrust.com\"\u003ee\u003c/a\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.youtube.com/watch?v=Pq82aFap1rc\"\u003ehttps://www.youtube.com/watch?v=Pq82aFap1rc\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eMain bullets are: \u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eGrowing trust in distrubited teams is hard, but nevertheless as important as in co-located team. \u003c/li\u003e\n\u003cli\u003eTeam itself creates an atmosphere of trust in itself. Our task, as a scrum master, coach, manager - is to help and highlight needed areas.\u003c/li\u003e\n\u003cli\u003eXP and especially Pair Programmingи helps in growing trust.\u003c/li\u003e\n\u003cli\u003eIntrateam trust, from the informal side (skype beers, navigating as a guest to your colleagues in other locations, bike fixing via the webcam, ordering stuff on flea market in your city and sending it over to a colleague) helps a lot.\u003c/li\u003e\n\u003cli\u003eMore freedom for the team, for collaborative work and motivation. More trust! Work harder on understanding the context and value of features implemented.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eMore details (rus) / tg channel : \u003ca href=\"https://t.me/inteamwetrust_rus/35?fbclid=IwAR1OAt63O2wy_vYNCbdCED1aOzaBTYD5Vcqa7oHeuEDc8QQrlpdeRkXgyjs\"\u003ehttps://t.me/inteamwetrust_rus/35\u003c/a\u003e\nVideo: \u003ca href=\"https://youtu.be/Pq82aFap1rc?fbclid=IwAR3cx0vUeqigK00jLtjzAPzyJa61KQNyckGH5A675S-Y4wKAGhbWLbTMhJA\"\u003ehttps://youtu.be/Pq82aFap1rc\u003c/a\u003e\u003c/p\u003e","title":"Trust Stories - Growing trust in distributed teams (RU)"},{"content":"\nNavigate to Personal Settings- Turn switcher for Jira Labs off- And leave feedback. Atlassian team needs you to help\u0026rsquo;em understand what didn\u0026rsquo;t you like. Ahem, I got some help :)It\u0026rsquo;s not comfortable to edit- It doesn\u0026rsquo;t support markup- It doesn\u0026rsquo;t allow to work with resolutions- It makes it hard to find needed fields, although they are already turned on in standard view Are you finding new view comfortable? Has it helped you improve your Jira routines?\n","permalink":"https://maratkee.com/posts/2019-06-30-how-to-turn-off-new-jira-issue-view/","summary":"\u003cp\u003e\u003cimg loading=\"lazy\" src=\"/images/image-5.png\"\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eNavigate to Personal Settings- Turn switcher for Jira Labs off- And leave feedback. Atlassian team needs you to help\u0026rsquo;em understand what didn\u0026rsquo;t you like. Ahem, I got some help :)\u003col\u003e\u003cli\u003eIt\u0026rsquo;s not comfortable to edit- It doesn\u0026rsquo;t support markup- It doesn\u0026rsquo;t allow to work with resolutions- It makes it hard to find needed fields, although they are already turned on in standard view\u003c/li\u003e\u003c/ol\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eAre you finding new view comfortable? Has it helped you improve your Jira routines?\u003c/p\u003e","title":"How to turn off New Jira Issue view"},{"content":"and why Trello? Lately I\u0026rsquo;ve started using Trello as an ultimate tool for the Retros and Demos. So this post will cover the path to using trello as opposed to other solutions.\nyet another pencil illustration\nTools I\u0026rsquo;ve been using multiple tools, such as Realtimeboard (now Miro) as an interactive flipchart to collaborate with the team, Google Docs with sections appointed to the retro stages, Confluence (as in 100% of the projects I\u0026rsquo;ve been working in we\u0026rsquo;ve had Atlassian stack), even Jira once (wow that was a bad idea)!\nI bet almost everyone was trying to find that nieche, that ultimate tool he can expand to using in various projects no matter the area!\nThe main criterias for the proper tool are:\nhandling item-centric discussion -\u0026gt; cards, ideally.- fast and effortless collaboration of the cards- markering the cards (by all members), no matter label or color- cards reordering- time spent on executing action of: creating section -\u0026gt; adding item -\u0026gt; labelling it to be worth (by members) -\u0026gt; adding comment to the item. Realtimeboard While Realtimeboard is awesome, it\u0026rsquo;s not as simple to use in collaboration (well, it exceeds in functionality but format of retro is tied to the cards which is not the strongest of that product\u0026rsquo;s sides). There\u0026rsquo;s no barebone structure that supports cards, so you have to maintain it yourself: create some kind of a column, move items that are not self-aligned to that column. This is time-consuming and effortless. Labelling is not a stronger side of Realtime board.\nGoogle Docs When it came to Google Docs, it\u0026rsquo;s the default option for zillions of companies I\u0026rsquo;ve discussed remote retros with. However, it\u0026rsquo;s not visual enough from the point of dissecting retro items and splitting them. Using spreadsheets on the other hand seems to cope better with 2-dimentional-retro-approach (well, not an approach but the idea that you got buckets with items for good/bad/improvements). However drag-n-drop for the items to reorder and link with each other sucks there. I\u0026rsquo;ve also tried to have Google Slides at a certain point with one-slide-per-section (e.g. all great improvements accomplished since last sprint) - but it seemed too heavyweight and kind of sucked at limiting members of the dev team to collaborate properly. Labelling here is somewhat ok, but\nConfluence Coming to confluence, albeit it does have a blueprint for the retro - it\u0026rsquo;s good more for the documenting / stenographing, than for the real-time-discussion. Or just writing some kind of decision-log. Atlassian tries to position confluence as a lightweight in-stack solution for collaboration, however it\u0026rsquo;s far away from gDocs in terms of simplicity/stability/collaborating. And again, it\u0026rsquo;s not centered around discussion items. It\u0026rsquo;s also not stable enough, where some of the changes are not applied on publishing, or connection is lost to cloud instance.\nTrello Coming to Trello, it simply supports the cards, it allows voting either via power-ups (which is simple), or via labelling with colors (which is fast, efficient and convenient). You can drag-n-drop item cards, and organize Retro stages into column. If the item may have a lengthy discussion or not that related -\u0026gt; you just drop it into the parking lot. Basically, trello is the most simple-to-use online implementation of flipchart + stick-it-notes.\nPreparation \u0026amp; Setting the Stage Remote retros usually are much less emotional and empathetic, given that it all happens online and some people may not want to share their faces (and expressions) behind the camera. Now to set the stage, we\u0026rsquo;d ideally need to:\nGet everyone to turn on the cameras at their laptops- Select comfortable tool. I usually use either Skype or Slack video, but occasionally zoom seems to be a great option as well- Make sure the quality of connection is superb: we need as less lags possible- Prepare beforehand: either with the unified agenda, or the topics. We can preliminary pinpoint any inconsistensies and disfunctions on an online board :) All members of the retro should know the structure of how the retro will be proceeding, in order to assign points they\u0026rsquo;ve prepared to particular retro stages. Retro example of how trello board is used during screen sharing on a retro\nThings improved since the last sprint I usually start retros by listing our improvement/accomplishments that we\u0026rsquo;ve planned to achieve last time. So we either mark something achieved with green (we got a long list of all improvements implemented), or mark with orange something critical that we didn\u0026rsquo;t achieve but planned (and with red if it was not improved for 2 sprints in a row). Later on this red labelled card simply is the top-priority to improve (if still relevant).\nThis shows the team where we at with desired improvements and is a good starting point for overall recap of things that happened during the sprint before the current one.\nTip: it\u0026rsquo;s also sometimes nice to order everyone a pizza for the retro to get the positive vibe and thank for accomplishments. It shouldn\u0026rsquo;t be only on org budget, the team can self-organize around retro being a cheerful and friendly event, instead of a mandatory meeting. Although, don\u0026rsquo;t force it into the \u0026ldquo;mandatory-pizza-meeting\u0026rdquo;, with the management looking from above and yelling: \u0026ldquo;Eat your food and report on bad things happened during this sprint\u0026rdquo;. I\u0026rsquo;ve seen some orgs giving the budget for pizza and overwatching that it\u0026rsquo;s spent properly (eaten) and making sure people are thankful that management is spending money on their food :)\nThis stage may get lengthy as if something planned to be improved is not achieved -\u0026gt; team may start getting in lengthy discussions on why this happened. As a facilitator, your job is to help team find the productive path to navigating to the root cause in a short enough time to accomodate retro timebox. That\u0026rsquo;s why only a few items (1-2) should be planned for improvement, otherwise we may be stuck on the very fist stage. Your job as a scrum master is to coach the team to be aware of the timebox and get to the root cause efficiently.\nSprint Metrics Sprint metrics is an important internal-SLA for the team. Usually there are various factors that dev team may see as an obstacle or an impediment to be an even greater power-ranger-squad. Facilitation and proper reflection of dev team\u0026rsquo;s discussion provides sufficient items on how to improve the process and measure those improvements. The rest is just comparison. Common metrics to compare are: Lead Time (as soon as you explain the team the meaning of it, team will start to be motivated to improve this metric), time in Code Review, # of times tickets are reopened, and so on.\nFor bigger projects we\u0026rsquo;re also reviewing the metrics until the project-end, comparing projections on finishing via story points, and throughput.\nSprint Goals This is not something that I use everywhere, but still when it comes to transparency, we need to reiterate what we tried to achieve goal-wise. Although this is not directly related to the process itself, since goals achieved need to be reviewed and discussed during Sprint Review -\u0026gt; it\u0026rsquo;s still effective to hightlight reasons on meeting sprint goals or not (which are related to the process, and retro is about inspecting the inner processes and tuning them).\nI usually guide the teams to mark sprint goal cards with green for achieved, and red for not. And comments to demonstrate the reasons. Simple as that :)\nTypical \u0026lsquo;What have been working nice\u0026rsquo;, \u0026lsquo;What could have been better\u0026rsquo;, \u0026lsquo;What will help us improve in the future\u0026rsquo; btw, did you know that there\u0026rsquo;s a ACP-ATF (team facilitator badge by ICAgile)\nDistributed and remote team members need to add points and vote for them as soon as the issues are found. No need to wait until the retro itself, to pin discussion item.\nAs a facilitator, your job is to turn team\u0026rsquo;s attention / highlight any conflicts / impediments during the sprint when the team faces them. Help the team to document / pin it to the retro board.\nDo it via reflecting the situation when discussing it with the team, providing a view from a person that doesn\u0026rsquo;t have a context, or any other facilitation technique :) Make sure team is engaged in inspection process during the cadence itself, and not during the retro event only. And help the team to document / pin it to the retro board. Even if it would lead to a lot of items in retro - you can always remove irrelevant.\nReferences and helpful things Ben Linders has a pretty great trello board that provides crowdsourced ways of retro-handling https://www.benlinders.com/news/trello-board-retrospective-techniques/ That possibly was the best help I got when trying to make team retros in trello better :) He\u0026rsquo;s a nice guy in person, you can clarify a lot if you\u0026rsquo;re at the same conference / workshop as him! ","permalink":"https://maratkee.com/posts/2019-06-05-conducting-remote-and-distributed-retrospectives-with-trello/","summary":"\u003ch1 id=\"and-why-trello\"\u003eand why Trello?\u003c/h1\u003e\n\u003cp\u003eLately I\u0026rsquo;ve started using Trello as an ultimate tool for the Retros and Demos. So this post will cover the path to using trello as opposed to other solutions.\u003c/p\u003e\n\u003cp\u003e\u003cimg loading=\"lazy\" src=\"/images/trello_featured_image.jpeg\"\u003e\u003cem\u003eyet another pencil illustration\u003c/em\u003e\u003c/p\u003e\n\u003ch4 id=\"tools\"\u003eTools\u003c/h4\u003e\n\u003cp\u003eI\u0026rsquo;ve been using multiple tools, such as Realtimeboard (now Miro) as an interactive flipchart to collaborate with the team, Google Docs with sections appointed to the retro stages, Confluence (as in 100% of the projects I\u0026rsquo;ve been working in we\u0026rsquo;ve had Atlassian stack), even Jira once (wow that was a bad idea)!\u003c/p\u003e","title":"Conducting Remote and Distributed Retrospectives with Trello"},{"content":"This is an interesting case I always wanted to make better: almost every project you come to has a lot of older unreleased tickets, that actually already sit on production. And developers (without proper jira management) continue using the Kanban board that becomes more crowded in the Done / Closed column (and it can hit 400, 1000 tickets and be slow and almost pointless to use). Typical story, huh?\nSo what to do, if you want to release all those older tickets and don\u0026rsquo;t bother developers with, say, 450 updates on every ticket that fixVersion has been set to each one of them? The answer (and thanks to AUG Moscow Community) is to swap notification scheme for related projects while releasing.\nReferences: https://confluence.atlassian.com/adminjiraserver071/creating-a-notification-scheme-802592629.html\nSteps Go to Jira Settings -\u0026gt; Issues -\u0026gt; Notification Schemes *usually there\u0026rsquo;s one by default only *\nCreate a blank scheme (as in the screenshot). It means that the events (like in my case it is \u0026lsquo;Issue Updated\u0026rsquo; would not send any notifications). - Now go to the Project Settings -\u0026gt; Notification Schemes. Swap the notification scheme for the blank one in the Project Settings - Take a look at notification schemes in jira settings (it should not include one project attached to the blank scheme. And finally release the Done/ Closed tickets on the Kanban board -\u0026gt; voila, no email notifications were sent at all. You\u0026rsquo;ll still get the events themselves logged in Jira Settings -\u0026gt; System -\u0026gt; Audit log, which is neat and nice, cause everyone will be able to relate to that if needed!\nOther solutions Might include turning off outgoing emails, but after turning them on events will build up a queue of notification that missed scheduled sendout :) So don\u0026rsquo;t do this.\n","permalink":"https://maratkee.com/posts/2018-12-11-jira-cloud-releasing-multi-project-old-tickets-from-kanban-board-without-spamming-developers-inboxes/","summary":"\u003cp\u003eThis is an interesting case I always wanted to make better: almost every project you come to has a lot of older unreleased tickets, that actually already sit on production. And developers (without proper jira management) continue using the Kanban board that becomes more crowded in the Done / Closed column (and it can hit 400, 1000 tickets and be slow and almost pointless to use). Typical story, huh?\u003c/p\u003e\n\u003cp\u003eSo what to do, if you want to release all those older tickets and don\u0026rsquo;t bother developers with, say, 450 updates on every ticket that fixVersion has been set to each one of them? The answer (and thanks to AUG Moscow Community) is to swap notification scheme for related projects while releasing.\u003c/p\u003e","title":"Jira Cloud: Releasing multi-project old tickets from Kanban board without spamming developer's inboxes"},{"content":"So we\u0026rsquo;ve been measuring story points estimate and throughput through the last 5 sprints, and they really do show approximately similar results :) makes you think why do have an additional story points layer on top of the simple throughput? :)\nJust as Vasco Duarte told :)\n","permalink":"https://maratkee.com/posts/2018-10-25-throughput-vs-story-points-velocity/","summary":"\u003cp\u003eSo we\u0026rsquo;ve been measuring story points estimate and throughput through the last 5 sprints, and they really do show approximately similar results :) makes you think why do have an additional story points layer on top of the simple throughput? :)\u003c/p\u003e\n\u003cp\u003e\u003cimg loading=\"lazy\" src=\"/images/throughput-_-sp-_correlation.png\"\u003e\u003c/p\u003e\n\u003cp\u003eJust as \u003ca href=\"https://medium.com/@duarte_vasco\"\u003eVasco Duarte\u003c/a\u003e told :)\u003c/p\u003e","title":"Throughput vs Story Points velocity"},{"content":"It\u0026rsquo;s been an extremely fruitful Atlassian Summit 2018 in Barcelona! Main purpose was to speak about Distributed Teams, however the atmosphere was so cheerful and friendly, that it was more like a fireside chat, even given that my speech was the closing one.\nhttps://www.youtube.com/watch?v=yFDtxT5-5MM\nGot an awesome tracklead! Brought a giant bag of Atlassian merch for AUG events in Ufa, thanks Darlene! Finally met Ben Linders (check out his Agile Self-Assesment game!) whom I\u0026rsquo;ve been giving a Q\u0026amp;A to (which is now available in Japanese and Chinese).\nTalked with zillions of new people from Atlassian Marketplace, Bitbucket, DevOps, Jira Cloud, Adaptivist, Code Barrel, and loads of other Atlassian-related-folks (including long speeches with Mike Cannon-Brookes (WHOA!) :) Met AUG Leaders from all-over-the-world, and the whole atmosphere was sheer cozy and welcoming (you guys were awesome)!\n[gallery ids=\u0026ldquo;919,916,917,918\u0026rdquo; type=\u0026ldquo;rectangular\u0026rdquo;]\nSources for presentations: Summit_Distirbuted_Teams_v1.0, Agile Communication in Distributed Teams (with no overlapping hours), Workflow for the Requirements in the Distributed team\n","permalink":"https://maratkee.com/posts/2018-09-25-anatomy-of-distributed-team-workflows-agility-communication-my-talk-from-atlassian-summit-2018/","summary":"\u003cp\u003eIt\u0026rsquo;s been an extremely fruitful Atlassian Summit 2018 in Barcelona! Main purpose was to speak about Distributed Teams, however the atmosphere was so cheerful and friendly, that it was more like a fireside chat, even given that my speech was the closing one.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.youtube.com/watch?v=yFDtxT5-5MM\"\u003ehttps://www.youtube.com/watch?v=yFDtxT5-5MM\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eGot an awesome tracklead! Brought a giant bag of Atlassian merch for AUG events in Ufa, thanks Darlene! Finally met \u003ca href=\"https://www.benlinders.com\"\u003eBen Linders (check out his Agile Self-Assesment game!)\u003c/a\u003e whom \u003ca href=\"http://kiniabulatov.com/2018/08/17/my-qa-for-infoq-on-keeping-distributed-teams-in-sync/\"\u003eI\u0026rsquo;ve been giving a Q\u0026amp;A to\u003c/a\u003e (which is now available in \u003ca href=\"https://www.infoq.com/jp/news/2018/09/distributed-teams\"\u003eJapanese\u003c/a\u003e and \u003ca href=\"http://www.infoq.com/cn/news/2018/08/distributed-teams\"\u003eChinese\u003c/a\u003e).\u003c/p\u003e","title":"Anatomy of Distributed Team: Workflows, Agility, Communication - my talk from Atlassian Summit 2018"},{"content":"I spoke with Ben Linders of InfoQ (thrilled to be published at that website!) about challenges and communication patterns for Distributed Teams, uncovering bits of my Atlassian Summit 2018 speech.\nThe biggest challenge of distributed teams is communication, which is essential for establishing ground rules on collaboration. Shifting working hours to accommodate each other and team liaisons help to communicate and synchronize work. Teams based on trust, respect, and openness will thenselves to help people throughout the organization and foster a culture that keeps teams in sync.\nMarat Kiniabulatov, project manager at SkuVault, will give a talk about the anatomy of distributed teams at the Atlassian Summit Europe 2018. This event will be held September 3 - 5 in Barcelona, Spain:\nInfoQ spoke with Kiniabulatov about the challenges of distributed teams, how product owners and stakeholders collaborate at SkuVault and how the workflow is managed, how distributed teams communicate effectively and synchronize their work, and how SkuVault nurtures a culture that keeps teams in sync. Full Q\u0026amp;A at Keeping Distributed Teams in Sync,\nAlso available in Japanese and Chinese\n","permalink":"https://maratkee.com/posts/2018-08-17-my-qa-for-infoq-on-keeping-distributed-teams-in-sync/","summary":"\u003cp\u003eI spoke with Ben Linders of InfoQ (thrilled to be published at that website!) about challenges and communication patterns for Distributed Teams, uncovering bits of my Atlassian Summit 2018 speech.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eThe biggest challenge of distributed teams is communication, which is essential for establishing ground rules on collaboration. Shifting working hours to accommodate each other and team liaisons help to communicate and synchronize work. Teams based on trust, respect, and openness will thenselves to help people throughout the organization and foster a culture that keeps teams in sync.\u003c/p\u003e","title":"My Q\u0026amp;A for InfoQ on Keeping Distributed Teams in Sync"},{"content":"Stride is being discontinued as of Feb 2019, and Atlassian itself moves to Slack. It was quite hard to use Stride as the speed of the electron package was painful, integrations were worse than in Slack (even with Atlassian products), stability and features were suffering quite heavily.\nIt\u0026rsquo;s great that a team can admit it\u0026rsquo;s pain points, since it\u0026rsquo;s almost impossible to compete with de-facto industry standard \u0026lsquo;Slack\u0026rsquo;. I\u0026rsquo;ve written about experience of 6 months on Stride, we\u0026rsquo;ll jump off it, I presume, closer to the end of product support.\n","permalink":"https://maratkee.com/posts/2018-07-27-stride-is-to-be-discontinued-in-feb2019/","summary":"\u003cp\u003e\u003ca href=\"https://www.atlassian.com/blog/announcements/new-atlassian-slack-partnership\"\u003eStride is being discontinued as of Feb 2019, and Atlassian itself moves to Slack.\u003c/a\u003e It was quite hard to use Stride as the speed of the electron package was painful, integrations were worse than in Slack (even with Atlassian products), stability and features were suffering quite heavily.\u003c/p\u003e\n\u003cp\u003eIt\u0026rsquo;s great that a team can admit it\u0026rsquo;s pain points, since it\u0026rsquo;s almost impossible to compete with de-facto industry standard \u0026lsquo;Slack\u0026rsquo;. \u003ca href=\"http://kiniabulatov.com/2018/05/04/telegram-stride-migration-experience/\"\u003eI\u0026rsquo;ve written about experience of 6 months on Stride\u003c/a\u003e, we\u0026rsquo;ll jump off it, I presume, closer to the end of product support.\u003c/p\u003e","title":"Stride is to be discontinued in Feb2019"},{"content":"\nHey guys, good news - Minsk has it\u0026rsquo;s own Atlassian User Group now, me \u0026amp; StiltSoft kicked out the first event, gathered 60 RSVP\u0026rsquo;s in just one week, and had an amazing time in the beautiful city of Minsk, Belarus!\nHosted an event in an awesome Eventspace.by at the old factory!\n[gallery ids=\u0026ldquo;902,899,900\u0026rdquo; type=\u0026ldquo;rectangular\u0026rdquo;]\n- \u0026lt;a title=\u0026quot;AUG Minsk, SkuVault-\u0026gt;Jira\u0026quot; href=\u0026quot;/images/aug-minsk-skuvault-jira.pdf\u0026quot;\u0026gt;AUG Minsk, SkuVault-Jira\u0026lt;/a\u0026gt; - Speech on how we organized processes and workflows in Jira, and helped SkuVault become more transparent in development; - [AUG Minsk, Stride](/images/aug-minsk-stride.pdf) - our experience in migration from Telegram to Atlassian Stride. https://www.linkedin.com/embed/feed/update/urn:li:activity:6396021858935861248\nAnd of course, a pub pic.\n","permalink":"https://maratkee.com/posts/2018-05-14-minsk-aug-hosted/","summary":"\u003cp\u003e\u003cimg loading=\"lazy\" src=\"/images/1c0346c5-3d86-4f3d-a3c7-6e301876a15e-original.jpeg\"\u003e\u003c/p\u003e\n\u003cp\u003eHey guys, good news - Minsk has it\u0026rsquo;s own Atlassian User Group now, me \u0026amp; StiltSoft kicked out the first event, gathered 60 RSVP\u0026rsquo;s in just one week, and had an amazing time in the beautiful city of Minsk, Belarus!\u003c/p\u003e\n\u003cp\u003eHosted an event in an awesome Eventspace.by at the old factory!\u003c/p\u003e\n\u003cp\u003e[gallery ids=\u0026ldquo;902,899,900\u0026rdquo; type=\u0026ldquo;rectangular\u0026rdquo;]\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e- \u0026lt;a title=\u0026quot;AUG Minsk, SkuVault-\u0026gt;Jira\u0026quot; href=\u0026quot;/images/aug-minsk-skuvault-jira.pdf\u0026quot;\u0026gt;AUG Minsk, SkuVault-Jira\u0026lt;/a\u0026gt; - Speech on how we organized processes and workflows in Jira, and helped SkuVault become more transparent in development;\n- [AUG Minsk, Stride](/images/aug-minsk-stride.pdf) - our experience in migration from Telegram to Atlassian Stride.\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e\u003ca href=\"https://www.linkedin.com/embed/feed/update/urn:li:activity:6396021858935861248\"\u003ehttps://www.linkedin.com/embed/feed/update/urn:li:activity:6396021858935861248\u003c/a\u003e\u003c/p\u003e","title":"Minsk AUG Hosted!"},{"content":"Recently I hosted Minsk Atlassian User Group, where I shared our experience on migrating to Stride and gave the analogy between Stride, and Russian word \u0026lsquo;Stradai\u0026rsquo; (-\u0026gt; eng.: \u0026lsquo;Suffer\u0026rsquo;). I\u0026rsquo;ll explain the analogy later. Hence the \u0026lsquo;Napalm Death\u0026rsquo; song \u0026lsquo;Suffer\u0026rsquo; joke on the first slide :)\nGiven that a lot of people use Telegram as a corporate messenger, and given all of the telegram-blocking happening in Russia currently, it\u0026rsquo;s pretty relevant to write about alternatives. We at SkuVault migrated due to the need of user control, but migration experience is relevant to many other teams.\nAtlassian launched Stride as a HipChat Cloud replacement (so we can call it hipchat 2.0). Main competition is Slack, which is currently de-facto corporate messaging standard, as we know. I\u0026rsquo;ll compare Stride to Telegram and Slack in areas they are strong.\nPros Atlassian Ecosystem Biggest point of Stride is that it connects to your atlassian ecosystem. Typically you got single account for Atlassian User, from which you can manage entirety of Atlassian Permissions. Now, Stride is added as an application to the very same account, and access / admin rights are easily managed from the very same place. If you want to have control over the users and the ecosystem that is locked to Atlassian (as we do) -\u0026gt; this is an ideal scenario.\nIn Telegram we had personal accounts, which you don\u0026rsquo;t have control of (sure you can create virtual / work phone numbers and link them to telegram to make it corporate-friendly, but that is kind of a crappy way to maintain users ecosystem).\nIn Slack - you have to pay more than $3/user and it\u0026rsquo;s a separate account management system.\nUsers Control User Control means removing a person, when she no longer works at the company, visibility for messages in order for infosec to not be compromised.\nAudio and Video Group Calls It may not be something you\u0026rsquo;d count as a pro, but given that we previously used Telegram + Skype for calls (with hangouts as a fallback in case of skype outage), it\u0026rsquo;s nice to have same app doing everything.\nJira / Confluence Integration via bots Integration with Jira and Confluence (not out-of-the-box-though) gives you a glimpse of the ticket in the chatroom (ticket card that reflects priority, assigne and editable layout), ability to create tickets as a command to chat-bot (create new bug Fix spacing on signup page in SV project), bitbucket PR review poking, and a lot of neat other things you\u0026rsquo;d expect inside the Atlassian ecosystem).\nBasics Mentions, citation, styles for text. NO HASHTAGS THOUGH - giant bummer!\nCons And here\u0026rsquo;s my analogy of \u0026lsquo;Stride\u0026rsquo; to russian word \u0026lsquo;Suffer\u0026rsquo;: you can use Stride, but it\u0026rsquo;s still raw, and a lot of features you\u0026rsquo;d expect to be basic in messaging, are half-baked in Stride.\nVideo Calls Let\u0026rsquo;s admit, that Slack sucks at group video calls as well. But Stride is much worse :)\n- Issues include showing bad internet connection, when connection is good. - People may suddenly leave the call, although didn't click on leaving or anything - Stride's animations are smooth, so when it switches to another person, it fades in / fades out. And sometimes crashes during that animation! - Video lags a lot, sound doesn't though - Video freezes a lot, and doesn't resume until you restart the call - RAM consumption (400mb), CPU consumtion 70% on core i5 2014. This is a lot. - When you share the screen, and stride catches a glimpse of itself (stride window), it falls into the infinite glitch of Stride fractal windows. Ok, done with the video calls!\nBasics - No hashtags (sucks) - Sending messages is painful (it's slow). - Sending messages with attachment is a torture (Stride waits until image is uploaded (slow), and only then allows you to click on send message (which is slow as well) - No forwarding between chatrooms -\u0026gt; leads to isolation of discussions to room-only. Notifications They are horrible (not Rocky-Horror-Show or Dr. Horrible way, and not even Troma-way. They are as bad as most coffee in US (ha-ha)). The sound of notification is bleak and unnoticable. You can\u0026rsquo;t change it, even if you rip apart the guts of app package and assemble it again :( That results in people not reacting on urgent messages.\nThere is no mute for chat rooms, which results in information overload and renders the whole notifications system pointless.\nThere is no indication that your message was read by your counterpart. You don\u0026rsquo;t know whether to poke your colleague or he already read this.\nPhone gets 2/3rds of all notifications. But when it does - mac app doesn\u0026rsquo;t show any of those! This is a typical failure, I\u0026rsquo;m writing this post on the train from Brest to Minsk where I ride to host AUG Minsk, and our team notified me with long message on my phone, but i see no new messages in my mac app. I have to restart it to get those messages.\nJira Bot Although integration with jira bot is neat (hey, slack does that even better, actually), it crowds chat room\u0026rsquo;s vertical space like a giant worm that digs Jasinto in Gears of War 2. If you dump number of tickets to dicsuss in the chatroom, you can\u0026rsquo;t read any message because card previews will occupy the whole 2-3 screens of vertical space.\nJSON parsing As per our admins, Stride doesn\u0026rsquo;t parse JSON on itself, so basically you have to parse and feed parsed JSON to the API yourself. Not the case with telegram.\nNutshell Stride is not-horrible-beyond-anything, it\u0026rsquo;s ok. You can use it and adjust to it. Especially if you\u0026rsquo;re locked to Atlassian Ecosystem (and I love and use jira, even after the latest interface update). But if you\u0026rsquo;re already on slack - there\u0026rsquo;s no point, it will work better for now.\nThere are a lot of things to improve, and the guys at Stride work on making their product better. It took 5 years to telegram to become the best and neatest messaging platform, it took same number of years for Slack.\nParking Lot References - Submitted Issues\n- Default Notification Sound - Cannot be Changed (https://jira.atlassian.com/browse/ STRIDE-578) - No 'read' indication https://jira.atlassian.com/browse/STRIDE-66 Lags \u0026amp; Crashes https://getsupport.atlassian.com/servicedesk/customer/portal/40/ STRD-2580 - Notifications sometimes simply don't come to the phone / laptop. (https://jira.atlassian.com/ browse/STRIDE-1989) - Inability to mute rooms https://jira.atlassian.com/browse/STRIDE-2196 - No forwarding (https://getsupport.atlassian.com/servicedesk/customer/portal/40/ STRD-2579) - Bug with notifications on macos https://jira.atlassian.com/browse/STRIDE-1848 - No ability to reply https://jira.atlassian.com/browse/STRIDE-104 - No sorting by recent messages in left sidebar for groups https://jira.atlassian.com/browse/ STRIDE-2077 - https://getsupport.atlassian.com/servicedesk/customer/portal/40/STRD-2581 - Slow image sending https://jira.atlassian.com/browse/STRIDE-2102 ","permalink":"https://maratkee.com/posts/2018-05-04-telegram-stride-migration-experience/","summary":"\u003cp\u003eRecently I hosted \u003ca href=\"https://aug.atlassian.com/events/details/atlassian-minsk-presents-first-ever-minsk-atlassian-user-group\"\u003eMinsk Atlassian User Group\u003c/a\u003e, where I shared our experience on migrating to Stride and gave the analogy between Stride, and Russian word \u0026lsquo;Stradai\u0026rsquo; (-\u0026gt; eng.: \u0026lsquo;Suffer\u0026rsquo;). I\u0026rsquo;ll explain the analogy later. Hence the \u0026lsquo;Napalm Death\u0026rsquo; song \u0026lsquo;Suffer\u0026rsquo; joke on the first slide :)\u003c/p\u003e\n\u003cp\u003eGiven that a lot of people use Telegram as a corporate messenger, and given all of the telegram-blocking happening in Russia currently, it\u0026rsquo;s pretty relevant to write about alternatives. We at SkuVault migrated due to the need of user control, but migration experience is relevant to many other teams.\u003c/p\u003e","title":"Telegram -\u0026gt; Stride Migration Experience"},{"content":"So we\u0026rsquo;ve survived Ufa Atlassian User Group, the very first meetup, with 17 people visiting our office to hear about jira, confluence, bitbucket and other atlassian products :)\n[gallery ids=\u0026ldquo;869,870,871,872,873\u0026rdquo; type=\u0026ldquo;square\u0026rdquo;]\nWe\u0026rsquo;ve discussed how Jira helped us in reflecting SkuVault development processes, and how do we keep documentation on the feature in Confluence, until it\u0026rsquo;s released, and what info do we store there.\nPanel consisted of Smena.io, modulbank, MEGI, and a couple other teams :) Presentation is available in Russian via this link: UfaAUG_1.\nhttps://www.youtube.com/watch?v=-vQOq7JxXn8\u0026t=27s\nStay tuned at https://aug.atlassian.com/ufa/ for more events in Ufa :)\n","permalink":"https://maratkee.com/posts/2018-02-07-ufa-aug-1-wrap-up/","summary":"\u003cp\u003eSo we\u0026rsquo;ve survived \u003ca href=\"https://aug.atlassian.com/ufa/\"\u003eUfa Atlassian User Group\u003c/a\u003e, the very first meetup, with 17 people visiting our office to hear about jira, confluence, bitbucket and other atlassian products :)\u003c/p\u003e\n\u003cp\u003e[gallery ids=\u0026ldquo;869,870,871,872,873\u0026rdquo; type=\u0026ldquo;square\u0026rdquo;]\u003c/p\u003e\n\u003cp\u003eWe\u0026rsquo;ve discussed how Jira helped us in reflecting SkuVault development processes, and how do we keep documentation on the feature in Confluence, until it\u0026rsquo;s released, and what info do we store there.\u003c/p\u003e\n\u003cp\u003ePanel consisted of Smena.io, modulbank, MEGI, and a couple other teams :) Presentation is available in Russian via this link: \u003ca href=\"/images/ufaaug_1.pptx\"\u003eUfaAUG_1\u003c/a\u003e.\u003c/p\u003e","title":"Ufa AUG #1. Wrap Up"},{"content":"So as you know my speciality is distributed teams :) This post is about what changes does the agile communication face (and scrum in particular), when it\u0026rsquo;s adjusted to the distributed teams. This is my experience, I don\u0026rsquo;t assume this is a silver bullet, but such approach works for me for the last 5 years and proved itself to be proficient.\nLet\u0026rsquo;s divide communication by types:\n- stragetic meetings (plannning, retrospective) - daily huddles (e.g. daily standup in scrum) - day-to-day clarifications. by Text I mean Instant Messaging\nLet\u0026rsquo;s add another dimension: geographical distribution:\nCollocated teams - everything\u0026rsquo;s perfectly fine for all three types of communication events. Teams, working in scrum, that are collocated face no issues with any of those.\nDistributed teams with little difference in timezones, but still with overlapping hours. Great examples are US - Chile / Mexico. Netherlands / India.\n- Daily syncup can be handled with almost no pain, as well as planning and retrospective (if you incorporate scrum in your company). - Instantness of clarification on work tasks is lost (when overlapping hours end), however given that skype / hangouts / whatever you use is just a click away - no significant impediments are to be found. - **No matter what you think about focused team, and that it processes everything faster due to unitedness, whenever team member is outside of her overlapping hours with the rest of the team - communication lag happens.** Distributed teams with no overlapping hours (8+ hours difference).\nApproaches here are:\n- 3.1 Team liason. When someone from the team in one part of the world is having a meeting during his time off work, to sync up with other part of the team in different timezone. Usually, team liason is someone from product team, however there are different examples of who syncs up with dev team in the industry. It can be simply a representative from one part of the team that syncs up on the progress with the other part (just like in scrum of scrums) - 3.2 Timezone Compromise approach. Teams change their work schedule, to have a compromise in at least 1 overlapping hour, in order to sync properly. For example, start of working day for one part of the team in western hemisphere moved from 10am to 9am, and eastern hemisphere team changes their working day to start from 10am to 9am. Thus, you got at least 1-2 hours overlapping. Whoa, problem solved -\u0026gt; we can get back to bullet 2, on how teams with overlapping hours work together! But remember, everything depends on team configuration, whether the team is comfy with selected approach, and development tasks specifics. - 3.3 And finally, you can set up communication process in a way it's comfortable for everyone in the distributed team. My personal beliefs is that redundant communication is always less efficient than on-demand-clear-bulleted-discussion, thus I'd prefer clear agenda and clarification when needed. \u0026ndash; 3.3.1 First of all, that means that people still are participating in retrospectives and planning sessions, cause those events happen once per 2-3 weeks (thus distraction or working off-time is tolerable). However, those meetings / scrum rituals are to be performed with clear goals, and well-prepared bullets. Try to not allow offtop conversations (when someone gets into topic not relevant to current discussion). Remember, team values personal time, and no team member should suffer from poorly planned meetings.\n\u0026ndash; 3.3.2 Second, it means that daily sync (or daily standup, if you follow scrum) can be done via text, at the end of team\u0026rsquo;s working day. In order to reach more visibility, developer can share a link to the branch, that he worked on. But main goal is to have an exceprt of what team member has done during the day, that is visible for everyone (e.g. special channel on updates in telegram). Some people also propose asynchronous video messages (Dave Snowden of cognitive edge shared this experience of his with me, referring to the times he worked at IBM) - you record video message for the team, and even share the screen, if you want some visual material on your work.\n\u0026ndash; 3.3.3 Third, clarificational communication (meaning day-to-day clarification communication type) is done on demand. Meeting for such batch of clarifications is done in a compromise time, so that noone\u0026rsquo;s felt left out). The good part of that is since you don\u0026rsquo;t have to get explanations on critical and extremely complex clarifications every day - you don\u0026rsquo;t need to torture your colleagues with evening / early morning calls each day. Usually, most of the impediments are resolved via instant messaging. Please keep in mind, that requirements standardisation is a key role in these clarifications, as properly structured requirements save a lot of time while developing a feature.\n\u0026ndash; 3.3.4 And fourth, but equally important, more standards and documenting. The more info necessary you prepare for your colleagues overseas, for the questions that may rise during your off-time, the less he will be stuck. Please use common sense in how much you need to prepare. When team gets to know each other, such planning becomes much easier. And finally, efficient process always means that person doesn\u0026rsquo;t get stuck :)\nFinally, we\u0026rsquo;re getting to my favourite ever part!\nDistributed teams with no overlapping hours + language barrier! I\u0026rsquo;ve been working with those for the last three year, and here are the additional steps to make it all work efficiently.\nThe three common baseline rules to follow are:\n- Prepare meeting agenda prior to the meeting. I'm talking about writing down basic points, explanations, and maybe even branching when presenting solutions (depending on meeting complexity). It's obvious, that people not fluent in english can't properly communicate during the meeting - everything starts to require much more time, which isn't efficient (and quite heavy, when it comes to hourly payrates ;) - More documenting. You may say that Agile says \u0026quot;working software over comprehensive documentation\u0026quot;, however when dealing with distributed teams + no overlapping hours + language barrier, I can't stress enough how much documentation means. There are key principles better to be described, as the team grows: communication standards (what type of communication is done via which tool, working time, speed of response), requirements acceptance, visual standards for documentation. All three principles affect how developer understands the task he's supposed to work on. Requirements should have only one way of interpreting, should include clear pre-and-post-conditions; bugs are to be described in reproducible steps. - And finally, it's essential to have a bi-lingual person (team liason), who helps with english (he comes up with translation of complex bits, moderates the discussion). This person is better to be a developer or someone who gets the technical part well, as she often helps with syncing two development parts of the team. She may also add meeting notes on technical details agreed once meeting is over. That person most likely will sacrifice some of her time off, since hours don't overlap. At the end of the day, there are plenty examples across my experience, and blogs, how people manage to work with just on demand meetings, and create complex projects together. Those are git, atlassian and, among others - SkuVault.\nLet me add an additional rule to common sense manifesto - process over redundancy. Greatly established process, understandable and rational for all parts of the team, makes it easy to track progress through transparency, keep team motivation high (for being productive) and time off undistracted.\nReferences:\n- http://www.disciplinedagiledelivery.com - http://snowdolphin.com/blog/2009/2/16/adventures-in-distributed-agile.html - http://agilemodeling.com/essays/communication.htm - https://www.atlassian.com/blog/confluence/4-simple-collaboration-strategies-distributed-teams - https://www.atlassian.com/team-playbook - https://www.atlassian.com/company/events/summit-europe/watch-sessions/2017/scale-extend/a-brave-journey-in-merge-waters-how-paysafe-consolidated-their-atlassian-tools - https://msdn.microsoft.com/en-us/magazine/hh771057.aspx - https://pdfs.semanticscholar.org/cde9/6fed7d2e2591bc8f697814ab1f33e3a84160.pdf - https://www.scrumalliance.org/community/articles/2013/july/managing-distributed-teams - [medium.com/@MentorMate/what-i-learned-managing-a-remote-agile-software-team-fd2db22e22b1](https://medium.com/@MentorMate/what-i-learned-managing-a-remote-agile-software-team-fd2db22e22b1) - https://www.researchgate.net/publication/263398659*Moonlighting*Scrum*An*Agile*Method*for*Distributed*Teams*with*Part-Time*Developers*Working*during*Non-Overlapping_Hours - https://www.agileconnection.com/article/five-agile-challenges-distributed-teams - https://www.agilealliance.org/wp-content/uploads/2016/01/Distributed-Agile-in-the-Enterprise-and-Virtual-Spaces-2012-08-16.pdf - http://www.research.ibm.com/pdfs/scrum/Chapter6*Pearson*20090706.pdf - https://www.thoughtworks.com/mingle/scaled-agile/2016/06/13/visualizing-time-zones.html - http://reqtest.com/general/working-efficiently-with-distributed-teams/ - http://www.methodsandtools.com/archive/archive.php?id=109 - https://books.google.ru/books?id=jBsVrWbIhYUC\u0026amp;pg=PA112\u0026amp;lpg=PA112\u0026amp;dq=distributed+teams+agile+communication+no+overlapping+hours\u0026amp;source=bl\u0026amp;ots=0kdQw5RQo9\u0026amp;sig=SMVuHCrX0oH4dWq1KDn2lQ8-1fk\u0026amp;hl=ru\u0026amp;sa=X\u0026amp;ved=0ahUKEwis5tDGvOHXAhXGQZoKHWzRCqE4ChDoAQhMMAU#v=onepage\u0026amp;q=distributed%20teams%20agile%20communication%20no%20overlapping%20hours\u0026amp;f=false ","permalink":"https://maratkee.com/posts/2018-01-18-agile-communication-in-distributed-teams-with-no-overlapping-hours/","summary":"\u003cp\u003eSo as you know my speciality is distributed teams :) This post is about what changes does the agile communication face (and scrum in particular), when it\u0026rsquo;s adjusted to the distributed teams. This is my experience, I don\u0026rsquo;t assume this is a silver bullet, but such approach works for me for the last 5 years and proved itself to be proficient.\u003c/p\u003e\n\u003cp\u003eLet\u0026rsquo;s divide communication by types:\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e- stragetic meetings (plannning, retrospective)\n- daily huddles (e.g. daily standup in scrum)\n- day-to-day clarifications.\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e\u003cimg loading=\"lazy\" src=\"/images/2018-01-18-11-12-16.jpg\"\u003e by Text I mean Instant Messaging\u003c/p\u003e","title":"Agile Communication in Distributed Teams (with no overlapping hours)"},{"content":"Hey, welcome! Name\u0026rsquo;s Marat, I help organizations and teams embrace agility, gain transparency and make better products.\nI\u0026rsquo;ve built Predictable.Team - tool to\nvisualize trends of your Jira \u0026amp; Youtrack flow metrics,\nget recommendations with step-by-step guide,\nperform monte-carlo simulation to forecast \u0026ldquo;when will the project be ready\u0026rdquo;, \u0026ldquo;how many items should we take in a sprint\u0026rdquo;, \u0026ldquo;how long will this epic take\u0026rdquo;.\nCurrently, I work with upper management that teams within my domain (banking core) become more Productive and Predictable to achieve our strategic goals.\nPreviously I helped MetaMap to scale-up process-wise (50 to 500 staff across the org) and maintained structured processes across departments, leading Program Management Office, and coaching teams to be efficient and business-objective driven.\nIn this blog I share my experience in building great products, building processes with clear success outcomes, and creating PDLC, and foster agility in companies. Given my experience with distributed teams, I dedicate lot of attention to how those aspects.\nMy initiatives are #AgileUfa (meetup on modern management), and Atlassian Communities in Minsk \u0026amp; Ufa, and local Coworking Space. I\u0026rsquo;m always open to have you as guests and speakers at one of those.\nI\u0026rsquo;m always looking forward to participating in exciting ventures, and I do really enjoy training teams, so in case you are interested in workshops or Scrum/Agile/Kanban trainings, ping me at email / telegram / linkedin.\nI have some certifications, but don\u0026rsquo;t really think it\u0026rsquo;s that important (unless you want to hire me in consulting and those are necessary: PSM II, KMP II, ICP-ACC, ICP-ATF, Prosci and OKR Coach.\nSocial Network Presence:\nLinkedIn Profile\nGetMentor Profile\nTelegram Blog (RU)\nHabr Blog (RU)\nMedium\nI\u0026rsquo;ve presented or spoke at at:\nSxSW \u0026lsquo;15 (Storia.me, Pitching and Showcasing social storytelling app at the fair)\nAtlassian Summit 2018 (on Distributed Teams anatomy and issues)\nLocal Ufa (my home city in Republic of Bashkortostan) events and workshops\nAgile Greece 2019.\n","permalink":"https://maratkee.com/about/","summary":"\u003cp\u003eHey, welcome! Name\u0026rsquo;s Marat, I help organizations and teams embrace agility, gain transparency and make better products.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"/images/2025/09/00100dportrait_00100_burst20180528193328743_cover.jpg\"\u003e\u003cimg loading=\"lazy\" src=\"/images/2025/09/00100dportrait_00100_burst20180528193328743_cover.jpg\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;ve built\u003ca href=\"https://predictable.team\"\u003e Predictable.Team\u003c/a\u003e - tool to\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003evisualize trends of your Jira \u0026amp; Youtrack flow metrics,\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eget recommendations with step-by-step guide,\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eperform monte-carlo simulation to forecast \u0026ldquo;when will the project be ready\u0026rdquo;, \u0026ldquo;how many items should we take in a sprint\u0026rdquo;, \u0026ldquo;how long will this epic take\u0026rdquo;.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eCurrently, I work with upper management that teams within my domain (banking core) become more Productive and Predictable to achieve our strategic goals.\u003c/p\u003e","title":"about"},{"content":"UPD: Rescheduled Jan. 30th -\u0026gt; to Feb. 6th.\nRecently buddies from Moscow recommended me to join Atlassian User Group Leaders,to host Atlassian events in Ufa, so here I am (after an interview with Atassian)!\nFirst ever-ever Atlassian User Group with special Atlassian swag will be happening January 30 2018, 7pm :) Meetup related to all things atlassian and related! Follow the link and save the date :) https://aug.atlassian.com/events/details/atlassian-ufa-presents-ufa-atlassian-user-group-1#/\n- # I'll be talking about how we adapted our development workflow in JIRA - # Documentation lifecycle in confluence at SkuVault More topics to come, from our local Atlassian Users :)\n","permalink":"https://maratkee.com/posts/2017-12-29-ufa-atlassian-user-group/","summary":"\u003cp\u003e\u003cstrong\u003eUPD: Rescheduled Jan. 30th -\u0026gt; to Feb. 6th.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eRecently buddies from Moscow recommended me to join Atlassian User Group Leaders,to host Atlassian events in Ufa, so here I am (after an interview with Atassian)!\u003c/p\u003e\n\u003cp\u003eFirst ever-ever Atlassian User Group with special Atlassian swag will be happening January 30 2018, 7pm :) Meetup related to all things atlassian and related! Follow the link and save the date :) \u003ca href=\"https://aug.atlassian.com/events/details/atlassian-ufa-presents-ufa-atlassian-user-group-1#/\"\u003ehttps://aug.atlassian.com/events/details/atlassian-ufa-presents-ufa-atlassian-user-group-1#/\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003e\u003cimg loading=\"lazy\" src=\"/images/2017-12-29-10-12-57.png\"\u003e\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e- # I'll be talking about how we adapted our development workflow in JIRA\n- # Documentation lifecycle in confluence at SkuVault\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eMore topics to come, from our local Atlassian Users :)\u003c/p\u003e","title":"Ufa Atlassian User Group"},{"content":"This time it was all about requirements. And we hosted the event at our cozy SkuVault office:\n- Eliciting and preparing requirements from gathering data till development: Oleg Gumerov (PO at SMENA - solutions provider for a big delivery service) shared his experience on how they do it in SMENA.io; - Nur Ibragimov (Head Analyst at modulbank) shared their way of processing requirements; - Us (me and Ksenia - also PM/ BA at SkuVault) shared how we do it in SkuVault, as well as how we used to work on requirements at Storia.me back in the days. - Formalizing and Structuring the requirements, by our own Ksenia of SkuVault - Tracking changes in Requirements by Ksenia (lightning talk) - Tracking time and Estimations by me (lightning talk) - Documentation Lifecycle when developing a feature (by me) And that was my first-time experience of stitching video and audio :) https://www.youtube.com/watch?v=HPxLpW1f8IA\nMeetup is in Russian, links are: VK / Meetup / Telegram Channel\n","permalink":"https://maratkee.com/posts/2017-12-20-ufa-it-management-meetup-4/","summary":"\u003cp\u003eThis time it was all about requirements. And we hosted the event at our cozy SkuVault office:\u003c/p\u003e\n\u003cp\u003e\u003cimg loading=\"lazy\" src=\"/images/img_1550.jpg\"\u003e\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e- Eliciting and preparing requirements from gathering data till development:\n\u003c/code\u003e\u003c/pre\u003e\n\u003cul\u003e\n\t\u003cli\u003eOleg Gumerov (PO at SMENA - solutions provider for a big delivery service) shared his experience on how they do it in SMENA.io;\n\t- Nur Ibragimov (Head Analyst at modulbank) shared their way of processing requirements;\n\t- Us (me and Ksenia - also PM/ BA at SkuVault) shared how we do it in SkuVault, as well as how we used to work on requirements at Storia.me back in the days.\n\u003c/li\u003e\n\t- Formalizing and Structuring the requirements, by our own Ksenia of SkuVault\n\t- Tracking changes in Requirements by Ksenia (lightning talk)\n\t- Tracking time and Estimations by me (lightning talk)\n\t- Documentation Lifecycle when developing a feature (by me)\n\u003c/ul\u003e\nAnd that was my first-time experience of stitching video and audio :)\n\u003cp\u003e\u003ca href=\"https://www.youtube.com/watch?v=HPxLpW1f8IA\"\u003ehttps://www.youtube.com/watch?v=HPxLpW1f8IA\u003c/a\u003e\u003c/p\u003e","title":"Ufa IT Management Meetup #4"},{"content":"2 weeks after we had the actual meetup, here\u0026rsquo;s the follow-up post :)\nTopics this time:\n- Keynote by me on [cynefin](https://www.youtube.com/watch?v=N7oz366X0-8) and how it fits our company projects. Had some discussion \u0026amp; arguing on applicacy of cynefin when it comes to rough development times, migrations, firefighting-based development. Overall, model was introduced, and the fact-and-experience-based arguments are always the best. Cause we all keep it harsh, true and ironic, when it comes to sharing something you've been stuffing bumps on! - Afterwards beer-session was a 3-hour-rant on headhunting of employees by Moscow, Saint-Petersburgh, Europe and States, and that Ufa developers became much more audacious, over the past crisis-driven years (given that there was no crisis in Moscow and the rest of the world). Seems like the raises are imminent, if you want to keep the developer. Headhunting becomes more brutal and sneaky at the same time! - Yet another topic was keeping the valuable professional, when he reaches the limites of intra-company growth, and what is best to offer in those cases. Overall, meetup gathers momentum and creates a community. We already got bigger guys from the enterprisey-yet-more-or-less-tolerable-sector, few startups on mobile/IoT/PaaS, Banking, Digital :)\nour links are: VK / Meetup / Telegram Channel\n","permalink":"https://maratkee.com/posts/2017-11-07-ufa-it-management-meetup-24-10-17/","summary":"\u003cp\u003e2 weeks after we had the actual meetup, here\u0026rsquo;s the follow-up post :)\u003c/p\u003e\n\u003cp\u003eTopics this time:\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e- Keynote by me on [cynefin](https://www.youtube.com/watch?v=N7oz366X0-8) and how it fits our company projects. Had some discussion \u0026amp; arguing on applicacy of cynefin when it comes to rough development times, migrations, firefighting-based development. Overall, model was introduced, and the fact-and-experience-based arguments are always the best. Cause we all keep it harsh, true and ironic, when it comes to sharing something you've been stuffing bumps on!\n- Afterwards beer-session was a 3-hour-rant on headhunting of employees by Moscow, Saint-Petersburgh, Europe and States, and that Ufa developers became much more audacious, over the past crisis-driven years (given that there was no crisis in Moscow and the rest of the world). Seems like the raises are imminent, if you want to keep the developer. Headhunting becomes more brutal and sneaky at the same time!\n- Yet another topic was keeping the valuable professional, when he reaches the limites of intra-company growth, and what is best to offer in those cases.\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e\u003cimg loading=\"lazy\" src=\"/images/kxd01nqfom8.jpg\"\u003e\u003c/p\u003e","title":"Ufa IT Management Meetup (24.10.17)"},{"content":"Me \u0026amp; my colleague basically decided to attend Agile Greece and Agile Turkey, and then exchange opinions and knowledge gathered there. Big advantage of my trip was Dave Snowden\u0026rsquo;s keynote, whom I wanted to catch after the speech and bore to death with silly questions :)\nAgile Turkey Itself The conference (1-day conference, october 19th) kind of frustrated me, as 2/3rds of speeches were in Turkish, so I had to ditch my plan to attend certain events, and half of the time was roaming around the conference floor.\nDear people who stand behind this huge event, Agile Turkey team, please make a note next to the speech, that it may be in Turkish next time :) That would be awesome!\nThe awesome part of that was that English-speaking crowd (mostly invited speakers) were roaming around the vortex (as Kurt Bittner joked) as well. Noone occupied their attention (possibly because of the language barrier), so I\u0026rsquo;ve turned that into 2-3-hour-long interrogations!\nThe Bag \u0026lsquo;Shift Happens. Be Agile\u0026rsquo; has a nice slogan, but poor quality :) Lots of spam from sponsors and small notebook with the pen. Felt like I\u0026rsquo;m on my local UfaDevConf conference.\nSnowden\u0026rsquo;s Keynote I\u0026rsquo;m so glad that I\u0026rsquo;ve attended to one of Dave Snowden\u0026rsquo;s speeches! He\u0026rsquo;s an amazing guy, I love his approach to not treat metholodogies and frameworks as silver bullets, I love how he merges anthropology with IT - and I share this approach wholeheatedly (given my specialization in Applied IT in Psychology).\nKeynote was called COMPLEXITY, CULTURE AND CONFUSION. Snowden described cynefin model, which I find as an universally applicable framework for sense-making. My experience with cynefin emerged when we were trying to find an already-existing model of describing various projects we had at SkuVault with Ksenia. And guess what: it fits and describes how we firefight, develop new features, research/migrate/stuff bumps as a sequence of cause-effect perfectly (and I\u0026rsquo;ll write about that soon).\nKey points:\n- Perception over mindset: I'm so agreeing with him, that mindset cannot be changed after it's declared to be agile: you start with slow process and transparency improvement - and over the time the team becomes more agile. And only then the inner understanding of the business agility is fulfilled. - As soon as the company declares it's now agile - it's definitely the opposite (which is derived from the first bullet). - There's a thin line between simple and chaotic systems in cynefin, and you may even not see if you're already in chaos: it may be calm on the outside. - Work on company's perception among the clients. Clients remember all past negative events you had. Interview the clients / market, and make sure you address the question: 'what can we do so that clients don't say this the next time', instead of justificating your actions. - Company's culture is to be inherited. There should be a knowledge sharing, when the creators transmit their values to the others, share both good and bad experiences over the course of the work. - Waterfall is not bad (thank god finally more and more people start telling that). - And yes, finally, SAFe and NEXUS stop being dynamic, when they scale up! And that's the disconnection from the original Agility idea! The latter part of me interacting torturing Snowden with questions on remote distributed teams with huge timezone difference, processes and estimations was indeed very satisfying! Lesson learned from almost every speaker I had time to chat with: SkuVault\u0026rsquo;s case is unique and you empirically find your own path of comfortable pace, workflow and communication.\nMr. Snowden also shed some light on asynchronous conference calls they had back at IBM, which seems like a very interesting idea to try now.\nKurt Bittner of Scrum.org Kurt Bittner was talking about \u0026lsquo;5 THINGS YOU NEED TO DO TO SCALE YOUR AGILE ADOPTION\u0026rsquo; (http://www.summit.agileturkey.org/session/5-things-you-need-to-do-to-scale-your-agile-adoption/).\n[gallery ids=\u0026ldquo;782,781\u0026rdquo; type=\u0026ldquo;rectangular\u0026rdquo; link=\u0026ldquo;file\u0026rdquo;]\nLater on, I sneaked out to him while he was listening to some old Van Halen stuff, and started to ask tricky questions:\n- How does Scrum work, when the team is distributed, when there's a language barrier, when timezone difference is 9-10 hours? (\u0026gt;\u0026gt; scrum works, but that depends on how comfortable the team is overall with scrum and everyone's got own approach, mixed with constraints that every organization has). - We recently worked on migrating a huge chunk of SkuVault to a new architecture and it was chaotic, is Scrum a good way to handle such? (\u0026gt;\u0026gt; R\u0026amp;D projects may work with Scrum pretty good, however in our case there's no clear answer because using micro-sprints for 1 day and have a whole retro for that seems obscurely inefficient and redundant). - Politics (eww)... Skiing \u0026amp; Hiking in Colorado and generally in the world.. Does iPad Pro 12\u0026quot; really allow you to do general work without bringing your laptop (for mail and notes yup). - Estimates - what does he think of them, do we even need them fully in scrum? (\u0026gt;\u0026gt; Kurt is not a fan of estimates. If you got a timerange - better give it (doing this myself all the time), and estimate is really needed only in times when you have to understand project phase length). - Overcertification, and is there really a problem with Scrum Master certification and poor performance of fresh certified practitioners, which devalues overall CSM / PSM badges? (\u0026gt;\u0026gt; gosh, this is a painful topic to discuss with scrum.org rep, right? :) So the consensus was that SCM certification really only shows that you know the basics, it doesn't tell anyone about your experience on the battlefield and definitely not something to rely on when forcing scrum ;) So in a way, yes, certified people quality in scrum and process building may devalue certification perks... kinda...) Kurt was not just helpful, he\u0026rsquo;s been my savior in the middle of turkish-only-speaking crowd :) I thank him greatly for expanded answers, references to his experience and knowledge sharing!\nOther interesting speeches and people Simon Orell told an interesting story on his experience in applying Scrum (although modified) in building gas turbines (!) in Canada (BILLION DOLLAR AGILE: APPLYING SCRUM VALUES AND PRINCIPLES TO LARGE CONSTRUCTION PROJECTS, ) - COOL!\nScott Ambler told about pragmatic way of looking at company transformation in his \u0026lsquo;THE DISCIPLINED AGILE ENTERPRISE)\u0026rsquo; speech.\n","permalink":"https://maratkee.com/posts/2017-10-30-agile-turkey-summit-2017/","summary":"\u003cp\u003eMe \u0026amp; my colleague basically decided to attend Agile Greece and Agile Turkey, and then exchange opinions and knowledge gathered there. Big advantage of my trip was Dave Snowden\u0026rsquo;s keynote, whom I wanted to catch after the speech and bore to death with silly questions :)\u003c/p\u003e\n\u003ch2 id=\"agile-turkey-itself\"\u003eAgile Turkey Itself\u003c/h2\u003e\n\u003cp\u003eThe conference (1-day conference, october 19th) kind of frustrated me, as 2/3rds of speeches were in Turkish, so I had to ditch my plan to attend certain events, and half of the time was roaming around the conference floor.\u003c/p\u003e","title":"Agile Turkey Summit 2017"},{"content":"Small and duct-tapey resolution for the time, when you have an All -\u0026gt; [statusName] JIRA workflow transition.\nBy default, it results in the following: Default Ticket Screen shows transition from current to current status, among others. So e.g., you have an In Progress ticket, you have the transition to the very same In Progress. To avoid that, use simple conditioning for the transition:\n- Go to transition Conditions - Click Add New - Select 'Value Field' from the given list - Select logical operator 'doesn't equal' / '!=' - And put a value in it (name of current status, and the value to be handled as string) Start Working is the transition name to the \u0026ldquo;In Progress\u0026rdquo; status This is how it looks in Workflow\nThis works in the following way:\n*Perform *\u0026lt;i\u0026gt;Transition (if (Status doesn\u0026#39;t equal string(\u0026#39;currentStatus\u0026#39;) condition is met).* @AtlassianTeam! A good UX would be something like a checkbox, checked by default, and labelled \u0026ldquo;Don\u0026rsquo;t show transition option to same status\u0026rdquo;.\n","permalink":"https://maratkee.com/posts/2017-09-21-jira-removing-transition-from-current-status-to-itself-if-all-transition-is-turned-on/","summary":"\u003cp\u003eSmall and duct-tapey resolution for the time, when you have an \u003cstrong\u003eAll -\u0026gt; [statusName]\u003c/strong\u003e JIRA workflow transition.\u003c/p\u003e\n\u003cp\u003eBy default, it results in the following: \u003cem\u003eDefault Ticket Screen\u003c/em\u003e shows transition from current to current status, among others. So e.g., you have an \u003cstrong\u003eIn Progress\u003c/strong\u003e ticket, you have the transition to the very same \u003cstrong\u003eIn Progress\u003c/strong\u003e. To avoid that, use simple conditioning for the transition:\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e- Go to transition Conditions\n- Click Add New\n- Select 'Value Field' from the given list\n- Select logical operator 'doesn't equal' / '!='\n- And put a value in it (name of current status, and the value to be handled as string)\n\u003c/code\u003e\u003c/pre\u003e\n\u003cul\u003e\n\u003cli\u003eStart Working is the transition name to the \u0026ldquo;In Progress\u0026rdquo; status\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cimg loading=\"lazy\" src=\"/images/all_transition.png\"\u003e This is how it looks in Workflow\u003c/p\u003e","title":"Jira: removing transition from current status to itself (if All -\u0026gt; transition is turned on)"},{"content":"This post is available in English.\nИ делаем это без необходимости прилета в РФ американского гендира.\nПоследние полгода я набивал шишки, ходя по инстанциям, собственно, поделюсь опытом :) Задача: открыть 100-процентную дочку в России (материнская SkuVault.com находится в Луисвилле, Кентукки). Наш случай несколько уникален: CEO не мог посетить РФ, так что заверять и пересылать идентификационные документы приходилось туда-сюда меж двух контитентов.\nНа практике, все делается достаточно просто. Всего-то придется столкнуться с бюрократической машиной Mother Russia (которая за последние годы стала неимоверно удобнее), проблемами с межведомственной коммуникацией, ну да беготней с документами.\nНачнем с основ: список базовых документов для открытия ООО в России выглядит следующим образом:\n- Паспорт владельца - Заявление на открытие ООО - Решение (о создании организации и назначении гендира) Если учредитель - юр. лицо, то список документов дополняется:\n- Документами о создании материнской организации, данные об учредителях, и, как подсказывает нам налоговая - \u0026quot;выписка из торговой палаты, или ее аналога\u0026quot; Ключевые документы по организации в США - Certificate of Existence (когда и кем была зарегистрирована организация); - Annual Report (годовой отчет о состоянии компании); - Letter of Good Standing (документ о финансовом здоровье и отсутствии проблем с налогами); Подавать документы можно только в оригинале, а действительны они будут только подписанные Секретарем Штата (Secretary of State)\n- Берем оригиналы этих трех документов, из списка выше - Несем делать перевод в местное бюро переводов, которое умеет нотариально заверять - Просим бюро заверить нотариально выполненный перевод Бывает, что у материнской организации несколько учредителей. Я вернусь к этому нюансу позже.\nДокументы, подтверждающие личность учредителя материнской организации Наша налоговая, наверное, спит и видит, как у всех людей на свете один и тот же набор удостоверяющих личность документов: паспорт, ИНН, СНИЛС. Ну и соответственно, не удивляйтесь, если инспектор попросит все эти документы по нашему учредителю за океаном. А затем, тот же инспектор будет искренне удивляться (по крайней мере в Уфе это так), что в США в принципе нет внутренних паспортов.\nПо факту же, паспорт гражданина США (который используется американцами для поездок зарубеж) прекрасно подходит. Там нет адреса, так что надо отсканировать водительские права (в которых он есть).\nИтак, вот у нас на руках сканы документов учредителя, которые он прислал по почте:\n- Копия паспорта гражданина США - Копия водительских Переводим документы на русский в уже знакомом бюро переводов, заверяем перевод у нотариуса.\nВозвращаясь к ситуации, когда у американского юр. лица несколько учредителей. Лучше просто взять и перевести документы CEO (если он является одним из учредителей), а соучредителей опустить. Как правило, налоговая на эти вещи особо внимания не образает. В добавок, никаких дополнительных подписей потом не придется получать от всех соучредителей.\nФорма Заявления Разные отделы в налоговой хотят, чтобы заявление было заполнено по-разному. Если вы думаете, что регистрируясь через юридическую контору вы ощутимо облегчите себе жизнь, то вы ошибаетесь =) Не верьте возгласам, что юристы все сделают за вас. Они заполнят документы и побегают с ними по инстанциям, но заверять подписи учредителя, в случае если он отсутствует в России все равно придется самостоятельно. К сожалению, местные юристы за пределами двух столиц, обычно сами не знают полной процедуры и нюансов, а Московские и Питерские компании не консультировали по нашей ситуации, так как у них нет юрисдикции открывать дочерние организации за пределами своего региона.\nЮристы и налоговая обычно утверждают, что заполнять заявление должно быть:\n- Заполнено на кириллице, и только владельцем материнской организации (неправда, документ можно заполнить заранее, остается его только подписать) - Подписано владельцем, с заверенной подписью только на территории РФ (неправда) - Подписано владельцем, с заверенной подписью только в консульстве РФ (частично правда) Проще говоря, в некоторых случаях, налоговая отклоняет подписи, заверенные не в консульстве, или аккредитованной на территории РФ организации. В данном случае, смело требуйте разбирательства, потому что заверять подпись учредителя материнской организации на форме заявления можно у любого нотариуса в США (хотя лучше у русскоговорящего). Самое забавное в этой ситуации то, что российская налоговая утверждает, что только консульство может заверять форму заявления, а консульство РФ в США, в свою очередь, говорит что любой американский нотариус действует с аналогичной юридической силой.\nПуть первый: Консульство родное, сердцу дорогое Если у вас есть готовность потратить кучу времени, чтоб посетить какое-нибудь русское консульство (которых 4 штуки по углам США), и назначить собеседовение (срок ожидания: ~2-4 недели) - снимаю перед вами шляпу.\nВ то время как посольство в D.C. моментально отвечает на корреспонденцию, и быстро берет трубку - консульство в Сан-Франциско больше похоже на ленивцев из Zootopia, и отвечают по почте только через две недели. Кстати, документы можно заверять в консульстве, которое не прикреплено к вашему штату (например гражданин из Кентукки, может записаться на прием в Сан-Франциско).\nТак вот, если вы все же решили наведаться в консульство, то сначала необходимо выбрать свободный слот, оплатить консульский сбор, взять с собой\n- Учредительные документы в консульство (cert. of existence, letter of good standing, annual report) - Документы для подтверждения личности CEO (оригиналы и копии паспорта гражданина США, водительские) - Не забываем отослать заранее заполненные документы и сканы, которые вы хотите заверить и подписать, на почту консульству. У нашей налоговой есть \u0026ldquo;желаемая\u0026rdquo; форма заверенного:\n- Подпись заверена штампом нотариуса в консульстве - Следующая страница содержит информацию о нотариусе, заверившем подпись - Нотариус должен указать количество страниц в документе (дабы не допустить последующей подмены) - Заявление и страница с данными нотариуса должны быть подшиты, и на корешке должна быть печать, объединяющая всё подшитое. Примечание: если регистрируетесь через местную юридическую фирму, которая относит документы в налоговую, пенсионный, и другие инстанции, необходимо написать доверенность (Limited Power of Attorney) от имени владельца, на курьера юридической фирмы (или, соответственно, если вы занимаетесь регистрацией - на вас).\nПуть второй: местный (американский) нотариус Намного проще и быстрее. CEO подписывает заявление у нотариуса, а нотариус заверяет подпись. В идеальном раскладе, нотариус добавляет номер своей лицензии в поле ИНН.\nДоверенность на курьера Дабы подавать документы в налоговую от имени CEO материнской компании, надо написать доверенность (Limited Power of Attorney), сроком на один год, на вас или курьера. Сдать в налоговую надо будет оригинал, а также его нотариально заверенную копию. В доверенности нужно обязательно указать, на какие именно действия доверенность дается.\nРешение (форма о решении создания ООО) С этим документов никакой волокиты вообще нет. CEO подписывает две копии Решения, и ставит печать (печать в штатах обычно перфорированная, не пугайтесь, в России их принимают).\nПодаем документы, ну и сверяемся Отлично! Мы на финишной прямой. Давайте сверим пак документов:\n- Материнская организация: **Certificate of Existence** (с апостилем -\u0026gt; переведенная на русский -\u0026gt; перевод нотариально заверен) - Материнская организация: **Annual Report** (с апостилем -\u0026gt; переведенная на русский -\u0026gt; перевод нотариально заверен) - Материнская организация: **Letter of Good Standing** (с апостилем -\u0026gt; переведенная на русский -\u0026gt; перевод нотариально заверен) - CEO / Учредитель материнской организации: **Водительские Права** (отсканированные + распечатанные -\u0026gt; переведенные на русский -\u0026gt; перевод заверен у нотариуса) - CEO / Учредитель материнской организации: паспорт гражданина США (**US Citizen Passport)** (отсканированный + распечатанный -\u0026gt; переведенный на русский -\u0026gt; перевод заверен у нотариуса) - **2 копии Решения, **заполненные на русском, подписанные CEO / учредителем материнской организации, с печатью материнской организации. - **Заявление, **заполненное на русском, подписанное CEO / учредителем материнской организации, подпись заверена нотариусом. Вот, собственно, и все. Пожалуйста, не забывайте забрать бумажку о подтверждении выдачи вам регистрационных документов из налоговой, а также свидетельства ОГРН / ИНН, и свидетельство о регистрации вашей дочерней организации в России. Оставьте вторую копию Решения себе, так как порой оно может оказаться полезным (например, при открытии счета в некоторых банках).\nСноски:\n- Форма Решения: https://www.regberry.ru/registraciya-ooo/obrazcy-dokumentov/reshenie-edinstvennogo-uchreditelya-obrazec - Форма Заявления: https://www.regberry.ru/registraciya-ooo/obrazcy-dokumentov/forma-r11001-zapolnenie ","permalink":"https://maratkee.com/posts/2017-08-25-ru-%d0%be%d1%82%d0%ba%d1%80%d1%8b%d0%b2%d0%b0%d0%b5%d0%bc-%d0%b4%d0%be%d1%87%d0%ba%d1%83-%d0%b0%d0%bc%d0%b5%d1%80%d0%b8%d0%ba%d0%b0%d0%bd%d1%81%d0%ba%d0%be%d0%b3%d0%be-%d1%8e%d1%80%d0%b8%d0%b4%d0%b8/","summary":"\u003cp\u003eThis post is available in \u003ca href=\"http://kiniabulatov.com/2017/05/24/so-you-want-to-open-us-company-subsidiary-in-russia/\"\u003eEnglish\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eИ делаем это без необходимости прилета в РФ американского гендира.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eПоследние полгода я набивал шишки, ходя по инстанциям, собственно, поделюсь опытом :) Задача: открыть 100-процентную дочку в России (материнская SkuVault.com находится в Луисвилле, Кентукки). Наш случай несколько уникален: CEO не мог посетить РФ, так что заверять и пересылать идентификационные документы приходилось туда-сюда меж двух контитентов.\u003c/p\u003e\n\u003cp\u003eНа практике, все делается достаточно просто. Всего-то придется столкнуться с бюрократической машиной Mother Russia (которая за последние годы стала неимоверно удобнее), проблемами с межведомственной коммуникацией, ну да беготней с документами.\u003c/p\u003e","title":"RU: Открываем дочку американского юридического лица в России"},{"content":"This is basically the anatomy of a distributed team, working on requirements. Key point here is that this is the process working for us, in current configuration, and it\u0026rsquo;s effective.\nDisclaimer: Every organization is different: from internal structure to how it communicates with the outer world. So no workflow is a silver bullet.\n*Disclaimer 2: SkuVault is an ever-improving team of ~50 people, distributed across 10 timezones, 2 different versions, and serving loyal clients worldwide 24/7. Learn more about Communication in distributed teams: Messenger \u0026amp; Rules, or *Why we ditched Scrum, in favor of Kanban in JIRA\nIn order to let developer work as productive as possible, management should ensure the following bits related to her work are tackled:\n- Requirements Fallback - whom to ask - Issue Description \u0026amp; Decomposition - No interruption We moved closer to \u0026rsquo;no interruption\u0026rsquo; bullet by creating on call teams, that are reacting to whatever urgent issues arise. (hållo to Kniberg\u0026rsquo;s Scrum from the Trenches 2nd edition - our own way of \u0026lsquo;firefighting teams\u0026rsquo;!).\nHowever, there was no requirements preparation workflow a while back, so as the features grew more complex, more dependencies were discovered, we faced the inevitable given our product size: scope creeps, miscommunication, conclicting scenarios and inconsistency.\nIn order to bring all departments that were related to requirements eliciting and approval, we\u0026rsquo;ve created Product Management flow, which had to be highway to hell to better requirements.\nProduct Management Flow We aimed to tackle the following areas by creating a formalized workflow:\n- Easy to understand sequence of steps - Each step has an accountable person, visible to all participants - Workflow encourages Argumentation and Discussion -\u0026gt; no misinterpreted suggestions and details are hashed out collaboratively - Each step ensures higher quality requirements, by providing criterias to be met on the output Workflow consists of sequential steps: New Issue -\u0026gt; Discovery -\u0026gt; Sign Off -\u0026gt; Analysis\nmind the typical bad estimation of space on the left :P\nNew Issue Ticket is created by trigger from multiple sources (marketing, services, tech, customer support forums,..). During this state, the ticket is relatively empty, providing only the request and source of the request.\nTransition: In order to move the issue to the next stage, Product Owner reviews whether we\u0026rsquo;ll ever do this feature. If no - he closes it. Yes, sometime - he moves the ticket to Backlog. Yes, near-future - he moves it to Preliminary Analysis.\nPreliminary Analysis (Discovery) Step Goal: Product owner should outline Feature goal (what we need to achieve, benefits for our company and customers); describe basic business process (general 1-2 sentenses on how it works among the warehouse, since we\u0026rsquo;re a warehousing solutions company); and add that to wiki-page for that feature.\n**Example: **\nBrief feature description\nShipments are a way to track sale items that have been shipped to the customer of the Sale. A Shipment exists in SkuVault once a Tracking Number is assigned by the carrier.We want to provide an ability to connect and save tracking numbers, so that our users can have more visibility and editing right inside the app.\nWhat do we want to achieve Allow people that use shipping providers that don\u0026rsquo;t integrate with marketplaces as SkuVault How it works on the warehouse\nGoal: Allow clients to label products with tracking number, and see shipments in relation to Sale they are attached to\n- Picker gets to the QC table - QC performing person takes the product, QCs it and labels the product with shipping label and tracking number - The tracking number is added to the system and can be visible in relation to the sale - User tracks the product via tracking number Stakeholder Sign Off Since there\u0026rsquo;s quite a stream of tickets, we let Stakeholders approve bunch of tickets at a time. Someone might say \u0026lsquo;Hey, isn\u0026rsquo;t that Product Owner\u0026rsquo;s responsibility, to approve?\u0026rsquo;. Well, first of all our product is big and includes different areas and domains: services, marketing, tech, operations - all having their own pursuits respectively, even if we\u0026rsquo;re moving towards the same goal.\nStep Goal: approve the idea, general process and timeline for the feature to be developed.\nThe next step would be to gather related parties and start..\nAnalysis Analysis is biggest, most collaborative and complex part of the workflow. It involves:\n[Business Analysts (creating User Stories)] =\u0026gt; [collaborative efforts between BAs / UX / Developers (Wireframing)] \u0026lt;=\u0026gt; [BA / Developers (requirements adjustments, brainstorms, decomposition and clarification)].\nOutcome: clear and atomized User Stories with Backend Subtasks with estimates, that give you ability to grasp and plan the feature for development. By you I mean us, Project Managers :)\nExample: User Story - formalized and easy to grasp description, representing user activity and ability to interact with it.\nPrecondition: user is on Sale Info page\n- Before the user clicks a Shipment Tab in the Sale Info page, the hint at the top says \u0026quot;Click a Shipment for Detailed Information\u0026quot; - When the user clicks a Shipment line they see complete Shipment details at the top. list of fields for Shipments can be seen in Shipments - Plans / Technical Requirements - They can click a button for Shipped Items or Total Cost to see detail for the items. - If a Tracking URL exists for a shipment the user can click it to open the URL in a new tab. \u0026lt;li\u0026gt;After new tab opens, user is navigated to shipping carrier website with tracking url info - If there is not a tracking url user simple sees \u0026quot;Unknown\u0026quot; instead of the url. - If a Label (ie: PDF) is present, the user can view it in a new tab, or download it by clicking on 'Download' button Post-condition: user is able to see related Shipments info We got strict rules for creating user stories, technical tasks, support requests and bug reports. This ensures same standards across out task-tracking system (Jira, and properly used Kanban magic) for different issue types, and allows to interpret requirements with the single possible way (which is extremely helpful :). Nutshell Right, so in a nutshell, this dramatically increased our requirements quality, and gave us ability to start analysing scope creeps properly, visibility for similar projects and better prognosis. There are things to improve, such as redundancy removal from the requirements, optimizing time spent on the workflow, better communication when estimating client requests - we\u0026rsquo;re getting closed to that!\n*one more thing: \u0026ldquo;oh, author, your flow is redundant for smaller features!\u0026quot;. You\u0026rsquo;re right, just remove sign off phase and ease analysis to accomodate simple story description for that feature / improvement ;). *\n","permalink":"https://maratkee.com/posts/2017-08-24-how-to-ensure-requirements-quality-skuvault-way/","summary":"\u003cp\u003eThis is basically the anatomy of a distributed team, working on requirements. Key point here is that this is the process working for us, in current configuration, and it\u0026rsquo;s effective.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eDisclaimer: Every organization is different: from internal structure to how it communicates with the outer world. So no workflow is a silver bullet.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003e*Disclaimer 2: SkuVault is an ever-improving team of ~50 people, distributed across 10 timezones, 2 different versions, and serving loyal clients worldwide 24/7. Learn more about \u003ca href=\"http://kiniabulatov.com/2017/05/22/communication-in-distributed-teams-messenger-rules/\"\u003eCommunication in distributed teams: Messenger \u0026amp; Rules\u003c/a\u003e, or *\u003ca href=\"http://kiniabulatov.com/2017/07/17/why-we-finally-ditched-scrum/\"\u003e\u003cem\u003eWhy we ditched Scrum, in favor of Kanban in JIRA\u003c/em\u003e\u003c/a\u003e\u003c/p\u003e","title":"Workflow for the Requirements in the Distributed team"},{"content":"Warning: don\u0026rsquo;t misinterpret scrum for agile as a whole :)\nAround a year ago I wrote a yearly retrospect on how the workflow at SkuVault is organized, and how we set up our jira boards to work in sprints.\nsprints and their goals There was no Kanban backlog at the moment, and we used Scrum board as an improvized scrumban tool: we had the sprints, which were treated as folders to fit tickets in some time period. Classical sprints were not suitable for our workflow, I mentioned the reasons in Year Retrospective @ SkuVault. So that sprint-folder system was great, visible and allowed us to predict.\nYet, in a year period the signal that our approach (sprints as folders) doesn\u0026rsquo;t quite work appeared - there was a number of tickets migrating from sprint to sprint being rescheduled over and over.\nAllow me to add a small note here on SkuVault specifics: There are different categories of work, and planning a common roadmap doesn\u0026rsquo;t quite work either: we get different priorities from different departments (QA, Product Management, Services and Angry Clients, Services and Happy and Willing to Pay clients) - so the urgent ticket scope inflates. Urgent tickets may require distraction of a developer working on some client request, which shifts the timeline for delivery. So, in a nutshell: there is no unified roadmap between different categories or depts - there is a near-term plan only, with each category having it\u0026rsquo;s own stack of priorities. Now add to this a remote team that works in collaboration across atlantic and with the timezone difference of 9-10 hours :)\nSkuVault is a distributed team of awesome people, spreading across 9 timezones, or sometimes more. Notice how pathetic I am when it comes to image editing. Those are not cute animals - those are coat of arms symbols, lol :)\nSo a question is: how to remodel the workflow to reflect the specifics?\nBuckets and Kanban We came up with the idea of buckets: basically those are categories of work, originating from different departments with separate product owner responsible for stack of priorities.\nLast year Atlassian finally realised the scenarios teams use their product for. So, Backlog for Kanban was born out of desperate cry of thousands of PMs, Teamleads and other people who cannot develop themselves and just drag and drop tickets on the boards (/sarcasm).\nThe feature came out quite handy and we were able to merge our workflow with our development process IRL.\nFinally, there\u0026rsquo;s an option to see upcoming backlog you can both groom and plan inside, and drag that to ToDo as the near-term goals! Don\u0026rsquo;t forget to estimate that properly ;)\nBacklog Kanban allowed us to re-evaluate a lot of backburners that were hanging out there, never getting into the sprints. It also gives us a cleaner board - cause you can store current workload apart from near-term plans, yet in the same board. It\u0026rsquo;s something you already get with scrum boards, just without sprint management.\nCurrent State We attacked backburners and development scope from two fronts:\n- created a separate IDEAS project, where tickets were getting fully fleshed out prior to development; - moved all of the backlog tickets that were on the shelf in development projects back to the IDEAS, to re-evaluate; This + we\u0026rsquo;ve added Buckets System, with the support of limited number of devs in the pool for each bucket. I\u0026rsquo;ll try to write a separate post on how Buckets work in our company later (spoiler alert: they work only as indicators of ticket origins, otherwise - they are kind of not really helping, as of the current state, after some teams shuffling :)\nBoards, Workflows, and two Backlogs We\u0026rsquo;ve got two workflows - one for preparing the ticket for ready-to-be-developed state, the second is for development itself.\nEach workflow has it\u0026rsquo;s own board - as you know, boards are the best ever unicorn rainbow tool to show state of the project from a particular angle.\nSo two boards reflect those workflows.\nIDEAS Board (Also called pre-development), managed by Product Management. Includes it\u0026rsquo;s own backlog for backburners, that we put in the shelf for some time (or close to forever); Sign Off, Detalization and Formalization, Architecture Review and finally Ready to Schedule states. Each step has a description and a format of how it should look.\nThe point of this board is to reflect status of every single idea that we decided to evolve into a feature, and to see the bottlenecks in Product Management workflow.\nTicket on the right is not violet - it\u0026rsquo;s just blocker by another Core task\nPDM Workflow Establishing that IDEAS board was also a result of creating full Workflow for Product Management, without letting the ticket out of the IDEAS project and into main SkuVault development project, until all the details and edge cases are fleshed out (well, you caught me - there is no chance you get all 100% of edge cases, but you should try as hard as you can). By creating standards for each step of formalizing the ticket, we\u0026rsquo;ve ensured the consistent quality of ready-for-development tickets, which ensured that they won\u0026rsquo;t be put on hold until clarification from API partner / Client / Product Management. You don\u0026rsquo;t get big stream of tasks pouring into development, but the quality of such tickets lets developers be distracted less and be more motivated, because who wants to switch context and work on something unfinished.\nDevelopment Board As I pointed out in previous posts - development board is pretty much untouched -\u0026gt; if it works, don\u0026rsquo;t break it :)\nBut the utilization of Kanban Backlog in JIRA came quite handy for both of the boards: you are able to have a set of tickets in the backburner, still in same project, but not wasting ginormous amounts of space on the board -\u0026gt; you just access all backlog via a special planning view.\nPre-Development Board Backlog\nWhile IDEAS board has a backlog with things, that should sit on the shelf for some time, Development board utilizes kanban backlog in a slightly different manner: I store optimization tickets that we need to check every couple of weeks / months there; as well as User Stories for Epics, that are still in IDEAS, that we didn\u0026rsquo;t get into development yet; or it\u0026rsquo;s a very handy way to form a pool of tasks for upcoming developers.\nDevelopment Board - Backlog. Two Magento versions support is on hold -\u0026gt; we\u0026rsquo;ll reevaluate them in the coming months - they\u0026rsquo;re waiting for their turn.\nJIRA also support swimlanes for boards, which is utilizied by us in a manner of separating projects one from other:\nThree projects in Progress for Shawn -\u0026gt; Lots, QC Improvements, Shipments. The higher the project\u0026rsquo;s swimlane - the higher it\u0026rsquo;s priority.\n..in a nutshell - We've ditched sprints, in favor of Kanban. It's much easier to not pointlessly drag and drop tickets from one sprint to another, if they're not ready. As I wrote, Urgent tasks needing on call devs contradicts with uninterrupted scrum approach for developing concrete chunks of functionality in a given timebox (mind the fact that scrum and agile as a whole deals with deadlines badly, while we have deadlines most of the time); - Kanban gave us differentiation by projects on one board, without making the board too crowded. Scrum boards give that too, but count the hassle of moving unfinished tickets from one sprint to another, which doubles the maintenance work; - Kanban Backlog is a great feature, allowing us to manage all tickets in the project. We could have done this in two boards (one for new tickets to be moved to agenda or closed, and another for development / formalization itself) - but now we can manage all tickets in one. Neat. - We had an Urgent Board (Kanban Workflow), and Development in Sprints (Scrum) -\u0026gt; now that we moved Development itself to Kanban, we were able to unify the boards, and everything, from minor to blocker tasks, is visible on the same Board! This is great! - Never use scrum rituals just for the sake of rituals. We didn't use sprints for the sake of sprints, we approached sprints as folders and timeboxes. However it's a common mistake, while management or teams create a cargo-cult for scrum. Most likely you'll use different practices and methodologies over the time, and finally will come to a hybrid approach that makes you efficient. - There are different companies, and certainly there's no silver workflow bullet for all. So given the maturity / infrastructure / tech. stack / staff - you should model the workflow related and reflecting the flows inside that particular company. SkuVault is changing, growing, scaling - and so is the workflow. Different depts can have different workflows - and we reflect that. ","permalink":"https://maratkee.com/posts/2017-07-17-why-we-finally-ditched-scrum/","summary":"\u003cp\u003eWarning: don\u0026rsquo;t misinterpret scrum for agile as a whole :)\u003c/p\u003e\n\u003cp\u003eAround a year ago I wrote a yearly retrospect on how the workflow at SkuVault is organized, and how we set up our jira boards to work in sprints.\u003c/p\u003e\n\u003ch3 id=\"sprints-and-their-goals\"\u003esprints and their goals\u003c/h3\u003e\n\u003cp\u003eThere was no Kanban backlog at the moment, and we used Scrum board as an improvized scrumban tool: we had the sprints, which were treated as folders to fit tickets in some time period. Classical sprints were not suitable for our workflow, I mentioned the reasons in \u003ca href=\"https://kiniabulatov.com/2016/06/17/year-retrospective-skuvault/\"\u003eYear Retrospective @ SkuVault\u003c/a\u003e. So that sprint-folder system was great, visible and allowed us to predict.\u003c/p\u003e","title":"Why we ditched Scrum in favor of Kanban in JIRA"},{"content":"Jira is flexible, yet complex tool in some cases :)\n- In order to make the fields (inline as well) editable, when the ticket is closed, go to Workflow -\u0026gt; Select 'Closed' status -\u0026gt; Click Properties - There would be flags with bool values: we need jira.issue.editable - ![](/images/edit_closed_issue-e1496131332151.png) - In case you see jira.issue.editable is false - either change that to true or delete the property key with prev. value. - Don't forget to publish the updated workflow. ","permalink":"https://maratkee.com/posts/2017-05-30-jira-how-to-allow-editing-fields-for-closed-tickets/","summary":"\u003cp\u003eJira is flexible, yet complex tool in some cases :)\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e- In order to make the fields (inline as well) editable, when the ticket is closed, go to Workflow -\u0026gt; Select 'Closed' status -\u0026gt; Click Properties\n- There would be flags with bool values: we need jira.issue.editable\n- ![](/images/edit_closed_issue-e1496131332151.png)\n- In case you see jira.issue.editable is false - either change that to true or delete the property key with prev. value.\n- Don't forget to publish the updated workflow.\n\u003c/code\u003e\u003c/pre\u003e","title":"Jira: how to allow editing fields for closed tickets"},{"content":"This post is available in Russian.\n*And do it without the CEO flying all the way down to your city :) *\nLet me share a bit of an experience from past 6 months :) We wanted to open a branch in Russia (parent company is in US). Our case is a bit unique: our CEO wasn\u0026rsquo;t able to visit Russia, so we had to verify and send the list of docs back\u0026rsquo;n\u0026rsquo;forth between two continents.\nActually, that\u0026rsquo;s not as complex as it seems. You just have to deal with bureaucracy (which dramatically improved over the past years) and intradepartmental miscommunication, and, well, running with pack of docs to veryfy them in both countries.\nLet\u0026rsquo;s get to the basics - list of docs needed to open up a company in Russia:\n- Owner's passport - Application form (to open up an LLC) - Decision form (to create a company and assign a general manager) The list alters just a bit if the owner is to be another company:\n- Documents on establishing parent organization, who owns it and as the russian tax dept states: note from Department of Trade or some analogy - The rest is the same as above. Parent Company Docs in US Main company docs in US are:\n- Certificate of Existence (when the company was opened and by who); - Annual Report (yearly report on company state); - Letter of Good Standing (report on company tax health); You got to file only document originals, signed by Secretary of State!\n- You take the document originals - You translate them at translational bureau - That bureau should also notarize the translation There are cases, when company has several owners. I\u0026rsquo;ll get to it in the section below.\nDocs to Confirm Parent Company Owner Identity Russian Tax dept dreams of all people in the world having same documents, as Russian Citizens (passport, INN (analogue for SSN, that doesn\u0026rsquo;t allow to steal identity :), SNILS (pension fund info card). So you may be stunned for a sec when a receptionist asks that info from US citizen. And it usually stuns the whole dept, when they are explained that there are no inner passports in US (only for foreign travels). Jesus Christ, those barbarians use non-canonical (USSR-influenced) pack of personal documents -\u0026gt; send in the inquisition..\nWell, in reality passport of a US citizen (for a foreign travel) works great. The biggest issue here is that such passport doesn\u0026rsquo;t contain info on where the person lives (and this is essential in Russian world perception - how can you not be attached to the particular address in your main document?!). This issue is resolved by copying Driver\u0026rsquo;s Licence that includes living address.\nSo, in a nutshell, documents company owner needs to send to Russia are:\n- Copy of Passport of a US Citizen - Copy of Driver's Licence Those documents are processed in Russia, before filing:\n- Passport and Driver's Licence are translated - Translation notarized Now, getting back to the question, where you got multiple company owners. You don\u0026rsquo;t want the pain to be worse, so you better process docs of CEO, and not co-owners. That will make it easier and won\u0026rsquo;t require additional signatures on other documents.\nApplication form Different branches of Tax Dept want the Application to be filled in different sadistic ways, which I\u0026rsquo;m not the fan of. If you work with some lawyer firm, that makes it all for you - DON\u0026rsquo;T BELIEVE A WORD! Well, they will fill up many docs for you and even run and sign them for you. However, some things they cannot do - e.g. verifying signatures of company owner, if he\u0026rsquo;s not in Russia. In fact, good lawyers on creating international branches can be found in their natural habitat: Moscow and Saint Petersburgh. And since those lawyers don\u0026rsquo;t work with other regions (they can\u0026rsquo;t create international branches in other region jurisdictions) - \u0026ldquo;move along, nothing to see here\u0026rdquo;.\nMany law firms and tax dept themselves will tell you the only option available for Application Form to be filled. It includes:\n- Filling only in Cyryllic and only by parent company owner (bogus - you can have the full document ready, and only to be signed ) - Signing by owner, with signature verified ONLY in Russia (bogus) - Signing by owner, with signature verified ONLY in Russian Consulate (half-bogus). Getting to the last point: in fact sometimes tax dept may reject signatires not verified by Consulate or some legal Russian Federation entity. That sucks. You know what else sucks (and works!): you can verify owner\u0026rsquo;s signature on application form at any notary in US (it\u0026rsquo;s better be Russian-speaking notary, and there are loads of them in almost every country corner - in Louisville, at least, we found one). Why did I mention the \u0026lsquo;sucks\u0026rsquo; part? Because Tax dept (and Lawyers) in Russia state that only Consulate should verify signature on application form, but Russian Consulate and Embassy state that US-based notaries (even not speaking Russian ones) have the same power to verify the signature!\nRussian Consulate Way You are lucky! If your CEO got zillions of time to visit Russian Consulates (which are located in the corners of east and west coasts), to schedule appointments there and deal with GRBM (great russian bureacratic machine), which has it\u0026rsquo;s gears oiled by thick wax, and thus running slow.\nWhile D.C. consulate is fast to reply and it\u0026rsquo;s quite easy to reach it out by the phone - SF consulate, on the contrary, replied to me after 2 weeks passed. Small hack: you can also verify docs in the consulate you are not attached to (e.g. KY citizen verifying docs in SF) - but clarify that moment first (just in case).\nYou first have to pick free slot (usually a month or two away from current date), pay consular fee and verify the signature.\n- You got to pick your company docs (cert. of existence, letter of good standing, annual report) and bring them to the consulate - You got to bring your personal docs (originals and copies of US Citizen Passport and Driver's Licence) - You got to send already filled forms you want to verify notarize or sign, via email. Not really handy, but tolerable. After you get into the consulate, you got to verify company owner signature. It should look the following way: signature verified, with stamp of a notary in a consulate. The next page is an info of a notary, that has verified the signature. Notary should also state the number of pages in the document (so that there are no replacements afterwards). Both Application form and Notary page should be stitched together and stamped on the stitched place.\none more thing to mention: if you\u0026rsquo;re working with lawyer firm, and it handles the filing of docs to the tax depts and social funds, you should write Limited Power of Attorney from the owner to the law firm\u0026rsquo;s courier (or yourself, if you\u0026rsquo;re in charge of the branch creation)\nLocal Notary Way It\u0026rsquo;s much faster and easier. CEO signs the application form at any notary, and a notary verifies the signature. It would be ideal, if the notary would enter her notary licence number (in the INN / ИНН) field.\nLimited Power of Attorney In order to file documents for company creation, we got to write Limited Power of Attorney, for one year, for a person who would file it. You will need an original POA and a notarized copy.\nDecision Form Easiest part is the decision form. CEO should just sign 2 copies of Decision Form, it and stamp them with organization stamp. Don\u0026rsquo;t worry about non-ink stamps that are common in US - they are accepted in Russia.\nFiling: verifying the list Congrats - you\u0026rsquo;re finally gathered all of the docs needed! Let\u0026rsquo;s verify the list:\n- Parent company: **Certificate of Existence** (apostilled -\u0026gt; translated into Russian -\u0026gt; translation should be notarized) - Parent company: **Annual Report** (apostilled -\u0026gt; translated into Russian -\u0026gt; translation should be notarized) - Parent company: **Letter of Good Standing** (apostilled -\u0026gt; translated into Russian -\u0026gt; translation should be notarized) - Parent company owner / CEO: **Driver's Licence** (scanned + printed in Russia -\u0026gt; translated into Russian -\u0026gt; translation should be notarized) - Parent company owner / CEO: **US Citizen Passport** (scanned + printed in Russia -\u0026gt; translated into Russian -\u0026gt; translation should be notarized) - **2 copies of Decision Form** filled in Russian, signed by parent company owner, with parent company stamp on it. - **Application Form** filled in Russian, signed by parent company owner, with notarized (in US) owner's signature, and notary's info attached to the application form. Russian bureaucrats would ideally prefer Application Form and Notary's Note on number of pages stitched together, and stamped in the stitched place, so that no pages could be replaced afterwards. But that's not mandatory. That\u0026rsquo;s all folks! Don\u0026rsquo;t forget to take confirmation papers on documents receiving by the tax dept, as well as OGRN / INN papers, and certificate of existence in Russia. Keep 2nd copy of Decision form to yourself as well, you may needed it in the bank or some other institution sometimes.\nRussia is great, don\u0026rsquo;t let bureacracy ruin the experience! ;)\nReferences:\n- Decision form: https://www.regberry.ru/registraciya-ooo/obrazcy-dokumentov/reshenie-edinstvennogo-uchreditelya-obrazec - Application Form: https://www.regberry.ru/registraciya-ooo/obrazcy-dokumentov/forma-r11001-zapolnenie ","permalink":"https://maratkee.com/posts/2017-05-24-so-you-want-to-open-us-company-subsidiary-in-russia/","summary":"\u003cp\u003eThis post is available in \u003ca href=\"http://kiniabulatov.com/2017/08/25/ru-%d0%be%d1%82%d0%ba%d1%80%d1%8b%d0%b2%d0%b0%d0%b5%d0%bc-%d0%b4%d0%be%d1%87%d0%ba%d1%83-%d0%b0%d0%bc%d0%b5%d1%80%d0%b8%d0%ba%d0%b0%d0%bd%d1%81%d0%ba%d0%be%d0%b3%d0%be-%d1%8e%d1%80%d0%b8%d0%b4%d0%b8/\"\u003eRussian\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003e*And do it without the CEO flying all the way down to your city :) *\u003c/p\u003e\n\u003cp\u003eLet me share a bit of an experience from past 6 months :) We wanted to open a branch in Russia (parent company is in US). Our case is a bit unique: our CEO wasn\u0026rsquo;t able to visit Russia, so we had to verify and send the list of docs back\u0026rsquo;n\u0026rsquo;forth between two continents.\u003c/p\u003e","title":"So you want to open US-company subsidiary in Russia"},{"content":"In order for the distrubited teams to work, you got to have a clear flow, a set of general rules, that will fence the process and allow people to collaborate effectively around the globe. If everything is set up correctly, you are able to create amazing products with global professionals, and cover customer support 20+ hours a day.\nCommunication What do you miss most when working outside of the office? Procrastination!\nCommunication that is effortless in office envoronment may be not as natural in distributed teams.\nMessenger (SkuVault uses Telegram, chosen for it\u0026rsquo;s simplicity, availability across all platforms, stability gorgeous GIF bot) and videochat software are there to try to equally substitute verbal communication.\nDue to project specifics, we have the following channels in telegram:\n- Urgent chat, where On Call \u0026amp; Quality Assurance teams collaborate in order to resolve outstanding issues as fast as possible (you can read more about On Duty teams in my previous post on year retrospective); - Dev chat, that is general for all devs, covering the questions of \u0026quot;Who the hell broke QA again?\u0026quot;, ..., to \u0026quot;So have you seen Azure copied Amazon pricing plan\u0026quot;. - Russian Dev chat, due to significant part of the team being russian-speaking, is for fast communication and clarification across russian devs; - Quality Assurance chat, for questions and discussions across QA members; - Freshdesk feed, for fetching freshly issues support tickets, so that if immediate attention needed -\u0026gt; relevant people are informed; - separate project chats with various messaging activity, depending on how big and urgent the project is. Telegram Telegram is extremely handy when it comes to making life easier. We use:\n- hashtags, to mark needed messages in order to find them later. That could be #shipstation hashtag to mark everything related to ShipStation integration across all chats; - mentions, which allow to ping a person even if the chat is muted. So if dev doesn't want to get tons of messages on a related subject, he still is notified when he's mentioned; - great gif support (not only kittehs, but also when you need gif with reproduced bug); - bots! we fetch freshdesk support tickets, notified about engine and web errors thanks to telegram bot api :) - size, platform availability, stickers, e.t.c. now this sounds like a telegram evangelism\nVideo Conference When it comes to video conferencing, we use hangouts, since skype app is awful.\nGeneral Flow and Jira Ticket Descriptions It\u0026rsquo;s bad when you lack information on stuff you need to implement. In order to minize that, we have rules on filling out the ticket, so that as less questions as possible are raised.\nTicket description has testing plan, implementation plan, sequence of steps on how the feature should work, client and needed sandbox credentials, and tons of other information. Now that doesn\u0026rsquo;t prevent requirements change, scope creeps, blind spots (we all know that software development is an endless pain and all related people should suffer), but it surely reduces questions to clarify / misunderstanding / delays to the bare minimum and greatly helps in communication.\nGeneral Flow for the ticket before it hits implementation requires it\u0026rsquo;s acceptance by PM and dev, so those are members who control whether ticket is clear enough or not.\nWorkplace Attendance Although you are not obliged to come to the office, it\u0026rsquo;s still essential to be at your workplace during working hours. If you\u0026rsquo;re working flexible hours, you need to agree upon them with a manager or people you collaborate with, so that you have a consensus solution on comfortable time to work for all.\nCalendar lists days off, while chatrooms are good to inform colleagues about hours off, if necessary.\nWorking remote takes self-dicipline and responsibility, but pays off really great.\nNotifications for pinging stuck projects Be sure you use various notifications, such as jira web hooks + telegram, email notifications on stuck code review or testing, color coding on project management boards for due dates and approaching deadlines. Alltogether, those measures prevent unexpected situations and make the risk of missing deadlines, reduces the risk of tickets stuck halfway, keeps you alarmed in almost all cases where the flow takes wrong direction.\n","permalink":"https://maratkee.com/posts/2017-05-22-communication-in-distributed-teams-messenger-rules/","summary":"\u003cp\u003eIn order for the distrubited teams to work, you got to have a clear flow, a set of general rules, that will fence the process and allow people to collaborate effectively around the globe. If everything is set up correctly, you are able to create amazing products with global professionals, and cover customer support 20+ hours a day.\u003c/p\u003e\n\u003ch2 id=\"communication\"\u003eCommunication\u003c/h2\u003e\n\u003cp\u003eWhat do you miss most when working outside of the office? \u003cs\u003eProcrastination!\u003c/s\u003e\u003c/p\u003e","title":"Communication in distributed teams: Messenger \u0026amp; Rules"},{"content":"So it happened - I managed to gather 2 people for PM \u0026amp; BA meetup (without any PR xD).\nAfter visiting Vienna, I desperately wanted a platform to share knowledge or / and mock each other on PM \u0026amp; BA failures. So I created one: Ufa Project Management \u0026amp; Business Analysis Group Initial meeting consisted of Me, Nur (from modulbank.ru - online bank for small businesses) and Oleg (from smena.io - various crms / solutions for partners). Both work as analysts at cool and interesting teams.\nSo thank you, @Nur and @Oleg :) First meeting went nicely, at my favourite coffe place Chat House. Meetup went as expected: we\u0026rsquo;ve shared experience and discussed who works via which workflow, how we formalize requirements and what are the places we store them.\nI miss good ole Ufa42 Conference, I think we gotta revive it :)\n","permalink":"https://maratkee.com/posts/2016-10-20-project-management-business-analysis-meetup-ufa/","summary":"\u003cp\u003eSo it happened - I managed to gather 2 people for PM \u0026amp; BA meetup (without any PR xD).\u003c/p\u003e\n\u003cp\u003eAfter visiting Vienna, I desperately wanted a platform to share knowledge or / and mock each other on PM \u0026amp; BA failures. So I created one: \u003ca href=\"https://www.meetup.com/Ufa-Project-Management-Business-Analysis-Meetup/\"\u003e Ufa Project Management \u0026amp; Business Analysis Group \u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eInitial meeting consisted of Me, Nur (from \u003ca href=\"https://vc.ru/p/modulbank-office\"\u003emodulbank.ru\u003c/a\u003e - online bank for small businesses) and Oleg (from \u003ca href=\"http://smena.io\"\u003esmena.io\u003c/a\u003e - various crms / solutions for partners). Both work as analysts at cool and interesting teams.\u003c/p\u003e","title":"Project Management \u0026amp; Business Analysis Meetup - Ufa"},{"content":"\nRecently my colleague, Tim, decided to try out Planning Poker, to have better estimations. Planning is essential, and scrum already offers a framework of how to deal with planning. But over the course of my work and experience with scrum techniques, team usually shapes\nPrevious experience showed that daily scrum meetings are merely pointless. Direct communication / skype / IM is much more efficient. Especially in distributes teams.\nAnd following each and every ritual from scrum routine is time and efficiency consuming during the first iterations, since agile methodologies need a good deal of instructions. Usually, after some time teams shape up scrum as they want, and it just works, so from my experience it\u0026rsquo;s not essential to follow scrum by the book (Agile Estimating and Planning book by Mike Cohn, written 10 years ago). Here are additional thoughts on why our transatlantic distributed team doesn\u0026rsquo;t fully fit into planning classic scrum and it\u0026rsquo;s rituals:\n- Due to out product having two versions, we sometimes have developers jumping in and out of projects; - Since we're distributed and flexible - it's hard to incorporate planning poker with all it's \u0026quot;team that takes the hint\u0026quot; practice. Distributed team of two-three people can handle classic scrum, but not bigger one. - In order for classic scrum to work, team must be onsite (together in one place), and everyone should be in one timezone. That's not our key point, we're strong in our flexibility, adapting to challenges and different projects. Scrum meetings are not that effective, when one part of the team has finished work day, and the second one only starts with the fresh brains 😊 Story Points vs Ideal Days and time estimates - Story Points are valuable when it comes to relative complexity (e.g. that task is twice more complex as this one), and when the team has sort of fog of war before them. However, when elaborating on stats from burndown chart and calculating Focus Factor, we go to the point of calculating how many points / ideal days of uninterrupted development do we need. All because we need to know how to squeeze features into sprint timebox. - If you work with JIRA Story Points are not as comfortable to work with, as Original Estimate field. [Subtask story points do not sum up in parent ticket,](https://answers.atlassian.com/questions/103623/how-to-use-estimations-of-subtasks-in-story-points-for-burndown-chart) unlike original estimates. - Story Points lack 'remaining story points' bit, which is uncomfortable once user story has spilled over to the next sprint. Original Estimate, in this case, can be complimented with Remaining Estimate field. - It's not convenient to estimate buffers for unplanned work with Story Points. - At the end of the day, Story Points are calculated to that very same hours developers spends effectively inside a timebox. Do we need an additional layer of calculations, if it will eventually come to measuring time? ## Planning Poker Planning poker is a ritual before the sprint, where the team (devs, qa) estimates upcoming user stories by a consensus-estimate (average estimate of all team members), assigns user stories to developers, and discusses possible roadblocks collectively. Don\u0026rsquo;t have anything against that, but it often comes out time consuming (not that critical as it sounds, actually), and shows lack of detail from other estimators. Moreover, planning poker usually means that devs themselves think about which ticket is to take, which is quite hard to do when we have such a vast scope (~1300 tickets in backlog) + ~2 sprints planned ahead.\nBut let\u0026rsquo;s omit devs and tickets self-assignment and time consumption. That\u0026rsquo;s all tunable.\nThere are online tools for planning poker:\n- [https://www.planningpoker.com](https://www.planningpoker.com/) - [http://nearsoft.com/resources/tools/planning-poker/](http://nearsoft.com/resources/tools/planning-poker/) Estimations and Forecasting Man Day != Calendar Day, because developer gets distracted during man day. So none of these terms reflect what we need.\nStory Point is too abstract. Let\u0026rsquo;s use Ideal Day term, meaning 6 hours of undistracted work.\nKey questions to answer when making a good plan (cynical comment: plan is worthless, planning is essential, as Napoleon said) are the following:\n- How many ideal days on average are in sprint. - How many ideal days can certain developer actually works per sprint. Once again, Ideal days != calendar days.\nBuffers and Planned Days While starting to estimate and plan back in August, I started by making buffer of 0.5 day, thus making development occupy other 4.5 days in the sprint.\nCurrently it\u0026rsquo;s 1.5 days buffer, and 3.5 days of development. This may not be enough, as I\u0026rsquo;m continuing to tune and gather stats on that. I think that somewhere closer to 3 days is tolerable.\nMONTH TIME BUFFER / SPRINT PLANNED DAYS August 0.5 4.5 September 1 4 October 1 4 November 1.5 3.5 December 1.5-2 3-3.5 - I'm aiming at 3 days of development for devs, and 2 days for code review / scope creeps / finishing up tickets that are reopened; - Time buffer includes time for Code Review, fixing Reopened Tickets, other distractions; - Planned Days = Ticket Estimated in Ideal Days multiplied by Complexity Multiplicator. Such empiric way is basically the same focus factor scrum is offering, but without a layer of story points that you later need to convert. And btw, it falls into same ratio I had during previous two projects, which is 2/3 development, 1/3 buffer for fixes and everything else. Seems like more or less ratio across projects then.\nComplexity Multiplicator Plus we have complexity factor, which helps to form buffers. Complexity multiplicator is a combination complexity and unknown unknown. 3 ticket complexity levels:\n- easy \u0026lt;x1.2\u0026gt; - moderate \u0026lt;x1.5\u0026gt; - complex \u0026lt;x2\u0026gt; The common equation for one person will look like:\nSprint = SUM(User Story x Complexity Factor) + Time Buffer 5 days = SUM(User Story 1 x Complexity Factor; User Story 2 x Complexity Factor) + 1.5 Individual numbers differ among developers.\nAll in all, these are estimation basics. Questions asked will add up to this post. Meanwhile, some literature to read:\n- [https://programmers.stackexchange.com/questions/182057/why-do-we-use-story-points-instead-of-man-days-when-estimating-user-stories/182064#182064?newreg=ce5409f0211d491095fd1fcda482db36](https://programmers.stackexchange.com/questions/182057/why-do-we-use-story-points-instead-of-man-days-when-estimating-user-stories/182064#182064?newreg=ce5409f0211d491095fd1fcda482db36) - [https://answers.atlassian.com/questions/103623/how-to-use-estimations-of-subtasks-in-story-points-for-burndown-chart](https://answers.atlassian.com/questions/103623/how-to-use-estimations-of-subtasks-in-story-points-for-burndown-chart) - [https://www.mountaingoatsoftware.com/blog/story-points-are-still-about-effort](https://www.mountaingoatsoftware.com/blog/story-points-are-still-about-effort) - [https://www.mountaingoatsoftware.com/blog/dont-equate-story-points-to-hours](https://www.mountaingoatsoftware.com/blog/dont-equate-story-points-to-hours) - [https://docs.google.com/presentation/d/1BgLo-_g1rZvFrz1BaY7Q8uqt1VUTv8LfV8KlfIr73x4/pub?start=false\u0026amp;loop=false\u0026amp;delayms=3000\u0026amp;slide=id.g35f391192_00](https://docs.google.com/presentation/d/1BgLo-_g1rZvFrz1BaY7Q8uqt1VUTv8LfV8KlfIr73x4/pub?start=false\u0026amp;loop=false\u0026amp;delayms=3000\u0026amp;slide=id.g35f391192_00) - [http://www.codequest.com/blog/posts/playing-the-planning-poker-is-it-worth-it](http://www.codequest.com/blog/posts/playing-the-planning-poker-is-it-worth-it) - [http://www.agilelearninglabs.com/2012/05/how-to-play-the-team-estimation-game/](http://www.agilelearninglabs.com/2012/05/how-to-play-the-team-estimation-game/) I\u0026rsquo;m not telling pages behind those links are true / correct, but they are certainly allow to overview issues from different angles.\n","permalink":"https://maratkee.com/posts/2016-06-17-tuning-up-scrum-approach/","summary":"\u003cp\u003e\u003cimg loading=\"lazy\" src=\"/images/img_2016-06-17-132133.jpg\"\u003e\u003c/p\u003e\n\u003cp\u003eRecently my colleague, Tim, decided to try out Planning Poker, to have better estimations. Planning is essential, and scrum already offers a framework of how to deal with planning. But over the course of my work and experience with scrum techniques, team usually shapes\u003c/p\u003e\n\u003cp\u003ePrevious experience showed that daily scrum meetings are merely pointless. Direct communication / skype / IM is much more efficient. Especially in distributes teams.\u003c/p\u003e\n\u003cp\u003eAnd following each and every ritual from scrum routine is time and efficiency consuming during the first iterations, since agile methodologies need a good deal of instructions. Usually, after some time teams shape up scrum as they want, and it just works, so from my experience it\u0026rsquo;s not essential to follow scrum by the book (Agile Estimating and Planning book by Mike Cohn, written 10 years ago). Here are additional thoughts on why our transatlantic distributed team doesn\u0026rsquo;t fully fit into planning classic scrum and it\u0026rsquo;s rituals:\u003c/p\u003e","title":"Tuning up Scrum Approach"},{"content":"Last year guys from SkuVault offered me an amazing opportunity to help the company manage a growing development team, create organized schedule, establish workflow that reflects the company goals .\nFor those who don\u0026rsquo;t know - SkuVault is a Warehouse Management System (WMS). Like a swiss army knife, SkuVault manages and syncs your inventory across e-Commerce platforms, POS, Logistics and Warehouses, providing accurate quantities in order to prevent out of stocks. Headquartered in Louisville, KY - SkuVault helps to manage the inventory for hundreds of clients all across the globe.\nIt\u0026rsquo;s time to list some of the achievements we accomplished during this year.\nObservational Research and Optimization Scenarios For the first 2 weeks, I was examining the flow within the project, and getting to know the team. Each couple of days I published blog posts on my findings with ideas on how to improve and optimize the workflow. Some things in my new team were completely different from my previous experience:\n- No teamleads. That meant that developers split up into Code Review teams, and reviewed each other. - Technology stack (.NET at SkuVault vs Scala / Riak / react.js at Storia). With all the pros and cons, .NET development teams don't have that clear BE / FE differentiation: backend developers can work on frontend tasks via ASP.NET MVC, so our devs are more like (..universal soldiers). - No UX / UI design step in the workflow. This particular part makes every decision much faster. The product itself (SkuVault Warehouse Management App) uses Bootstrap, and is very utilitarian from design perspective. Key factor here is ease of use (as much as it can relate to industrial application). - Distributed team on both sides of the Atlantic, covering almost 24 hour period. - SkuVault is used by hundreds of customers around the world, bugfixing happens daily, and there are different bug priorities. This particular moment doesn't work well with typical “sprint-\u0026gt;release” cycles (because the priorities may change quite fast, or something needs to be urgently released). With all those differences in mind, I started to streamline the workflow in JIRA.\nStatuses, Transitions, Workflow I managed to decrease the number of statuses.\n- Used to be: 23 (with any transitions allowed between any statuses) - Became: 9 (with clear status sequence that reflects state of a bug / new feature). Most statuses were redundant, I’ve changed some of them with combination of “labels + status”, some were eliminated and substituted by generalized statuses (for example statuses “Design Holds”, “Client Clarification” changed to status: Hold + label “IncompleteDescription”).\nThe Workflow is constantly being refactored and improved per developers’ suggestions and whole team feedback. Last week I\u0026rsquo;ve released the 7th version of the workflow in a year.\nFlow in general, and for every team member (BA / PM / Dev / QA) is described in our wiki, as well as terminology, list of labels to apply (there is a special glossary for labels). I explain the workflow as a sequence of steps, so that there is an instruction in case of emergency, or a new person onboarding.\nOn Duty Teams During the first week we started to ask developers to fill a small questionnaire to find out how often they are distracted from new feature development by urgent client requests or bugfixes requiring immediate attention. It turned out that significant time (up to 80%) had been taken by Urgent Tasks, which distracted devs and made their work less efficient.\nSo the management team (well, actually it\u0026rsquo;s more like PMs, CEO, CTO and Support Lead) decided to establish teams of on call devs. These teams (2 devs: Frontend and Backend) would work only on urgent tickets, which allowed the rest of the team to work on regular tasks, ideally, without distraction.\nOn duty team concept has been rethought a couple of times, and currently we\u0026rsquo;re aiming at having 3 devs on call each shift, as client base grew significantly, and so have the requests, tasks and points of attention. Some of developers still get pulled to urgent tasks, because SkuVault heavily relies on integrations with other SaaS / eCommerce / Shipping systems, that change their APIs, improve their products, and may occasionally alter the way they interact with our system. And on duty devs may have questions for the developer who built the integration originally.\nHowever, the concept itself proved to be extremely helpful, and overall the issue is resolved.\nMentorship It\u0026rsquo;s a common thing to establish, when you have senior and junior devs :) In order to clarify overall system architecture questions, seniors mentor other developers and code review.\nTicket Description Standards Creating a clear guidance on filling out the fields and required info on a bug / new feature / or any other issue type is essential to streamline development.\nChanging Kanban approach to Hybrid Scrumban In a nutshell, a year ago development boards (one for planning, one for development) included lots of statuses, was extremely heavy (as you gotta display ~1k tickets), and hard to manage. Kudos to Tim Jannace and the team , who managed to bravely (and successfully) operate and maintain this board!\nHowever, an agile board should focus on one goal: to show a piece of flow relevant for particular scenario / area. So those two boards were split up, so that each board reflects a single scenario:\n- Development Board, where the tickets transition from ToDo to Ready to Release: Scrum Board; - Urgent Board, which is used by on duty teams, and includes only Critical and Blocker tickets: Kanban Board; - Quality Control Board, where developers and test managers can to see the scope of tickets they need to review: Kanban Board; - Release Board, for the release manager to overview and manage the tickets that should be merged to master: Kanban Board. There are boards for DevOps tasks, of course, as well as for other projects, but developers mostly have to check 2 boards maximum. And both of the boards are easy to use and lightweight.\nOn the other hand, pure sprint -\u0026gt; release cycles do not reflect how SkuVault operates, because of the Urgent bits that need to be released almost daily. So sprints are more like folders here, which allow us to forecast approximate or particular start / release dates for the tickets, and limit feature scope in a given time period. That\u0026rsquo;s why it\u0026rsquo;s called ScrumBan :)\nNotifications, Due Dates, etc I\u0026rsquo;ve also established automated email notifications on Pull Requests or Tasks are not Reviewed / Tested for more than 2 days.\nWe started to use labels trigger notifications for tickets that will soon miss due date, or for ones that shouldn\u0026rsquo;t be rescheduled.\nThere are a lot of other specifics, changes, undergoing improvements - over the year team grew significantly, as well as number of clients - and we adjust the company flows accordingly. Developers look motivated, and I couldn’t be happier to work in such an environment.\nKey findings this year: - Don't make a release the goal itself. Quality product is the goal. So you can skip a release or two, but deliver something good. Even if there are lots of clients,they would understand the importance of stability, not the feature they want firsthand; - Write up retrospectives on problematic moments, so that you solidify foundation of your experience for yourself and others. Try to gather additional data and opinions inside the team, in order to provide a broader angle to the problem; - Make everything possible to have a good human relationship with developers and other team members. You are colleagues, and a good person will always try to do her best, if she's motivated (see motivation reference article); - Horizontal hierarchy and a little bit of dev anarchy is always good. Every team member should have his voice at least heard; - Always update team feedback on how things are, this is essential to keep the flow up to date and address concerns that devs may have. Cause you know, in IT, team is what defines success, and good manager's work is to facilitate work and motivate the people; - Maintain comfortable release pace for the team and the clients; - Read professional literature, but don't forget to check how this works in reality :) - There is always room for optimization. You just don't have enough time! You can spend days micromanaging things, to extrapolate optimization on global flow later. Neverending exciting job. - Maintain work/ life balance. Don't let team overwork. Aside of your professionalism, key things to stay motivated are team spirit and ability to apply and improve your skills. For the past year we became mature, overcame challenges, and continue to create awesome WMS for our clients. Looking forward for the next adventurous year at SkuVault :)\nThanks to Ksenia, Slav and Kim for the review, and SkuVault team for the support.\n","permalink":"https://maratkee.com/posts/2016-06-17-year-retrospective-skuvault/","summary":"\u003cp\u003eLast year guys from SkuVault offered me an amazing opportunity to help the company manage a growing development team, create organized schedule, establish workflow that reflects the company goals .\u003c/p\u003e\n\u003cp\u003eFor those who don\u0026rsquo;t know - SkuVault is a Warehouse Management System (WMS). Like a swiss army knife, SkuVault manages and syncs your inventory across e-Commerce platforms, POS, Logistics and Warehouses, providing accurate quantities in order to prevent out of stocks. Headquartered in Louisville, KY - SkuVault helps to manage the inventory for hundreds of clients all across the globe.\u003c/p\u003e","title":"Year Retrospective @ SkuVault"},{"content":"I\u0026rsquo;ve recently been to Vienna, and visited local Austrian Startups Stammtisch. It went by the number #31, so quite a consistent event going on for more than a year now. The event took place in Sektor5 co-working space (which I have to recommend, because it\u0026rsquo;s a really cool place with only eur 18 per day! You can feel the international vibe and all that kinds of stuff).\nSektor 5 got a cool terrace :)\nSome of the stuff learned:\n- Bureacracy. In order to open a traditional gmbh company, you may need to be patient and get a lot of papers and formalities. It can take up to 120 days. - Government support. However, the good side, is that the process of bureacracy is not that painful, as the govt. is on your side and supports businesses will to change the country to innovation-driven economy. Grant system is strong here (http://www.austrianstartups.com/grants/) - Hard to notice, when you're from Russia, but Vienna is quite close to strongest european mainland startup hub: Berlin. An hour-flight only :) - English is embraced throughout the IT startups. So yaay!- Expats! However, you're more welcomed, if you speak deutsch. And because socialistic mindset, a good Austrian professional is mostly more preferable, than a great expat ;) And there are loads of cool pros in Austria. - Tons of sessions and meetups happen in Vienna, Salzburg and Graz. May keep you busy almost 100% of your time. There was a great atlassian event in Graz, that I wanted to attend, but didn't. Sad. - Great startup (and established IT companies) scene! Some of the big startups from Austria include: [Runtastic](http://runtastic.com) (surely you've heard about it), [bikemap](http://bikemap.net) (great stuff, more route-oriented than strava), [Shpock](http://shpock.com/int/) (my facebook is overloaded with it's ads now), [mySugr](http://mysugr.com) (basically an ecosystem of apps made for people with diabetes, by people with diabetes) and lots of others. - Vienna is extremely lovely! - Met great ppl from Austria, Ireland and Eastern Europe ;) Hey to Odessa guys, who created a venture find and were searching for partners (Crop Inc), - Good day to you, devs from Romania and Hungary, - Hi to Robert from heysharing.com. A lot of info, funds, grants, support and meetups can be found at [AustrianStartups.com](http://austrianstartups.com) Wish I had more time to dive into Austrian IT scene. This summer I\u0026rsquo;m visiting Berlin, and I\u0026rsquo;m sure I\u0026rsquo;ll be even more sad, cause I\u0026rsquo;ll have even less time than in Vienna.\nKeep up the good work, Austria! Your IT health status is great ;)\nCider is nice here too :)\n","permalink":"https://maratkee.com/posts/2016-05-05-notes-on-austrian-startup-scene/","summary":"\u003cp\u003eI\u0026rsquo;ve recently been to Vienna, and visited local Austrian Startups Stammtisch. It went by the number #31, so quite a consistent event going on for more than a year now. The event took place in Sektor5 co-working space (which I have to recommend, because it\u0026rsquo;s a really cool place with only eur 18 per day! You can feel the international vibe and all that kinds of stuff).\u003c/p\u003e\n\u003cp\u003e\u003cimg loading=\"lazy\" src=\"/images/img_20160419_195040.jpg\"\u003e \u003ca href=\"http://www.sektor5.at\"\u003eSektor 5\u003c/a\u003e got a cool terrace :)\u003c/p\u003e","title":"Notes on Austrian Startup Scene"},{"content":"It\u0026rsquo;s all about the process\nI might be a captain obvious here, but supporting a process for an analyst / pm is a more important, than micromanaging tasks amongst developer pool.\nWhen a new team member steps in, who\u0026rsquo;s responsibility is to manage development processes, she needs to find how to make business processes inside a company better.\nBusiness processes are evaluated from various points of view, but in a nutshell, aside from developer professionalism, she needs to make sure there\u0026rsquo;s no room for slowdowns and uncertanties when product passes different stages across different teams. Whether there are delays in communication, or delays of resources for the project, or sick-days, - there should be a correct process to tackle such cases, in order to minimize negative outcome.\nThere\u0026rsquo;s always a temptation to micromanage issues, no matter how big the project is and how little time you have. But project manager\u0026rsquo;s job is to create a process that allows to handle various situations. Once the process has been established - keep an eye on the workflow, so that it doesn\u0026rsquo;t jump over the fence of how the process should work.\nFencing is the key idea. Micromanagement is bad, if you don\u0026rsquo;t have a clear process: it\u0026rsquo;s time consuming, it\u0026rsquo;s inefficient on a project scale (of course there are exceptions), and most important - micromanagement doesn\u0026rsquo;t cope with scaling.\nSo the typical steps to establish a working mechanism is to:\n- Create the process - Adjust it to keep all needed operations inside that process fence - Make sure operations can connect to each other via unified inputs and outputs - Optimize the process to allow painless scaling - Do not pay too much attention to micromanagement :) ","permalink":"https://maratkee.com/posts/2016-04-12-manage-process-not-people/","summary":"\u003cp\u003eIt\u0026rsquo;s all about the process\u003c/p\u003e\n\u003cp\u003eI might be a captain obvious here, but supporting a process for an analyst / pm is a more important, than micromanaging tasks amongst developer pool.\u003c/p\u003e\n\u003cp\u003eWhen a new team member steps in, who\u0026rsquo;s responsibility is to manage development processes, she needs to find how to make business processes inside a company better.\u003c/p\u003e\n\u003cp\u003eBusiness processes are evaluated from various points of view, but in a nutshell, aside from developer professionalism, she needs to make sure there\u0026rsquo;s no room for slowdowns and uncertanties when product passes different stages across different teams. Whether there are delays in communication, or delays of resources for the project, or sick-days, - there should be a correct process to tackle such cases, in order to minimize negative outcome.\u003c/p\u003e","title":"Manage process, not people"},{"content":"While working on Storia.me iPhone app, we\u0026rsquo;ve eventually came up to the three-week sprints. Empirically, they proved themselves to make product high quality and provided time to get moderate functionality chunks done. Two notes here:\n- First of all - this is does not include time for appStore approval. That's additional week. So a release cycle is 1 month. - Second, we came to three-week sprints after we released MVP. Preparing the app for MVP was quite a kerfuffle, but we managed to finish needed bits in 2 months. Don't forget to have some rest and go for a holiday after that :) Time Distribution during 3 week sprint 2 weeks for development, 1 week for testing and fixing. Essential part of undistracted 2 weeks development, is to provide fully described User Stories with corner cases explained before the sprint. You also have to estimate all of the workload, and make sure it fits into the sprint. Leave tickets of a less priority on top of the backlog. Pay unprecedented attention to details, so that developer doesn\u0026rsquo;t need to waste time on communication and clarification (which always results in delays) how the described feature should work.\nThere are often times when stakeholders rush with some new request. For 80% of the time you\u0026rsquo;re (a good manager) able to protect developer and stories from scope creeps, but sometimes you are not able to do so. And here comes the last week of the sprint, that mostly handles such unfortunate situations.\nMake sure that AppStore materials are ready one week before app submission. Screenshots for all resolutions and languages, descriptions for different markets, no legacy and unsupported SDKs.\nKey point here is to make comfortable pace for the developer, so that as less things as possible distract him during the sprint. You know the rule: less distractions =\u0026gt; more productivity.\nAnd final achievement is predictable stable timely releases. These are something that are valued by stakeholders, investors, team and users.\n","permalink":"https://maratkee.com/posts/2015-11-12-three-week-sprints-for-ios-projects/","summary":"\u003cp\u003eWhile working on Storia.me iPhone app, we\u0026rsquo;ve eventually came up to the three-week sprints. Empirically, they proved themselves to make product high quality and provided time to get moderate functionality chunks done. Two notes here:\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e- First of all - this is does not include time for appStore approval. That's additional week. So a release cycle is 1 month.\n- Second, we came to three-week sprints after we released MVP.  Preparing the app for MVP was quite a kerfuffle, but we managed to finish needed bits in 2 months. Don't forget to have some rest and go for a holiday after that :)\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e\u003cimg loading=\"lazy\" src=\"/images/1117142_d0b4d0bed180d0bed0b3d0b8-d0b7d0bdd0b0d0ba-d0b7d0b5d0bbd0b5d0bdd18bd0b9-d188d0bed181d181d0b5-d0bed0b1d0bbd0b0d0bad0b5-d184d0bed0bd.jpg\"\u003e\u003c/p\u003e","title":"Three-week sprints for iOS projects"},{"content":"\nProduct is crafted by people. It is not a sum of collaborative work. It\u0026rsquo;s usually a combination of work, excitement, collaborative ideas, feedback loop inside the team throughout the whole project lifecycle.\nPassion is right at the heart of every person, and if environment tends to motivate - a person will work hard to achieve a good result (appreciated by the team and himself). Moreover, working with passionate team amplifies the overall product, makes it bigger than sum of efforts.\nI approach to motivation as to a three-factor equation.\n- Excitement about the project (and willingness to work on it) - Ability to apply your skills (and improve them) - Compensational part Let\u0026rsquo;s leave out compensational part. Let\u0026rsquo;s also make a note, that such approach doesn\u0026rsquo;t work on lousy boring projects.\nThe rest two points are extremely transparent, if you work in a smaller companies with more or less \u0026lsquo;flat\u0026rsquo; hierarchy and informal communication.\nExcitement about the project comes from inspiration. It could be something cool, that brings value to the market. Aspirational team, that challenges you, while you challenge them. This makes it extremely easy to go \u0026amp; do your job day by day. Such teams later stick together, even working on different products, to exchange ideas and share experience (as we did with Ufa42 Conference).\nOnce the project is exciting, challenging - person starts to work hard in order to bring his valuable contribution. Developer, manager, designer, analyst - everyone is involved into general decisions, everyone is able to improve the product from the inside. Which means he can apply his skills in a good way, practice fresh approaches and technics, learn on mistakes, tune the workflow.\nHowever, lack of involvement in product creation (aside from simply doing your job), vertical hierarchy and formal chain of command - it all kills the motivation. This brings us back to our equation: team is unhappy, not motivated = product not exciting. World doesn\u0026rsquo;t need boring products. Don\u0026rsquo;t forget: awesome pros won\u0026rsquo;t stick with something dull for a long time, they will leave as soon as they can. And we all know, that finding great teams is something almost impossible :)\n","permalink":"https://maratkee.com/posts/2015-06-16-team-spirit-exciting-project-good-product-and-vice-versa/","summary":"\u003cp\u003e\u003cimg loading=\"lazy\" src=\"/images/lego-teamwork.jpg\"\u003e\u003c/p\u003e\n\u003cp\u003eProduct is crafted by people. It is not a sum of collaborative work. It\u0026rsquo;s usually a combination of work, excitement, collaborative ideas, feedback loop inside the team throughout the whole project lifecycle.\u003c/p\u003e\n\u003cp\u003ePassion is right at the heart of every person, and if environment tends to motivate - a person will work hard to achieve a good result (appreciated by the team and himself). Moreover, working with passionate team amplifies the overall product, makes it bigger than sum of efforts.\u003c/p\u003e","title":"Team Spirit + Exciting Project = Good Product (and vice versa)"},{"content":"When developing Storia.me iPhone app, we had the following circles to deliver to:\n- Developers - QA - Early adopters - General Audience (AppStore) And the following problems to solve:\n- Provide Beta access with faster update pace and immediate critical bug fixing for early adopters (as in microsoft’s inner circle); - Make AppStore version as stable as possible; - Receive feedback on earlier stages, experiment with a limited set of users and influencers. A scheme we came up with eventually, has three (four in special cases) versions before the final AppStore release. Each version is rolled out out for certain circle, with different readiness level. Storia Alpha Internal build for developers. After code is frozen, feature-complete version is sent to Preprod. Alpha version may be used as a proof-of-concept prototype, since it usually doesn’t require QA stage. Distributed via hockeyapp. Connected to dev server.\nStoria Preprod Internal build for QA team, before we release stable version. After critical and major bugs fixed, Preprod becomes a Beta. Distributed via hockeyapp. Connected to preproduction server.\nQuite often preprod version is tested together with design team, in order to see how well the mockup works in extreme cases.\nStoria Beta Stable version for early adopters. Helps in revealing bugs, inconsistencies and everything else that fell out of scope during previous stages, shows overall initial reception. Has a 1-week period for testing, before AppStore submission.\nVersion that is used by stakeholders, everyone in the company and users from countries, where Storia is not released yet. Distributed via hockeyapp. Connected to production server.\nWhy hockeyapp?\n- It is cross-platform, meaning that we can extrapolate iOS scheme to Android. - It shows new updates instantly, meaning we can be sure that most Beta users are using the latest version. Bug fixing and merging\nFixes are merged into current version branch. If QA team finds a bug in Beta version - fixed are merged in Beta.\nIt is obvious, that we cannot hotfix an AppStore version =) Critical fixes are tested in Beta and issued as an AppStore update (depending on severity). Minor fixes are added to the next planned version.\nSpecial cases, Storia Testflight Testflight version is identical to Beta and the one submitted to AppStore. Connected to production server. We use it when we need to test a certain feature on production server privately. We needed to test video recording \u0026amp; processing on backend, but couldn\u0026rsquo;t rollout this features to Beta access (they could have produced a lot of broken content). Testflight Version was internally tested on production server by dev and QA teams, and proceeded to App Store once all obstacles were moved out of the way.\n- Q: Why to AppStore, and not to beta? - A: We rolled out video recording and playback features simultaneously for general public and Beta access). Bug fixing for Testflight version sometimes involved rolling out the fix in Beta, since hockeyapp update takes a bit less time to process.\nFor the past 9 months, come hell or high water, this flow proved itself to be efficient and transparent. It took two sprints initially to get used to the scheme and tune it a bit. Release cycle is stable, updates work well, adopters get new features faster, team receives feedback earlier.\nI would love to hear criticism, or get a fresh look at similar distribution process in your teams =)\nMany thanks to Rishat, Ksenia for edits.\n","permalink":"https://maratkee.com/posts/2015-05-29-storia-me-app-rollout-better-feedback-loop-faster-iterations/","summary":"\u003cp\u003eWhen developing Storia.me iPhone app, we had the following circles to deliver to:\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e- Developers\n- QA\n- Early adopters\n- General Audience (AppStore)\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eAnd the following problems to solve:\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e- Provide Beta access with faster update pace and immediate critical bug fixing for early adopters (as in microsoft’s inner circle);\n- Make AppStore version as stable as possible;\n- Receive feedback on earlier stages, experiment with a limited set of users and influencers.\n\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eA scheme we came up with eventually, has three (four in special cases) versions before the final AppStore release. Each version is rolled out out for certain circle, with different readiness level. \u003ca href=\"/images/scheme.png\"\u003e\n\u003c/a\u003e \u003cimg loading=\"lazy\" src=\"/images/scheme.png\"\u003e\u003c/p\u003e","title":"Storia.me App Rollout: Better Feedback Loop, Faster Iterations"},{"content":"\nWell-coordinated work across teams - let\u0026rsquo;s say design and development - is a huge deal when it comes to delivering a good product on time! So, part of my job as a project manager is making sure that the assets passed from design into development are ready for implementation.\nAt the very heart of the process, design review is nothing complex. You should know human interface guidelines, platform restrictions, requirements and a little bit of common sense =)\nHere are the common issues I often face, when reviewing design:\n- Design does not incorporate all the details on features planned; - Navigation controls are used inappropriately from the native experience point of view; or simply not intuitive; - Assets are missing during delivery phase; - Mockup does not look good, when populated with real user data; mockup has not been stress-tested on extreme cases. As our teams worked together, we optimized our process to minimize adverse effects on the points above.\n1. Kick-off with an interview. When the team is excited - it shines in willingness to collaborate on building a valuable product. Once an applicant to a designer position is excited - she starts to ask questions and share her ideas. I try to understand what the candidate thinks about the project, her motivation, her past projects experience: was there an established flow when this designer had been working on a product, how did the teams collaborate.\nUsually, our projects involve UX and UI designer. An iPhone UX expert knows navigation controls, their proper use, typical user flows, analytics and split testing, how to structure information elegantly and effectively. She creates prototypes and mockups for the upcoming app. UI designer provides GUI for a mock up (colors, iconsets, sizes for different resolutions).\n2. Help designer to understand the product, build solid requirements There is a timeframe for a designer to get to know the product. Have materials prepared, older designs structured (for the retrospective view), corner cases described.\nThe whole team was pleasantly surprised when our new UX designer asked for requirements documents and stayed knee-deep in them for a couple of days. He came up with rational and neat optimization.\nWe describe global functional requirements in Confluence, with obstacles, corner cases and retrospectives added to the main article. This gives a designer (and practically any new person in the team) the understanding which issues and mistakes we faced, what are the bottlenecks of particular solutions, and why we currently have an effective solution if we already do.\nWe describe platform-specific flows and requirements in User Stories, which also work as checklists for designers.\nThe one thing I want to point at again, are the corner cases. They usually fall out of scope and do not apply to typical user behavior, but may result in unpleasant experience. We brief a designer on corner cases before he starts prototyping.\n3. Create checklists for mockups There is a quite popular problem companies face: real user data doesn’t play nicely with the mockup. The design may look gorgeous and trendy and flat, but once you start populating it with longer names, venues, low quality photos, vivid photos that make overlayed text unreadable - the whole greatness falls apart. What to do here?\n- Reflect min and max length for the fields in the requirements. This way designer knows what to expect from the real data. - Prepare corner case text examples, to check how well the mockup stands against them. For example, use location named ‘Venkata Narasimha Raju vari Bahadur’ instead of ‘Union Station’. Show how long text should be cut, if needed. - Keep in mind that if you support multiple languages, some buttons may require more space for a label to fit. - Check for active / inactive states for buttons, segments, toolbars. - Alerts and message boxes for whatever reason can be (connection loss, lack of space, unsaved data, ...) - Text overlays. If text overlays a picture, be sure that text is still readable even on a bright vivid photograph. 4. Wording for mockups Wording mistakes happen quite often. You may have ‘Done’ button in current application, and ‘Save’ in an updated mockup, or even different labels for the same action in different sections. I make sure wording is correct and synced across designs, before dev team starts implementing it. Easiest path is to have all metaphors documented inside a task-tracking or wiki-system, so that designer knows how to name each element properly. This saves a lot of time and nerve for everyone involved.\n5. Standardize assets delivery In order to be sure we got all the assets we need we created a small guide on design delivery in a form of simple folder structure. #project_folder - #project_iOS - #comments_screen - comments.psd - #_icons - icon.png (for 1x) - icon_@2x.png (for retina) - icon_@3x.png (for retina HD) - This hierarchy serves to ensure we have needed states and sizes for icons, and a structure that will confuse noone.\nOverall, I hope that this brief article helps you optimise your process and get design delivered faster =)\nSpecial thanks to Ksenia, Rishat, Igor for reviews =)","permalink":"https://maratkee.com/posts/2015-05-27-making-app-design-review-better/","summary":"\u003cp\u003e\u003ca href=\"/images/iphone-6-psds.jpg\"\u003e\u003cimg loading=\"lazy\" src=\"/images/iphone-6-psds.jpg\"\u003e\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eWell-coordinated work across teams - let\u0026rsquo;s say design and development - is a huge deal when it comes to delivering a good product on time! So, part of my job as a project manager is making sure that the assets passed from design into development are ready for implementation.\u003c/p\u003e\n\u003cp\u003eAt the very heart of the process, design review is nothing complex. You should know human interface guidelines, platform restrictions, requirements and a little bit of common sense =)\u003c/p\u003e","title":"Improving App Design Review, Ensuring Design is Ready for Development"},{"content":"Werner Vogels, the amazon CTO, in a very informal way talked with Conten.ly, Distill Networks, and some other CEO/CFO/CCO\u0026rsquo;s on how the start-ups were scaling.\nWerner still claims that Amazon is a startup. Yeah, just with billion valuation and an IPO. How cute, noted Shane of Contently. (UPD: this was shared lightning fast all over the media, see the full transcript)\n====\n“How much time do you spent time on hiring?” Vogels asked. “At Amazon, of course, we’re a 20 year-old startup by now —”\n“Uh… startup?” Kretchmer interrupted.\nThe crowd burst into laughter. Vogels stuck with his description:\n“Ehh, startup,” he said over the crowd, “We’re still a startup!\n“Awww, that’s really cute,” Kretchmer fired back in a faux-sweet voice.\nVogels paused as the crowd and the panel participants continued to giggle.\n“Mmmhh, that threw me off guard a bit,” he said finally, shaking his head.\nKretchmer wasn’t done:\n“Yeah,” he said with a laugh, “There’s a new class of startup called ‘IPO’d and Worth Billions.\u0026rsquo;”\n“It’s not just about the size!” Vogel’s protested. “It’s.. whatever. Moving on.”\n=====\n** So, basic idea was that when there are 15-20 people, a general manager / product / ceo / founder can handle all of the connections, but the more people are scaled up, the harder it gets. So the discussion was on the sizes and scaling the management team for that, and how often should it report the feedback. \u0026lsquo;The one funny thing about the managers is that they are vital\u0026rsquo; - says Werner. \u0026lsquo;You think that he does nothing except managing the people, but he accumulates the feedback and knows what\u0026rsquo;s happening around\u0026rsquo;. The guys also talked about money, and how inefficiently they were spending them when they were founded and needed to fastly scale up the team. The funny thing was that their main investor and sponsor was there =) So they laughed all together.\n","permalink":"https://maratkee.com/posts/2015-03-16-scaling-a-startup-session-sxsw-with-werner-vogels/","summary":"\u003cp\u003eWerner Vogels, the amazon CTO, in a very informal way talked with Conten.ly, Distill Networks, and some other CEO/CFO/CCO\u0026rsquo;s on how the start-ups were scaling.\u003c/p\u003e\n\u003cp\u003eWerner still claims that Amazon is a startup. Yeah, just with billion valuation and an IPO. How cute, noted Shane of Contently. (UPD: this was shared lightning fast all over the media, see the full transcript)\u003c/p\u003e\n\u003cp\u003e====\u003c/p\u003e\n\u003cp\u003e“How much time do you spent time on hiring?” Vogels asked. “At Amazon, of course, we’re a 20 year-old startup by now —”\u003c/p\u003e","title":"Scaling a startup session @ SxSW with Werner Vogels"},{"content":" German writer and theologian Dietrich Bonhoeffer once famously said, \u0026ldquo;silence in the face of evil is evil itself.\u0026rdquo; When there is potential for storytelling or reporting to create a tangible impact, is there an obligation for the journalist or greater media ecosystem relay a call to action to the reader? What is the role of the journalist in getting the audience to emotionally connect to what they are reading, potentially at the expense of objectivity? Presented by The Knight Foundation\u0026quot;.\nhttp://schedule.sxsw.com/2015/events/event_IAP41786 What metrics does the journalism should use for measuring advocacy? The votes, some events maybe. The question is very broad here.\nHow does the storytelling affect propaganda, as well as fear in people\u0026rsquo;s heads? The storytelling can become even the business model.\n** There are different opinions on how to make people act after reading a story. It may work and may not, for example the african genocide and the child labor in asia can definitely strike lot of people\u0026rsquo;s hearts, however the basic things as citizen behaviour and improving school programmes does not provide such resonance since the people themselves are participating in that.\n","permalink":"https://maratkee.com/posts/2015-03-15-a-fine-line-journalism-storytelling-and-advocacy/","summary":"\u003cblockquote\u003e\n\u003cblockquote\u003e\n\u003cp\u003eGerman writer and theologian Dietrich Bonhoeffer once famously said, \u0026ldquo;silence in the face of evil is evil itself.\u0026rdquo; When there is potential for storytelling or reporting to create a tangible impact, is there an obligation for the journalist or greater media ecosystem relay a call to action to the reader? What is the role of the journalist in getting the audience to emotionally connect to what they are reading, potentially at the expense of objectivity? Presented by The Knight Foundation\u0026quot;.\u003c/p\u003e","title":"A fine line: Journalism, Storytelling and Advocacy"},{"content":" How to accurately estimate external projects\nThis is a first article from “How to accurately estimate incoming projects” series, aimed to help you see the possible future pitfalls. This includes both outsourcing projects and the ones where different teams around the world are involved.IT industry is dynamic. Companies change APIs, IDEs, upgrade hosting servers software, raise new compatibility issues. Of course improvements are welcome, but there is no way you will have a perfect product once and forever – it needs to be re-iterated. Don’t forget about hundreds of different environments that the system should work on. And people.\n1. Client Interaction Time It’s not a big deal when we are talking about local business (and even in such close distance email response delay time could be significant and expensive), but when you’re dealing with international clients and partners, this becomes a more significant issue.\nThere are several simple rules that are wise to follow in order to keep up with the deadlines:\n- Don’t underestimate time needed for interaction; - Client won’t run and read your email instantly, he has work to do; - Response time could vary, but prepare for the worst. Let’s look at an example: you are building an ecommerce website. The catalogues structure is a bit tricky so you need to clarify where a product recommendation slider leads.\n- You send the request; - Client reads it in 2 hours; - Gets back to you with some questions in order provide proper answer; - When you answer him – you are already off from work; - You read the final response the next day only. Of course it’s not what may happen every time, but you need to take such issues into account before they happen. Here is what could cause “lags” on the client side as well:\n- Clarification from a third party (could be a hosting provider, lawyers, content providers, etc); - Interaction between departments; - Approval of department manager and other bureaucratic procedures. In addition to that, there’s been quite a few times, when our clients from other countries needed to clarify detailed info with a a third-party with no people on that side speaking English at all. The main point of this section is to make you understand how heavily client interaction lag can affect the entire project. It’s worth mentioning because these things rather frequently fall out of scope of attention.\nHow to avoid possible adverse effects? A checklist or a roadmap will be helpful to manage handling tasks in advance. In Codebranch, we prepare a project roadmap with Freeze dates, which are the last dates that a certain part of team-client interaction is due. For instance, there are:\n- Design Freeze Date – this is when the client takes a final approval and signoff to the proposed design, all the amendments and improvements to the design have to go before that date. - Functionality Freeze Date – the milestone by which the final application functionality should be agreed upon. - Content Delivery Date – this is when the content provided by client is due, so the client would know the timing in advance and have enough time to gather the content. - Hosting or CDN accounts purchase dates, domain name registration deadline – when, and no later, the accounts need to be available to the development team in order to set the environment up and deploy on time. These dates are elaborated together with the client, basing on the delivery timelines that the client suggests, and adjusted accoring to the internal development milestones. This approach helps both the team and the client meet the responsibilities in working on a web project, and contributes into building a good working relationship.\n","permalink":"https://maratkee.com/posts/2013-09-01-how-to-accurately-estimate-projects-for-outsourcing-part-i-delays-caused-by-communication/","summary":"\u003cp\u003e\u003cimg loading=\"lazy\" src=\"/images/accurate_1.png\"\u003e\n\u003cem\u003eHow to accurately estimate external projects\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eThis is a first article from “How to accurately estimate incoming projects” series, aimed to help you see the possible future pitfalls. This includes both outsourcing projects and the ones where different teams around the world are involved.IT industry is dynamic. Companies change APIs, IDEs, upgrade hosting servers software, raise new compatibility issues. Of course improvements are welcome, but there is no way you will have a perfect product once and forever – it needs to be re-iterated. Don’t forget about hundreds of different environments that the system should work on. And people.\u003c/p\u003e","title":"How to accurately estimate external projects. Part 1 - Delays caused by communication"},{"content":"Nothing new this 2 weeks. Well, in fact tons of new stuff this 2 weeks, but no time to blog at all. We are experiencing extreme-2-week-game-development and are almost ready to release \u0026ldquo;how not to screw up big projects\u0026rdquo; book (this is a joke, everything\u0026rsquo;s under control).\nMeanwhile, we posted some stuff at codebranch blog, and want to say \u0026ldquo;HI\u0026rdquo; to our folks at LeWeb in Paris this week ;)\nHere are the previews for two next posts:\nHow to Accurately Estimate Projects for Outsourcing? Part I – Delays Caused by Communication In addition to that, there’s been quite a few times, when our clients from other countries needed to clarify detailed info with a a third-party with no people on that side speaking English at all. The main point of this section is to make you understand how heavily client interaction lag can affect the entire project. It’s worth mentioning because these things rather frequently fall out of scope of attention.\nHow to avoid possible adverse effects? A checklist or a roadmap will be helpful to manage handling tasks in advance. In Codebranch, we prepare a project roadmap with Freeze dates, which are the last dates that a certain part of team-client interaction is due\nHow to accurately estimate outsourcing projects. Part II: Accessing Web Services Compatibility and environment issues. The most common problem though is the environment. Whether it’s an API, a plugin to work with it, it may require additional adjustments to your server. Documentation should be carefully revised so that there are no flops when integrating the solution into your own website or service.\n2. Sometimes a client wants solution for a service, that has no public API. i.e. Pinterest has no public API and provides a gateway just for iOS.\nDevelopers start to use workarounds, gather together to find solutions. And so – 3rd party APIs are born. Returning to Pinterest, as a great example, apps that use 3rd party API access Pinterest via iOS gateway, identifying themselves as iPhone. Of course, that won’t always work as expected, even minor changes in Pinterest API now breaks almost every single app that uses 3rd party API.\n","permalink":"https://maratkee.com/posts/2012-12-05-no-title/","summary":"\u003cp\u003eNothing new this 2 weeks. Well, in fact tons of new stuff this 2 weeks, but no time to blog at all. We are experiencing extreme-2-week-game-development and are almost ready to release \u0026ldquo;how not to screw up big projects\u0026rdquo; book (this is a joke, everything\u0026rsquo;s under control).\u003c/p\u003e\n\u003cp\u003eMeanwhile, we posted some stuff at codebranch blog, and want to say \u0026ldquo;HI\u0026rdquo; to \u003ca href=\"http://frumatic.com/blog\"\u003eour folks\u003c/a\u003e at \u003ca href=\"http://leweb.co\"\u003eLeWeb\u003c/a\u003e in Paris this week ;)\u003c/p\u003e\n\u003cp\u003eHere are the previews for two next posts:\u003c/p\u003e","title":"no title"},{"content":"\nLatest post by LongZheng reveals MS Research’s plans to ship JS library for kinect-enabled website. We already mentioned this in our twitter, but today’s little article will take a look at opportunities that this fact brings to the market.\nKinect has been a revolutionary addition for XBOX and sold millions of copies first year, becoming the fastest selling product in Microsoft’s history. Although, I didn’t like the release name (codename: “Project Natal” was much smoother to our ears), we all now take it for granted. There are still no hardcore games for Kinect, titles like Sesame street (a must-notice title for parents out there) and Kinect adventures are great for kids so they sell well, while Dance Central series popularize this device as an entertainment.\nIt is said, that Microsoft gets in a right vibe on the third time. Kinect sold more than 18 million devices in 1.5 years, but the development for 3rd parties has been limited due to lack of experience. However, consumers love and use Kinect voice more than Kinect-gestured controls, simply because of the accuracy and easiness. “XBOX Pause/Play/Search” words are much more comfortable, than trying to swipe left and right with your hands in attempt to make a menu scroll.\nKinect for Windows Release and the Beginning of Kinect Hacks In February 2012, Microsoft released Kinect for Windows, with improved sensors and SDK. And while many people were skeptic about the reception, partially because of the higher price, researchers and developers loved that they wouldn’t need xbox to play around with Kinect anymore. Thus, PC/MAC-based experiments started to crowd coding4fun section at channel9.\nWe remember first example Kinect-enabled virtual fitting room in Topshop, Moscow. That was really cool. Accuracy was average, but the customers loved to see if the dress fits their style without trying it on. And of course – social network sharing.\nFakeCake Dressing Room\nKinect SDK made it pretty easy to track body parts moving.\nThere are 20 parts that kinect can track:\n- left foot, right foot - left ankle. right ankle - left knee, right knee - left hip, right hip - hip center - spine - shoulder center - left shoulder, right shoulder - left elbow, right elbow - left wrist, right wrist - left hand, right hand - head It’s an initiative of MS Research, to ship the library. No further details revealed, since it’s only a peek.\nSince its first appearance as a companion for Augmented Reality (AR), Kinect is quickly growing as a must for various digital media events. Mostly these are digital kiosks for interactive advertising. There are tons of articles and case studies written about how Kinect is used in advertising, but the post mentioned above expands the development part, merging kinect-enabled web and application development together.\nKinected Browser Architecture\nOpportunity to Jump In for Web Developers Today’s approach for developing Kinect applications is the same as any other involving sensors: you take the SDK, create an app, connect the device and test it, get the data you need. JavaScript library for Kinect-enabled websites could help merging the application development, limiting the functionality but making the solution more universal. Just imagine: you create a website with an interactive kinect-enabled module. Of course, talking about Microsoft’s piece of technology, we get a platform limitation: feature is IE only. Features are delivered via ActiveX, and that means no support for other browsers. Good news: IE9 and 10 are much better than the older versions and are capable of rendering great websites (almost) correctly.\nThis website would provide the same content both for common users, as well as for the interactive user group. No need to develop a special app, just integrate your module into the website and place a giant display onto the windows: engage your users via interaction and create unified experience both on interactive and common web browsing sides.\nThis in fact could engage many web developers to experiment with the controller and to position the Web as a great place for Kinect Hacks and Tricks. We will definitely follow the story.\nRead this:\n[Microsoft Research to ship Kinected Browser JavaScript library for Kinect-enabled websites](http://web.archive.org/web/20121204200722/http://www.istartedsomething.com/20121113/microsoft-research-to-ship-kinected-browser-javascript-library-for-kinect-enabled-websites/)[Interactive Tabletops and Surfaces Conference](http://web.archive.org/web/20121204200722/http://its2012conf.org/)[Kinect Controlled SwimBrowser](http://web.archive.org/web/20121204200722/http://swimbrowser.tumblr.com/)[Microsoft Research, Kinected Browser](http://web.archive.org/web/20121204200722/http://research.microsoft.com/en-us/projects/kinectedbrowser/)[Kinected Browser: Depth Camera Interaction for the Web ](http://web.archive.org/web/20121204200722/http://research.microsoft.com/pubs/172689/kinectedbrowser_cameraready_v1A.pdf)","permalink":"https://maratkee.com/posts/2012-11-18-159/","summary":"\u003cp\u003e\u003cimg loading=\"lazy\" src=\"/images/kinectedbrowser.jpg\"\u003e\u003c/p\u003e\n\u003cp\u003eLatest post by \u003ca href=\"http://web.archive.org/web/20121204200722/http://www.istartedsomething.com/20121113/microsoft-research-to-ship-kinected-browser-javascript-library-for-kinect-enabled-websites/\"\u003eLongZheng\u003c/a\u003e reveals MS Research’s plans to ship JS library for kinect-enabled website. We already mentioned this in \u003ca href=\"http://web.archive.org/web/20121204200722/https://twitter.com/code_branch\"\u003eour twitter\u003c/a\u003e, but today’s little article will take a look at opportunities that this fact brings to the market.\u003c/p\u003e\n\u003cp\u003eKinect has been a revolutionary addition for XBOX and sold millions of copies first year, becoming the fastest selling product in Microsoft’s history. Although, I didn’t like the release name (codename: “Project Natal” was much smoother to our ears), we all now take it for granted. There are still no hardcore games for Kinect, titles like Sesame street (a must-notice title for parents out there) and Kinect adventures are great for kids so they sell well, while Dance Central series popularize this device as an entertainment.\u003c/p\u003e","title":"MS to challenge interactive web with kinect controlling JS library"},{"content":"This is really interesting to watch! One of the best argued and balanced critical statements come from MS\u0026rsquo; former employees, that\u0026rsquo;s why I follow for example Scott Barnes (@MossyBlog). Check this out ;)\n[vimeo http://vimeo.com/53237950]\n","permalink":"https://maratkee.com/posts/2012-11-12-scott-barnes-on-reading-ms-roadmap/","summary":"\u003cp\u003eThis is really interesting to watch! One of the best argued and balanced critical statements come from MS\u0026rsquo; former employees, that\u0026rsquo;s why I follow for example Scott Barnes (@MossyBlog). Check this out ;)\u003c/p\u003e\n\u003cp\u003e[vimeo http://vimeo.com/53237950]\u003c/p\u003e","title":"Scott Barnes on reading MS' Roadmap"},{"content":"Having worked in the sound recognition field in mobile space (bird sounds) I know about this hard process a bit. Mostly I was using predefined algorithms and just implemented them in c#, but my poor knowledge and puny brain would never do such amazing stuff!\n[youtube=http://youtu.be/Nu-nlQqFCKg]\nNatural UI comes to life! You can always see that some awesome MS Research powered speech recognition displayed on MS keynotes almost in real-time, but yesterday\u0026rsquo;s article on The Next Web highlighted the new addition to that wonderful feature: same voice tone speech translation in Mandarin! Check this out!\nSource: Microsoft Demos Amazing English to Mandarin Translation, Allowing for Real-Time Audible Translations\n","permalink":"https://maratkee.com/posts/2012-11-10-awesome-microsofts-speech-recognition-and-instant-same-tonal-voice-translation/","summary":"\u003cp\u003eHaving worked in the sound recognition field in mobile space (bird sounds) I know about this hard process a bit. Mostly I was using predefined algorithms and just implemented them in c#, but my poor knowledge and puny brain would never do such amazing stuff!\u003c/p\u003e\n\u003cp\u003e[youtube=http://youtu.be/Nu-nlQqFCKg]\u003c/p\u003e\n\u003cp\u003eNatural UI comes to life! You can always see that some awesome MS Research powered speech recognition displayed on MS keynotes almost in real-time, but yesterday\u0026rsquo;s article on The Next Web highlighted the new addition to that wonderful feature: same voice tone speech translation in Mandarin! Check this out!\u003c/p\u003e","title":"AWESOME! Microsoft's Speech Recognition and Instant Same Tonal Voice Translation"},{"content":"7 years ago Apple announced that they would be moving from PowerPCs to Intel\u0026rsquo;s x86 CPUs in two years because they had been producing less heat and running much faster (PowerPCs were built by IBM. The 8-core version of this chip also powers PlayStation 3 ). This was a very dangerous step, which definitely brought massive boost in performance for Apple products, but caused additional emulation layer to run the legacy applications.\nApple previously made a transition from Motorola\u0026rsquo;s 68K to PowerPC architecture, and included Motorola 68K emulator to run legacy apps. The same happened when Apple started using Intel chips, instead of IBMs in 2005 - the additional layer to run the older code was called Rosetta. Will it really be that painful, if Apple would change the architecture one more time?\nThis week brought us not only MS Office for Android and iOS confirmation, but also an article by Bloomberg, whose informer claims that Apple is thinking about moving from Intel chips to ARM ones, particulartly A6X to their Mac product line. Why is this really important?\nThis could be the biggest shift in Mac history. Literally. The Macs now are the second biggest ecosystem and Intel chips helped Apple with the desktop expansion. Apple\u0026rsquo;s marketshare in PC reached 7.59%, and more than 12 million Macs were sold in 2011. That is a huge number for a single OEM with vertical infrastructure (it\u0026rsquo;s when a company maintains full-cycle production for its products: both develops software and designs, as well as produces the hardware). iOS domination in mobile space significantly helped in gaining worldwide market share. Apple took a clever way of delivering incremental updates to simplify and improve the OS. Even more: the design unification across all Apple\u0026rsquo;s devices made it very compelling to start using a Mac, if you already had an iPhone or iPad.\nOperating System Market Share, 2008-2012\nBackwards compatibility (running current OS X apps) and mobile development Some might say that Apple is not a freshman in architecture shifts, but moving from x86 can result in a big performance drop.\n- ARM processors are not as advanced as x86 (Intel core architecture) - ARM only plans to start 64 bit versions chips production [in 2014 with AMD](http://web.archive.org/web/20121204233353/http://www.amd.com/us/aboutamd/newsroom/Pages/presspage2012Oct29.aspx) (64 bit version will deliver huge boost in performance for the same power consumption) - Good news: ARM already supports out-of-order execution, unlike Intel's Atom processors (Next Gen atoms confirmed to support this feature) There is a good chance, that Apple is already testing some prototypes deep inside its labs, but it\u0026rsquo;s a huge work on optimization to be performed, and the OS could become fragmented. As it is with Windows 8 on x86 and limited Windows RT on ARM.\nARM-supported version of OS X should include an emulator-cushion, same as Rosetta, Apple provided for PowerPC =\u0026gt; x86 transition. AllthingsDigital states that there is an example: Russian Company successfully runs x86 software on ARM.\nSuch scenarios could happen: development-wise it\u0026rsquo;s Cocoa for the UI. And the app that calls windows will still do that on ARM version. Apple has developed an awesome IDE that simplifies the process of development between OS X and iOS. But running x86 code on ARM with the emulator could help if we\u0026rsquo;re talking about the simple applications that call the standard UI libraries and common stuff like that.\nHigh-performance applications But let\u0026rsquo;s turn to the elefant in the room: what will happen with the low-level applications? You can\u0026rsquo;t run Photoshop in emulator. Neither 3d Max, Office and many more. Meanwhile, these apps are crucial when it comes to the professionals working on Macs (mainly Macbook Pro / iMac). That\u0026rsquo;s why we are not that clear about porting a full-featured OS X to ARM. These apps will be needed to be fully re-written for the new OS. OS X Architecture Layers\nOne might argue that developers and customers still would buy new Macs so that they would create a market. And if a developer wouldn\u0026rsquo;t want to re-write an app, then money-hungry competitors would occupy the sunny spot and get all the money. The obvious issue is whether you could per se run a full 3D rendering suite on ARM. Right now there\u0026rsquo;s no way you could do that. We\u0026rsquo;re talking about something like 3DMax, Photoshop in particular.\nWe\u0026rsquo;d also like to point out high-performance games. We\u0026rsquo;re not talking about the hits like Shadowgun and Infinity Blade. Even if Infinity Blade is built on Unreal Engine, that doesn\u0026rsquo;t mean that it uses the fully featured one like on PC / XBOX. It\u0026rsquo;s a special ARM version, because ARM architecture is not capable of rendering complex shadows / advanced lightening / fully featured particles.\nMacs just started to gain some traction in gaming space, you can see huge titles across Mac App Store, but ARM move will kill the gaming culture in Mac space. Same applies to Steam.\nAnd one last thing: no Parallels for ARM.\nSome more quick points IDE \u0026amp; development ecosystem unification: - iOS developers gallore. We can bet - a lot of developers will emerge from iOS and help OS X in gaining apps - Desktop developers will get even easier porting. iOS userbase is much better than OS X's. This could trigger even more great apps of iOS and further iOS growth (possible solution to compete with Android in the future) iMac / MacBook for Work and Macbook Air differentiation - Macbook Air is the best selling Apple PC. Most people use it as a device to access the web, mail, office. Good candidate to include an ARM chip. As a result: much lighter and thinner gorgeous looking laptop, with no vents at all - MacBook Pro and iMac could be left for professional use (music / video editing / rendering / photos) with x86 chips - Possible creation of a whole new line of Macbooks for content consumption and text editing as an alternative to the MacBook Air ARM is dominating in mobile world with almost no room left for the competitors. The latest collaboration with Google and Samsung is the new Chromebook, an affordable and very limited in functionality laptop for just $249. No wonder ARM wants to bite a piece of Intel\u0026rsquo;s market share, especially datacenters and servers. ARM CEO is confident in his company and promises even more amazing computing power to come in the nearest future.\nThese are the scenarios we can think of, when discussing such rumors. This in fact could be a mass hit: Microsoft was able to lower the power consumption and reach 10-hour battery life with x86 tablets. We are really living in a very interesting world.\nRead this: \u0026ldquo;Apple Said to Be Exploring Switch From Intel for Mac\u0026rdquo;, Bloomberg Original Article\nApple Looking to Drop Intel Chips From Mac Computers [REPORT], Mashable\nWill Apple Switch the Mac to ARM? Why the Rumors Do - And Don\u0026rsquo;t - Ring True, AllthingsDigital\nARM Chief: It\u0026rsquo;s a bit early to write Intel\u0026rsquo;s obituary, AllthingsDigital\n","permalink":"https://maratkee.com/posts/2012-11-09-apple-moves-to-arm-no-way-in-at-least-the-next-4-years/","summary":"\u003cp\u003e7 years ago Apple announced that they would be moving from PowerPCs to Intel\u0026rsquo;s x86 CPUs in two years because they had been producing less heat and running much faster (PowerPCs were built by IBM. The 8-core version of this chip also powers PlayStation 3 ). This was a very dangerous step, which definitely brought massive boost in performance for Apple products, but caused additional emulation layer to run the legacy applications.\u003c/p\u003e","title":"Apple moves to ARM? No way in at least the next 4 years!"},{"content":"crosspost x codebranch There were so many announcements this month, that the tech press kept whining about the jetlags and whole difficulty of travelling around the globe. And we’re not talking about the small announcements and launches – all of the three IT giants had something new for the ever growing personal computing market. October was huge for us as mobile developers, because we are the ones who will bring to life our future projects for these platforms.\nThis column is not about the reviews and mobile platforms news, it’s about catching up and telling about interesting events on the IT landscape.\n- Windows 8 and Windows RT launch - Apple event: iMac, Pros, MacMini, new iPads - Google Nexus event Windows 8 / RT launch We really like Microsoft’s latest design language (#dontsaymetro), and we’ve been trying windows 8 out for almost 2 months now. There are UX details that many of the users might find questionable, but once you got used to Win8, it’s suddenly a pretty good operating system.\nBoth engadget and the verge stated that despite some unintuitiveness, the OS itself is very compelling once you passed the learning curve.\nFrom the development side, we really like the ability to easily port your Windows 8 solutions to Windows RT and Windows Phone 8, because of the shared kernel. We will aim to write an article about the advantages and flexibility Microsoft gives us with the shared kernel approach, since we have Windows Phone developers in house, but you can already have some examples and tutorials at dev.windows.com\nReviews: Anandtech, The Verge, Engadget\nSurface RT announcement You probably heard about surface: it’s a tablet from Microsoft and the only product within the recent years that created a giant amount of buzz around itself. Fancy ads, modern music, cool video. The [Verge gave it 7.0 out of 10](http://web.archive.org/web/20121204201905/http://www.theverge.com/2012/10/23/3540550/microsoft-surface-review), which seems to be pretty reasonable and even good, since Josh doesn’t like anything windows-realted very much. Engadget rated the tablet pretty good as well, with less criticism. Overall media reception was pretty good, except NY Times and Gizmodo, who crushed the tablet.\nThe best review was clearly written by anandtech, these guys always make awesome breakdowns and analysis on the tiniest details.\nApple Announcements Apple annouced the updates to the whole bunch of it’s products, from iPad’s successor “iPad 4th gen” and Nexus 7 / Kindle rival “iPad mini” to the new iMac, Mac Mini, and MacBook Pro with Retina 13″.\nRetina on 13″ is gorgeous, that’s really great! And the whole lineup was updated. Really massive launch for Apple. The only question is the discontinuation of iPad 3 (aka the New iPad) production, but it’s replaced with the 4th gen iPad, the price is the same. The Verge already reviewd iPad Miniand the new iPad 4th Gen.\nWhat we love the most from the development point of view, is that the iPad mini retains the same resolution the iPad 2 did, so no need to fix / rescale your apps! This is the unification approach by Apple, that is loved by mobile developers.\nThis year was huge for Apple! The whole-new iPod lineup, 2 iPad revamps, iPad mini, retina laptops, new iMacs and MacMini!\n## Google announced the next Nexus lineup, along with Jelly Bean 4.2 LG had became the next Nexus maker (Nexus 4), along with Samsung (Nexus 10 tablet). While both of the devices are very balanced, Nexus 10 impresses with the stunning 2500-1600 display! Check out the big story on the new Nexus line by the Verge. Clearly, Nexus line truly shows Google’s commitment to improve Android user experience, and how the true Android phones should be done. In the next few iterations we can see an ultimate iPhone rival.\nSo, clearly the audience got a wide choice of new products this months – whether you are an Apple fan, an Android geek or all nuts about new Windows 8 style, there are new gadgets to stand in line for!\n","permalink":"https://maratkee.com/posts/2012-10-31-october-is-for-launch-huge-announcements-from-microsoft-apple-and-google-mobile-platforms-news-overview/","summary":"\u003cp\u003e\u003ca href=\"http://codebranch.com/october-mobile-platforms-news/\"\u003ecrosspost x codebranch \u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eThere were so many announcements this month, that the tech press kept whining about the jetlags and whole difficulty of travelling around the globe. And we’re not talking about the small announcements and launches – all of the three IT giants had something new for the ever growing personal computing market. October was huge for us as mobile developers, because we are the ones who will bring to life our future projects for these platforms.\u003c/p\u003e","title":"October is for Launch. Huge announcements from Microsoft, Apple and Google: Mobile Platforms News Overview"},{"content":"\nHi everyone, as always I\u0026rsquo;d like to rant on the following: greediness and insanity of Russian retailers. The latest issue of Svyaznoy\u0026rsquo;s catalogue is a great example of utterly insane management and completely moronic pricing amongst almost any hardware company here.\nI was pleased by 6 tablets announced to be sold by the retailer this month, all 6 from Sammy, Asus and Acer. I was happy to see my beloved low-cost Acer Iconia W510 ($499 in US) (previews (1) and (2))! But here it\u0026rsquo;s priced as some crazy-ass magnesium-made premium ultra-fucking-machine. And that\u0026rsquo;s for Clover Trail! No way!\nAsus Vivo Tab RT (WinRT) Hi there, Vivo Tab RT =) Long time to see! Had a pretty good review both at the Verge and Engadget. Got a sweet price for the US as well ($499+). Russian Retail Price, anyone? $1130 And that\u0026rsquo;s for the RT tab! Are you out of your mind? Really? Ok, moving on.\nAsus Vivo Tab (Win8, Clover Trail) The price for the Atom Clover Trail based solution is what? $1330 Oh shi~, me can buy miself sum Macbook Pro for that price! Or even better - the latest awesome Acer S7!\nAcer Iconia W510 / W511(3G) (Win8, Clover Trail) For the record: that was the mid range solution that I wanted. I really wanted to give the tab a chance. I still want, even for 19.000 Roubles (which is roughly a $670 against $499 in US!). Ok, not THAT bad. By that can\u0026rsquo;t compete with the New iPad w/ Retina Screen and the same price for the base WiFi 16 Gigs model. Nah, no way. Diggin a grave for yourself, Acer! $900 is the price for the 3G model.\nAcer Iconia W700 (Win8 Pro, Ivy Bridge) That\u0026rsquo;s the tab that Paul Thurott loves! The price for core i5 is the same as for ASUS\u0026rsquo; Clover Trail-based solution, Insane price tag. **$1300 for Core i5, 4gb RAM, Intel HD 4000, 64 gigs of memory + MicroSD. **\nBluetooth Keyboard + Doc-Station (oh god it\u0026rsquo;s fugly) included.\nSamsung Ativ Smart PC (Win8, Clover Trail) No, no, no! What\u0026rsquo;s wrong with the pricing. Acer, at least includes doc station and keyboard. Sammy\u0026rsquo;s option: $900 for Clover Trail based tab. Reason? Doubtful Sales. Let\u0026rsquo;s look at the situation in 2 months or so.\nSamsung Ativ Smart PC Pro (Win8 Pro, Ivy Bridge) At least $200 difference between Clover Trail based tablet and the Ivy Bridge one seems right. Ideal price would be ~$800-900, but I guess $1100 is not that bad for a core-i5 device. Competitively priced among it\u0026rsquo;s core-i5 rivals, but unreasonably priced against the competition.\nThat\u0026rsquo;s all folks, sorry for the typos and stuff like that - It\u0026rsquo;s already 2AM =) Have a nice whatever.\n","permalink":"https://maratkee.com/posts/2012-10-31-windows-8-slates-moronic-pricing-in-russia/","summary":"\u003cp\u003e\u003cimg loading=\"lazy\" src=\"/images/genius-meme.jpg\"\u003e\u003c/p\u003e\n\u003cp\u003eHi everyone, as always I\u0026rsquo;d like to rant on the following: greediness and insanity of Russian retailers. The latest issue of  \u003ca href=\"http://svyaznoy.ru\"\u003eSvyaznoy\u0026rsquo;s\u003c/a\u003e catalogue is a great example of utterly insane management and completely moronic pricing amongst almost any hardware company here.\u003c/p\u003e\n\u003cp\u003eI was pleased by \u003cstrong\u003e6 tablets\u003c/strong\u003e announced to be sold by the retailer this month, all 6 from \u003cstrong\u003eSammy, Asus and Acer\u003c/strong\u003e. I was happy to see my beloved low-cost Acer Iconia W510 ($499 in US) (previews\u003ca href=\"http://www.engadget.com/2012/10/09/acer-iconia-w510-review/\"\u003e (1)\u003c/a\u003e and \u003ca href=\"http://arstechnica.com/gadgets/2012/10/acer-iconia-w510-windows-8-tablet-starts-at-500-launches-november-9/\"\u003e(2)\u003c/a\u003e)! But here it\u0026rsquo;s priced as some crazy-ass magnesium-made premium ultra-fucking-machine. And that\u0026rsquo;s for Clover Trail! No way!\u003c/p\u003e","title":"Windows 8 Slates. Moronic Pricing in Russia"},{"content":"crosspost x codebranch\nWe are Codebranch – an external web development team. For the last couple of months we’ve been preparing the grounds to run – now the website is up, our 3 offices in Finland, Russia and Turkey fully operational, so we’re good to go!\nCodebranch Website We aimed to make our website content-centric, so you won’t find awesome charts and colorful pictures. You can find important information like what we do and how to reach us almost instantly. The same applies to the whole approach of our company – we work in a transparent, leanand efficient way.\nThe External Web Development Idea When we created Codebranch, the idea was simple: we wanted to be team which is not a spare pair of hands, but an extra brain for external development. So this is what we do:\n- develop stable, reliable solutions; - consult on the workflow; - aim to point out possible pitfalls. Our final mission is not just the completed solution, but also complete understanding between developers and client in the course of work.\nOur Web Development Team Each of our developers has between 3+ and 8+ years of experience. We are really proud of our team’s professionalism, but what makes us really great is shared development experience. Our team has been working together for almost 2 years, and we believe that a well-shaped team brings more advantages to the working process.\nOur Approach to Development Everything we do – we execute with care.\n- We ask the right questions to clarify important matters before we start the project. Always. - There are usually multiple ways to achieve a goal. We can suggest more flexible solutions. - We aim to point out possible pitfalls and think how to avoid them. - Clear roadmap, displaying the project stages in dynamics will be given after the contract sign-off. - English is a must for everyone in the team. - Project Managers are the tech people too. Everyone is very fluent in project’s technical details. Development Services We have been developing Web Apps and Websites for a very long time – we live webdev! HTML5 + Canvas, Responsive, Facebook Applications, Complex Frontend and Backend coding – we can help you present yourself in the web, develop an additional module to your website, integrate it with your CRM system.\nWe can help you with CMS as well!\n- We love the buzz and community around WordPress. In fact, we build our own websites on WordPress as well! - In case you are looking for an enterprise solution – here comes our team, ready for some Drupal Develoment. If you need / use a helpdesk, and Zendesk in particular: we can help you with its customization and integration. That’s something we’ve been working with quite often for the past 2 years.\nWe build mobile solutions as well. Whether it’s a mobile version of a website, native or a cross-platform app – don’t hesitate to ask a quote on your project.\nWe will share our thoughts on the industry, as well as development tips and tricks, be sure to visit our blog and leave us a comment =)\n","permalink":"https://maratkee.com/posts/2012-10-30-codebranch-an-external-web-development-team-is-now-active/","summary":"\u003cp\u003e\u003ca href=\"http://codebranch.com/codebranch-web-development-team/\"\u003ecrosspost x codebranch\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eWe are Codebranch – an external web development team. For the last couple of months we’ve been preparing the grounds to run – now the website is up, our 3 offices in Finland, Russia and Turkey fully operational, so we’re good to go!\u003c/p\u003e\n\u003ch2 id=\"codebranch-website\"\u003eCodebranch Website\u003c/h2\u003e\n\u003cp\u003eWe aimed to make our website content-centric, so you won’t find awesome charts and colorful pictures. You can find important information like \u003ca href=\"http://web.archive.org/web/20121204200144/http://codebranch.com/our-services\"\u003ewhat we do\u003c/a\u003e and \u003ca href=\"http://web.archive.org/web/20121204200144/http://codebranch.com/contact-us\"\u003ehow to reach us\u003c/a\u003e almost instantly.\nThe same applies to the whole approach of our company – we work in a transparent, leanand efficient way.\u003c/p\u003e","title":"Codebranch: an external web development team is now active!"},{"content":"I love Surface RT, the way it looks and works. I\u0026rsquo;m even ok with the lack of ***mkv **codec support (although, that\u0026rsquo;s a NO for me, until there\u0026rsquo;s an app).\nHowever, reading the latest articles on how MS \u0026ldquo;nailed\u0026rdquo; shipping Surface Pre-Orders again makes me tip my hat to Apple, because of it\u0026rsquo;s polished supply / retail lines.\nSurface RT — first attempt\nLatest \u0026ldquo;Where is my Microsoft Surface? Here\u0026rsquo;s what we know\u0026rdquo; article sheds some light on the shipping issues inside the software giants. Although zdnet really sucks in 70% of it\u0026rsquo;s \u0026ldquo;analytics\u0026rdquo;, this is a good example of trying to understand what went wrong.\nSource: zdnet\n","permalink":"https://maratkee.com/posts/2012-10-29-be-microsoft-screw-your-shipping-up/","summary":"\u003cp\u003eI love Surface RT, the way it looks and works. I\u0026rsquo;m even ok with the lack of ***mkv **codec support (although, that\u0026rsquo;s a NO for me, until there\u0026rsquo;s an app).\u003c/p\u003e\n\u003cp\u003eHowever, reading the latest articles on how MS \u0026ldquo;nailed\u0026rdquo; shipping Surface Pre-Orders again makes me tip my hat to Apple, because of it\u0026rsquo;s polished supply / retail lines.\u003c/p\u003e\n\u003cp\u003e\u003cimg loading=\"lazy\" src=\"/images/jailbreak-microsoft-surface.png\"\u003e\n\u003cem\u003eSurface RT — first attempt\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eLatest \u0026ldquo;\u003ca href=\"http://www.zdnet.com/where-is-my-microsoft-surface-heres-what-we-know-7000006471/\"\u003e\u003cstrong\u003eWhere is my Microsoft Surface? Here\u0026rsquo;s what we know\u003c/strong\u003e\u003c/a\u003e\u0026rdquo; article sheds some light on the shipping issues inside the software giants. Although zdnet really sucks in 70% of it\u0026rsquo;s \u0026ldquo;analytics\u0026rdquo;, this is a good example of trying to understand what went wrong.\u003c/p\u003e","title":"Be Microsoft! Screw your shipping up!"},{"content":"Oh that is sooooo awesome! I love when the guys speak like that xD /s\nZend and PHP have made significant inroads into the enterprise market in the last few years — Gutmans told me that “when we go up against Java or .Net, we win — and the new integrated development environment for mobile, cloud, and business applications is part of a new mobile-first push for the company. http://venturebeat.com/2012/10/23/huge-news-php-developers-can-now-design-build-and-publish-mobile-apps-right-in-zend-studio/\nUPD: Anyway, my tip of a hat for the work they\u0026rsquo;ve done =)\n[youtube=http://www.youtube.com/watch?feature=player_embedded\u0026amp;v=d7u2CYVUucY]\nhttp://venturebeat.com/2012/10/23/php-developers-you-must-see-this-creating-a-cloud-enabled-native-mobile-app-in-10-minutes-or-less-in-zend-studio/\n","permalink":"https://maratkee.com/posts/2012-10-24-zend-guys-on-their-enterprise-victories/","summary":"\u003cp\u003eOh that is sooooo awesome! I love when the guys speak like that xD /s\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eZend and PHP have made significant inroads into the enterprise market in the last few years — Gutmans told me that “when we go up against Java or .Net, we win — and the new integrated development environment for mobile, cloud, and business applications is part of a new mobile-first push for the company.\n\u003ca href=\"http://venturebeat.com/2012/10/23/huge-news-php-developers-can-now-design-build-and-publish-mobile-apps-right-in-zend-studio/\"\u003ehttp://venturebeat.com/2012/10/23/huge-news-php-developers-can-now-design-build-and-publish-mobile-apps-right-in-zend-studio/\u003c/a\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eUPD: Anyway, my tip of a hat for the work they\u0026rsquo;ve done =)\u003c/p\u003e","title":"Zend guys on their enterprise victories"},{"content":" 📬 Predictable Teams Newsletter Еженедельный дайджест про Agile, AI adoption, flow metrics и управление командами. Без воды — только данные, исследования и практические инсайты.\n📊 Данные, не мнения Исследования, метрики, A/B тесты. Каждый тезис подкреплён источником.\n🔧 Практика из 50+ команд Real-world кейсы из Raiffeisen, Agile Ufa, коворкинга и спикерского опыта.\n🧠 AI × Agile Как AI меняет состав команд, flow, delivery. Что работает, что — хайп.\nПодписаться Подписаться → Или подписаться на Substack напрямую. Без спама, отписка в один клик.\nПримеры выпусков AI-First Команды: Состав, Размер, Гибкость — Extended Research: 4 модели, Deloitte vs практика, скрытые риски. Читать → The Harness Paradox — Почему 500 инженеров за год внедряли AI — и ни одна гипотеза не ускорила доставку. Читать → Cognitive Debt — MIT Media Lab: ChatGPT-группа показала самую слабую нейронную связность. Что это значит для teams. Читать → Об авторе Марат Киньябулатов — Agile Coach @Raiffeisen (50 команд), спикер DUMP / MergeConf / PeopleSense, автор фреймворка «Учпочмак» (Цели → Люди → Поток). Основатель Agile Ufa. Пишу на Habr, Substack, VC.ru.\n","permalink":"https://maratkee.com/newsletter/","summary":"\u003cdiv class=\"newsletter-page\"\u003e\n  \u003ch1\u003e📬 Predictable Teams Newsletter\u003c/h1\u003e\n  \u003cp class=\"subtitle\"\u003eЕженедельный дайджест про Agile, AI adoption, flow metrics и управление командами. Без воды — только данные, исследования и практические инсайты.\u003c/p\u003e\n  \u003cdiv class=\"newsletter-benefits\"\u003e\n    \u003cdiv class=\"benefit\"\u003e\n      \u003cspan class=\"benefit-icon\"\u003e📊\u003c/span\u003e\n      \u003ch3\u003eДанные, не мнения\u003c/h3\u003e\n      \u003cp\u003eИсследования, метрики, A/B тесты. Каждый тезис подкреплён источником.\u003c/p\u003e\n    \u003c/div\u003e\n    \u003cdiv class=\"benefit\"\u003e\n      \u003cspan class=\"benefit-icon\"\u003e🔧\u003c/span\u003e\n      \u003ch3\u003eПрактика из 50+ команд\u003c/h3\u003e\n      \u003cp\u003eReal-world кейсы из Raiffeisen, Agile Ufa, коворкинга и спикерского опыта.\u003c/p\u003e\n    \u003c/div\u003e\n    \u003cdiv class=\"benefit\"\u003e\n      \u003cspan class=\"benefit-icon\"\u003e🧠\u003c/span\u003e\n      \u003ch3\u003eAI × Agile\u003c/h3\u003e\n      \u003cp\u003eКак AI меняет состав команд, flow, delivery. Что работает, что — хайп.\u003c/p\u003e\n    \u003c/div\u003e\n  \u003c/div\u003e\n  \u003cdiv class=\"newsletter-form\"\u003e\n    \u003ch2\u003eПодписаться\u003c/h2\u003e\n    \u003cform action=\"https://predictableteams.substack.com/api/v1/free\" method=\"post\" target=\"_blank\"\u003e\n      \u003cinput type=\"email\" name=\"email\" placeholder=\"your@email.com\" required\u003e\n      \u003cbutton type=\"submit\"\u003eПодписаться →\u003c/button\u003e\n    \u003c/form\u003e\n    \u003cp class=\"form-note\"\u003eИли подписаться на \u003ca href=\"https://predictableteams.substack.com\" target=\"_blank\"\u003eSubstack\u003c/a\u003e напрямую. Без спама, отписка в один клик.\u003c/p\u003e","title":"Newsletter — Predictable Teams"}]