[{"content":"Welcome to the new LeanTechPro. Same content, same mission — but this site no longer runs on a WordPress server. It\u0026rsquo;s now a static site hosted on Cloudflare Pages, which means:\nFaster page loads — every page is pre-built and served from Cloudflare\u0026rsquo;s edge network Nothing to hack — no PHP, no database, no plugins to update Free hosting — Cloudflare Pages\u0026rsquo; generous free tier covers a blog easily Version-controlled content — every article is a plain-text Markdown file in Git If anything looks off, it\u0026rsquo;s probably a leftover from the migration — let me know.\n","permalink":"https://leantechpro.com/hello-static/","summary":"\u003cp\u003eWelcome to the new LeanTechPro. Same content, same mission — but this site no\nlonger runs on a WordPress server. It\u0026rsquo;s now a static site hosted on\n\u003ca href=\"https://pages.cloudflare.com\"\u003eCloudflare Pages\u003c/a\u003e, which means:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eFaster page loads\u003c/strong\u003e — every page is pre-built and served from Cloudflare\u0026rsquo;s edge network\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eNothing to hack\u003c/strong\u003e — no PHP, no database, no plugins to update\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eFree hosting\u003c/strong\u003e — Cloudflare Pages\u0026rsquo; generous free tier covers a blog easily\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eVersion-controlled content\u003c/strong\u003e — every article is a plain-text Markdown file in Git\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eIf anything looks off, it\u0026rsquo;s probably a leftover from the migration — let me know.\u003c/p\u003e","title":"LeanTechPro is now static (and that's a good thing)"},{"content":"This post is a note-to-self: the exact steps to publish a new article on LeanTechPro.\n1. Create the file cd ~/dev/leantechpro hugo new content posts/my-new-post.md Or just copy an existing post in content/posts/ and rename it.\n2. Write Open the file. Update the front matter (title, date, tags), set draft: true while writing, and write the body in Markdown. Images go in static/images/ and are referenced as /images/my-photo.png.\n3. Preview locally hugo server -D Open http://localhost:1313 — the site reloads as you type.\n4. Publish Set draft: false in the front matter, then:\ngit add . git commit -m \u0026#34;post: my new post\u0026#34; git push Cloudflare Pages detects the push, rebuilds the site, and the article is live in about a minute. That\u0026rsquo;s it — no admin panel, no plugins, no regeneration.\n","permalink":"https://leantechpro.com/how-to-publish/","summary":"\u003cp\u003eThis post is a note-to-self: the exact steps to publish a new article on LeanTechPro.\u003c/p\u003e\n\u003ch2 id=\"1-create-the-file\"\u003e1. Create the file\u003c/h2\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-bash\" data-lang=\"bash\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003ecd ~/dev/leantechpro\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003ehugo new content posts/my-new-post.md\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003eOr just copy an existing post in \u003ccode\u003econtent/posts/\u003c/code\u003e and rename it.\u003c/p\u003e\n\u003ch2 id=\"2-write\"\u003e2. Write\u003c/h2\u003e\n\u003cp\u003eOpen the file. Update the front matter (title, date, tags), set \u003ccode\u003edraft: true\u003c/code\u003e\nwhile writing, and write the body in Markdown. Images go in \u003ccode\u003estatic/images/\u003c/code\u003e\nand are referenced as \u003ccode\u003e/images/my-photo.png\u003c/code\u003e.\u003c/p\u003e\n\u003ch2 id=\"3-preview-locally\"\u003e3. Preview locally\u003c/h2\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-bash\" data-lang=\"bash\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003ehugo server -D\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003eOpen http://localhost:1313 — the site reloads as you type.\u003c/p\u003e","title":"Publishing workflow (cheat sheet)"},{"content":" AGENTIC AI · HOW LEANTECHPRO RUNS\nOne Operator. An Agentic Production System. LeanTechPro runs its content, research, and client deliverables on a set of AI agent skills I designed, built, and operate daily. Each skill encodes a working method as a standard. This page shows the system. I demo it live in 90 seconds.\nSee it live → 30 minutes · Screen share · Real production run, not slides\nThe design\nHuman source. AI derivatives. Never the reverse. 1\nThe human makes the source One real case study, one banked story, one set of audit findings. The judgment, the voice, and the field work stay human. That is non-negotiable by design.\n2\nSkills encode the standard Each skill is a written standard the agent loads on demand: voice rules, structure, quality gates, output format. The method is in the system, not in my memory.\n3\nThe agent industrializes the output One pass produces every downstream artifact: posts, captions, carousel copy, newsletter issue, briefs, client reports, all with built-in quality. There is no rework loop.\nThis is the same production logic I bring to client teams: standard work, one-piece flow, quality built into the process. The AI did not replace the method. It made the method executable.\nThe registry\nSix skills in production. Each card describes what the skill takes in, what it produces, and the operating principle it encodes. The skill definitions themselves are proprietary and stay private.\n🔁\nStory Engine In: one case study or article from the story bank.\nOut: eight channel-ready artifacts in one pass: the weekly newsletter issue with its two branded visuals, LinkedIn text post, carousel copy, X thread, Bluesky post, and Substack Note.\nEncodes: one-piece flow. One source, one pass, every channel served. Zero duplicate writing effort.\n✍️\nWriting System In: a topic, a brief, or a draft.\nOut: long-form articles and newsletter issues in the LeanTechPro voice, structure and SEO rules applied.\nEncodes: jidoka. Voice, structure and quality rules are built into the process, so quality is produced, not inspected in afterwards.\n🔎\nSEO Research Brief In: a topic idea.\nOut: a build-ready content brief: keyword research, competitor analysis, search intent, recommended structure, differentiation angle.\nEncodes: grasp the situation before acting. Study first, then build once. No writing starts without a validated brief.\n📣\nLinkedIn Post Engine In: the week’s story and its atoms.\nOut: publication-ready posts following codified formats, hook rules, and publishing constraints.\nEncodes: standard work. Six proven post formats and hard rules on hooks and structure, applied identically every week.\n💬\nEngagement Layer In: a post worth contributing to.\nOut: a comment that adds an angle, a perspective, or a concrete field example. Never generic agreement.\nEncodes: daily cadence. Fifteen minutes every morning, standardized, so consistency does not depend on motivation.\n📊\nTech Audit Report In: diagnostic findings from a client engagement.\nOut: a branded, board-ready audit presentation: executive summary, code quality, velocity, team health, security, action items.\nEncodes: the standardized deliverable. The client-facing proof that this system industrializes real work, not just marketing.\nMeasured on my own operation\nWhat the system produces. I run delivery diagnostics for a living. So the first delivery system I instrumented was my own.\nOutput\n8 in 1\nEight channel-ready derivatives generated from one source story, in a single pass.\nTime\n4h ↓\nFull weekly content operation, source to publication across five channels, in about four hours.\nSource\n1 story\nOne banked case study per week. The human input is small by design. The system does the fan-out.\nRework\n≈ 0\nVoice and quality rules live in the skills. Outputs ship with minutes of adjustment, not rewrites.\nWhy skills, not prompts. Ad-hoc AI use ✗The method lives in someone’s head and in scattered prompts\n✗Output quality varies with the day and the person\n✗Every task re-explains the same rules from scratch\n✗Nothing transfers when the person is unavailable\nA skills-based system ✓The method is written down as a standard the agent executes\n✓Quality rules are built in, so output is consistent by construction\n✓Skills load on demand and improve version by version\n✓The capability belongs to the organization, not to one operator\nThis scales beyond a one-person company. These skills are built on an open agent-skills standard. In an enterprise, the same files are provisioned centrally by administrators across an organization, deployed programmatically through an API into internal applications, or shipped inside engineering workflows. Building the skill is the small part. Making adoption produce measurable delivery results is the work, and that is what I do for client teams.\nOpen standard format Central provisioning API deployment Portable across platforms\nWatch it run. The fastest way to judge this system is to watch a real production pass: one story in, eight artifacts out, live on screen. Then we talk about what the same approach looks like inside your organization.\nBook the 90-second demo →\n30-minute call · The demo takes 90 seconds · The rest is your questions\nPrefer to read first? The articles this system produces →\n","permalink":"https://leantechpro.com/agentic-system/","summary":"\u003cdiv class=\"section hp-hero\"\u003e\n\u003cdiv class=\"hp-hero-label hp-fade\"\u003e\n\u003cp\u003eAGENTIC AI · HOW LEANTECHPRO RUNS\u003c/p\u003e\n\u003c/div\u003e\n\u003ch1 id=\"one-operator-an-agentic-production-system\"\u003eOne Operator. An Agentic Production System.\u003c/h1\u003e\n\u003cp\u003eLeanTechPro runs its content, research, and client deliverables on a set of AI agent skills I designed, built, and operate daily. Each skill encodes a working method as a standard. This page shows the system. I demo it live in 90 seconds.\u003c/p\u003e\n\u003cdiv class=\"hp-cta-group hp-fade hp-fade-3\"\u003e\n\u003cp\u003e\u003ca href=\"https://cal.com/jlcossi/leantechpro-discovery-call\" class=\"hp-btn-primary\"\u003eSee it live →\u003c/a\u003e \u003cspan class=\"hp-sub-cta\"\u003e30 minutes · Screen share · Real production run, not slides\u003c/span\u003e\u003c/p\u003e\n\u003c/div\u003e\n\u003c/div\u003e","title":"Agentic System"},{"content":" HALF-DAY WORKSHOP · FOR ENGINEERING LEADERS\nYour AI tools made coding faster. Delivery didn’t move. A half-day working session with your leadership team. We map where the speed leaks in your delivery system, find the constraint, and you leave with the redesign plan. Built on 15 years of measured turnarounds inside engineering and IT teams at large regulated enterprises.\nBook a Discovery Call → 30 minutes · No pitch · We scope it to your team Not ready to talk? Take the Free Scorecard →\nThe Evidence\nThe bottleneck moved. The data shows where. The tools work. Code arrives faster than your system was designed to absorb. The queue forms downstream, where nobody is looking.\nOpenAI, official\n+70%\nMore pull requests merged weekly by OpenAI’s own engineers. Review could not absorb the volume, so Codex now reviews almost every PR. Even the toolmaker rebuilt its review step.\nFaros AI, 22,000 devs\n+91%\nRise in median code review time in one year. Pull requests grew 51% larger. Code comes in faster than anyone can check it.\nFaros AI, 2026\n31%\nMore PRs now merge with no review at all. The queue stopped growing. It is being skipped.\nGoogle DORA 2025\nBoth ↑\nAI adoption lifts throughput and delivery instability at the same time. DORA’s conclusion: a systems problem, not a tools problem.\nFive steps, your data on the wall 1\nYour flow on the wall. How work actually moves from request to production, including the handoffs and waits your tools don’t track. Drawn live with your delivery data. Not the org chart, not the Jira board.\n2\nWhere the speed went. Your developers produce more than they did two years ago. We find what that output became inside the system: review queues, rework, waiting. Sized in days.\n3\nThe constraint, today. Speed applied upstream deepens the queue downstream. We locate where your constraint sits now, not where it sat before the tools arrived.\n4\nCountermeasures, designed by your team. One move per leak, an owner per move. No new tools, no reorg. Their solutions, which is why they hold.\n5\nTwo numbers, from Monday. The redesign plan, and the two measures that tell you within weeks whether delivery actually sped up.\nAlready running DORA or flow metrics? Bring them. They measure the steps you track. The wall shows the ones you don’t, and that’s where the time goes.\nYour leadership team sees the same picture at the same time. Half the value of the room is that nobody has to argue about the diagnosis afterwards.\nDeliverables\nWhat you leave with 🗺️\nThe constraint map Your delivery system on one page: where work waits, where it bounces back, and where the post-AI constraint actually sits. Drawn live, with your data.\n🎯\nThe redesign plan The prioritized moves your team designed, each with an owner and a first step. Not my playbook. Their solutions, which is why they hold.\n📊\nThe measurement baseline The two numbers to track from Monday morning, and how to read them. You will know within weeks whether the redesign works, without waiting for a quarterly review.\nWho this is for Book the call if ✓ You lead engineering: CTO, VP Engineering, Head of Delivery or Platform\n✓ Your teams adopted AI coding tools 6+ months ago and delivery has not visibly sped up\n✓ Review queues, rework, or production instability grew since the tools arrived\n✓ You can put your delivery leadership in one room for half a day\nSkip it if ✗ You want an AI tool evaluation or a vendor comparison. The tools are fine.\n✗ You are looking for training on prompting or coding assistants\n✗ Nobody who owns delivery outcomes can attend\n✗ You expect a dashboard. What you leave with is a decision your team made, not a chart.\nTrack Record\nThe method behind the half-day The workshop compresses the Lean management diagnostic I have run inside engineering organizations for 15 years. Every number below was measured on the ground, with the team.\nBanking Software\n91% ↓\nDefect reduction in 60 days. Right-first-time fixes went from 9% to 100%. BNP Paribas Fortis.\nDevOps\n64→29\nDeployment lead time in days, halved. No new tools, no reorg. Sodexo.\nProject Delivery\n24→55%\nOn-time delivery across 18 BI projects on 4 continents. Client satisfaction rose from 5.5 to 9.4/10.\nIT Operations\n0\nProduction deployment incidents on an international DBA team. Employee NPS up 65 points. Michelin.\n15 years of delivery turnarounds across Europe and Africa. Read what clients say →\nI run my own company on agentic AI daily. Live demo on request →\nMichelin BNP Paribas Sodexo IQera Sopra Steria Docaposte EDF Ipsen\nFormat and price\nHalf day (4 hours) · On site or remote · Your engineering leadership team\nPreparation: one 30-minute call and your delivery data. Nothing else.\nDelivered in French or English. Deliverables in the language of your team.\nFlat price\nNo hourly billing, no follow-on obligation.\nBook a Discovery Call →\nYou already paid for the speed. The tools delivered. The system around them did not adapt. One half-day with your leadership team finds where the speed leaks and leaves you with the plan to capture it.\nBook a Discovery Call →\n30 minutes · Free · We check the fit before anything else\nNot ready to talk? Take the Free Scorecard →\n","permalink":"https://leantechpro.com/workshop/","summary":"\u003cdiv class=\"section hp-hero\"\u003e\n\u003cdiv class=\"hp-hero-label hp-fade\"\u003e\n\u003cp\u003eHALF-DAY WORKSHOP · FOR ENGINEERING LEADERS\u003c/p\u003e\n\u003c/div\u003e\n\u003ch1 id=\"your-ai-tools-made-coding-faster-delivery-didnt-move\"\u003eYour AI tools made coding faster. Delivery didn’t move.\u003c/h1\u003e\n\u003cp\u003eA half-day working session with your leadership team. We map where the speed leaks in your delivery system, find the constraint, and you leave with the redesign plan. Built on 15 years of measured turnarounds inside engineering and IT teams at large regulated enterprises.\u003c/p\u003e\n\u003cdiv class=\"hp-cta-group hp-fade hp-fade-3\"\u003e\n\u003cp\u003e\u003ca href=\"https://cal.com/jlcossi/leantechpro-discovery-call\" id=\"ws-hero-call\" class=\"hp-btn-primary\"\u003eBook a Discovery Call →\u003c/a\u003e \u003cspan class=\"hp-sub-cta\"\u003e30 minutes · No pitch · We scope it to your team\u003c/span\u003e \u003ca href=\"https://jlcossi.activehosted.com/f/59\" id=\"ws-hero-scorecard\" class=\"hp-btn-soft\"\u003eNot ready to talk? Take the Free Scorecard →\u003c/a\u003e\u003c/p\u003e\n\u003c/div\u003e\n\u003c/div\u003e","title":"Workshop"},{"content":" KEY TAKEAWAYS A management Obeya is the leadership team’s operating system made visible. It tracks the health of the business, not project deliveries. Seven boards on the walls of one room replaced opinion-based meetings with weekly data-driven sessions in 60 minutes. The agency director continued to run the Obeya after the engagement ended. The boards evolved, the weekly rhythm never stopped. An IT services agency director wanted to change how his management team worked together. He had a strategy and objectives. He also had talented people running operations, commercial development, and client delivery. What he did not have was a way to see it all in one place, discuss it factually, and solve problems before they became crises.\nI designed and built a “management Obeya” with his team. It was not a “project Obeya” tracking deliveries. Here, it was an Obeya for the management team, connecting the agency’s vision, client voice, commercial pipeline, performance indicators, and structured problem-solving on the walls of one room.\nThe agency director had been managing his team through weekly meetings and individual check-ins. Strategy lived in a slide deck nobody reopened. Client issues surfaced when they escalated, not when they started. He wanted a way to run his agency with the same rigor he expected from the project teams delivering for clients.\nWhat a Management Obeya Is Most Obeya examples you find online focus on project management or product development. A management obeya serves a different purpose. It is the leadership team’s operating system, made visible.\nA project Obeya room tracks work as it flows through stages. A management Obeya tracks the health of the entire business unit: clients, revenue, margin, people, problems, commercial pipeline, and strategy execution.\nThe distinction matters because the boards, the rhythm, and the conversations are completely different. In a project Obeya, you ask, “Is this task on track?” In a management Obeya, you ask, “Are we winning clients, keeping our people, and solving the right problems?”\nDesigning the Boards I started by working with the agency director to answer one question: What does he need to see and understand every week to lead this agency?\nWe designed seven modules. Each one occupied a section of the wall.\nClients and Voice of Customer. Who are the clients? What do they say, both positive and negative? Satisfaction scores tracked visually, with clear signals for what needs attention and what is going well. The client voice lived on the wall permanently, not buried in a quarterly survey. It is updated weekly.\nVision and Objectives. The agency’s three-year vision: revenue target, margin target, client alert threshold, and HR indicators. All written on the wall with the current status next to each target. Green or red, without ambiguity.\nCommercial Development. Every active opportunity tracked on a board: client name, offer, status, result, next step. The team could see at a glance which clients were buying, which deals were stalling, and where the pipeline needed attention.\nPerformance Indicators. Six charts covering client alerts, number of proposals sent, HR metrics (turnover, regretted departures), number of commercial interactions, and progress on key initiatives. Each chart showed the trend. Each had an owner responsible for updating it before the weekly meeting.\nProblem Solving. A structured board divided by domain: clients, operations, commercial, and HR. Every problem listed with its cause, actions, results, and what changed as a consequence. It was a PDCA board where problems got investigated and solved.\nMacro Plan. Major projects, roadmap items, and strategic initiatives plotted on a timeline. The management team could foresee dependencies, resource conflicts, and upcoming deadlines without opening a single spreadsheet.\nProduction Monitoring. Current activities, bench status, service delivery. The agency’s operational pulse, visible and up to date.\nWith the Director, we sketched the full Obeya layout by hand on paper first. That included every board, field, and signal system. When I showed the full prototype to the agency director, he pushed back on one point: he wanted the commercial pipeline front and center, not tucked away in a corner. That told me what mattered most to him. We rearranged the layout together and added a strategic action plan section he had not initially considered.\nBuilding It on the Wall I finalized the Obeya prototype first on paper, sketching every board with its layout, fields, and signal systems. Then, with the agency Director, we had additional rounds of fine-tuning together. We were trying to answer questions like: What belonged in the vision section? Which KPIs would the team actually update? What client data mattered enough to put on the wall? Those were the right questions for the Director to reinforce his ownership of the Obeya and for me to understand his focus and empower him with it. Once we agreed on the design, we built the physical boards. We used paper, markers, sticky notes, and printed charts. The whole room took two days to construct, with support from other managers.\nWhen the entire management team walked in for the first time, the room was covered floor to ceiling. Some stood back and scanned the walls in silence. One manager walked straight to the commercial pipeline board and started reading the client names. Another asked, “Are we really going to update all of this every week?” I told him yes, and that most of it would take five minutes once the habit was in place.\nThe boards were not decorative. Every sticky note had an owner. The charts had an update cadence, and every empty field was a question the team had to answer.\nRunning the Obeya The agency director ran a weekly Obeya session, limited to 60 minutes. That was the structure we fixed.\nFirst, the client’s point: what feedback came in this week, positive or negative? If a client raised a problem, the team qualified it and moved it to the problem resolution board.\nSecond, a performance review. There was a focus on two or three indicators, not all of them every week. The team reviewed the trend, identified gaps between target and actual, and initiated a PDCA when the gap was significant.\nThird, problem-solving: Any new issues to surface? For existing problems, what progress has been made this week? One team member presented a PDCA. The rest challenged it and suggested improvements.\nFourth, commercial development. Which offers were moving? Which ones stalled? Why? What changes to the approach were needed?\nFifth, the team set the focus for the following week.\nThe first session ran long. The agency director tried to cover every board, and the team was not used to discussing performance data out loud. It was also necessary to explain the principles. By the third session, the rhythm clicked. He learned to pick two or three indicators to focus on, not all six. The team stopped waiting to be asked and started presenting their own updates. I coached him after each session on how to challenge the performance, what to let go, and the required attitudes.\nWhat Changed Before the Obeya, management meetings covered whatever felt urgent. Discussions circled and depended on who argued the loudest. Problems resurfaced month after month because nobody tracked whether the fix worked.\nAfter the Obeya, the wall set the agenda. The data triggered the conversations. When client satisfaction dipped, the team did not debate whether it was a real problem. The chart showed the trend. They moved to causes and actions.\nOne early win came from the client alerts board. A recurring complaint from one client had been mentioned in meetings for months, but never formally tracked. Once it hit the PDCA board with a named owner and a deadline, the team found the root cause in two weeks: a handoff gap between two departments. They fixed it, and the client noticed. That was the moment the management team stopped seeing the Obeya as overhead and started using it as their tool.\nThe commercial pipeline became visible for the first time. The team could see how many proposals went out, how many converted, and where deals died. Conversations shifted from “we need more revenue” to “why did we lose this specific client, and what do we change in our approach?”\nThe problem resolution board forced closure. A problem entered the board with a cause, an action, a deadline, and an expected result. If the action did not produce the result, the team investigated further. Problems stopped recycling through meetings without resolution.\nProject Obeya vs Management Obeya I have built both. They are discovery tools, but they solve different problems.\nA “project obeya”, like the one I built for a BI team managing 18 projects, tracks delivery: milestones, defects, timelines. The question is always: are we delivering what we promised?\nA “management Obeya” tracks the business. It’s all about clients, revenue, people, and strategy execution. The question is: are we running this organization in the right direction?\nBoth use the same principles: make work visible, track performance against targets, and solve problems with structured methods. But the boards, cadence, and audience are different.\nA project obeya serves project managers and their teams. A “management Obeya” serves the leadership team of a business unit. If you lead a department, division, or service line with 20 or more people, a “management Obeya” gives you what no reporting tool provides: a single place where your entire business is visible, your team is aligned, and problems are solved before they grow.\nHow to Start You do not need a perfect room. You need wall space, paper, markers, and a leadership team willing to update the data every week. There is no one-for-all Obeya. Start and adapt continuously as needed and as challenges arise.\nStart by answering: What are the five things I need to see every week to lead this team? Client health, financial performance, people metrics, commercial pipeline, and open problems are a common starting point. But your Obeya should reflect your reality, not a template.\nBuild the first version in a few hours, with your team. Run your first session and adjust after every meeting. The Obeya is never finished. It evolves as the team learns what information drives better decisions.\nThe agency director continued to run the Obeya after I left. The boards evolved, some modules were simplified, others expanded. But the weekly rhythm never stopped. The obeya changed how he leads: less time chasing information, more time solving problems.\nThe method works the same whether you lead a 10-person agency or a 200-person division. The walls change, but the principles stay the same.\n","permalink":"https://leantechpro.com/management-obeya-case-study/","summary":"\u003cdiv class=\"key-takeaways\"\u003e\n\u003ch2 id=\"key-takeaways\"\u003eKEY TAKEAWAYS\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eA management Obeya is the leadership team’s operating system made visible. It tracks the health of the business, not project deliveries.\u003c/li\u003e\n\u003cli\u003eSeven boards on the walls of one room replaced opinion-based meetings with weekly data-driven sessions in 60 minutes.\u003c/li\u003e\n\u003cli\u003eThe agency director continued to run the Obeya after the engagement ended. The boards evolved, the weekly rhythm never stopped.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003cp\u003eAn IT services agency director wanted to change how his management team worked together. He had a strategy and objectives. He also had talented people running operations, commercial development, and client delivery. What he did not have was a way to see it all in one place, discuss it factually, and solve problems before they became crises.\u003c/p\u003e","title":"Management Obeya: How an IT Services Team Built Their Own War Room"},{"content":" KEY TAKEAWAYS A BI team managing nearly 20 projects across several continents built an Obeya room and doubled on-time delivery in 3 months. The Obeya surfaced milestone collisions, quality failures, and ownership gaps that no status report had ever shown. Three PDCAs run inside the Obeya rescued a go-live, halved defects per delivery, and created a standard that the team still uses. Get the Full Project Obeya Template with all the boards layout: Strategy, performance, macro planning, and problem-solving. Ready to print and fill in.\n[Download Free Template →]\nA team of project managers ran nearly 20 Business Intelligence projects across several continents. On-time delivery sat at 24%. One of four projects hit its deadline. The rest slipped, and every delay rippled into the group’s financial reporting.\nThe division head could not see where projects actually stood. Status reports arrived late, told different stories depending on who wrote them, and never revealed the collisions between milestones until it was too late. Client satisfaction had dropped to 5.5 out of 10.\nI was brought in to fix project delivery performance. What I built with the team was an obeya room, a physical space where every project, every metric, and every problem lived on the walls. Three months later, on-time delivery reached 55%. Defects per delivery dropped from 38 to 19. Client satisfaction climbed to 9.4.\nHere is how it happened.\nThe Starting Point The team sat inside a global enterprise IT department. Two senior project managers, local project leaders spread across several continents, and one external vendor handling development and testing. Nearly 20 BI projects running simultaneously, building reports and dashboards for business teams worldwide.\nWhen I arrived, the two project managers were each tracking their own projects in spreadsheets and via email. There was no shared view of the projects. I asked where I could see the status of all projects, whether separately or together, and nobody could point me to a single, coherent view. Each project manager knew their own projects well, but neither could tell me how their timelines affected each other’s. There was no tracking of the actual vs. target lead time, defects, cost, or real customer satisfaction.\nThe numbers confirmed what the organization already felt. Only 24% of milestones were delivered on time. Defects per delivery stood at 38. Client satisfaction scored 5.5 out of 10, and it was trending down.\nProject managers lacked a core skill: the ability to see problems before they became crises. They managed projects through documents, email threads, and weekly status meetings. When something went wrong, they discovered it afterward. By then, the damage was done.\nBuilding the Obeya Room I designed the Obeya around three zones. Each zone answered a different question.\nStrategy wall. This connected every BI project objective to the CIO’s strategic goals. The IT strategy was clear: end-user centric, business-oriented, result-driven. Leadership had set explicit targets for customer satisfaction, on-time delivery, quality, and budget. Every project on the wall had to trace back to one of those targets. If it did not connect, the team had to ask why they were doing it and lead a clarification with the management.\nPerformance dashboard. Six handwritten charts on the wall, updated weekly: on-time delivery rate, number of defects per delivery, client satisfaction scores, delivery pace (cumulative projects delivered), risk exposure, and budget tracking. Every chart showed the trend line over time. Red meant below target. Green meant on track. No hiding behind averages or quarterly summaries. The team saw reality every week.\nMacro planning wall. Every project is plotted on a single timeline over months. Every project listed its phases: scoping, development, testing, UAT, training, communication, and go-live. Planned milestones marked with symbols. Actual progress tracked with sticky notes. When two milestones collided in the same week, the wall showed it. When a project fell behind, the gap between planned and actual was visible to anyone who walked into the room.\nWith the project managers and their leaders, we built the first version (prototypes) of the Obeya in a 2-day hands-on workshop. We had large sheets of paper taped to the wall, hand-drawn charts, and printed timelines. Once back in their office, the project team plotted every project on the macro planning wall and updated the performance charts, along with the actual projects’ status. On the wall, we had every project, every milestone. The team had never seen their own workload displayed like that. We started to see every conflict, especially as we gained visibility into the future ones. One of the project managers said something like “now I understand why we keep missing dates.”\nThe project managers also added a simple task board next to the planning wall, with three columns: to do, doing, done. It tracked the daily actions tied to the projects, so nothing fell between two weekly sessions.\nWhat the Obeya Revealed The macro planning wall showed what no status report ever had: milestone collisions. Projects competed for the same testing resources in the same weeks. Go-live dates piled up at the end of the quarter because nobody had seen the full picture until now.\nThe performance dashboard forced factual conversations. Before the Obeya, discussions with the division head were opinion-based. Who was on track? It depended on who you asked. After the obeya, the numbers spoke. Managers acknowledged this shift directly: discussions became more factual because the data was on the wall, visible to everyone, and updated every week.\nThe first time we reviewed the performance dashboard together, the division head stopped at the defect chart. He had known deliveries were not clean, but he had never seen the pattern laid out week by week. The trend was clear and getting worse. That was the moment he stopped asking “are we on track?” and started asking “what is causing this?”\nThe wall also revealed a more uncomfortable truth. Defects kept surfacing after delivery, and no one had tracked the pattern until the charts made it undeniable. The data did not point at people. It pointed at a testing process that let those defects through.\nThree PDCAs Inside the Obeya The Obeya made problems visible. PDCA solved them. Three structured problem-solving cycles ran during that engagement.\nRescuing a Go-Live With eight weeks to go-live, not one of the project’s twenty-plus planned reports had been validated. At about a day per report to pre-check and validate, the math did not work. The project faced a slip of a week or two, which would hit the business.\nRoot causes: nobody had sized the actual work against the delivery dates. The developer did not know how many objects he had to test or the total scope of the project. The development database lacked representative data, with dozens of anomalies traced to data gaps.\nActions: The project manager asked the team to report every couple of days on verified reports versus the total. Tech copied the production database into the development environment, allowing testers to work with real data. The team dedicated one business expert full-time to pre-checks and validation for the final stretch.\nResult: every report was delivered, pre-checked, and validated before the deadline. On time.\nFixing Defects at the Source One afternoon I sat next to a developer on the delivery team and watched him execute a test script. He opened a report, exported it to PDF, and checked “OK” on the test line for the export. I looked at the PDF. The user name was missing. The execution date was missing. I asked him why he marked it OK. He looked at the test script again and pointed to the line: “verify PDF export.” It did not say “verify that the user name and execution date appear in the PDF export.” He had tested exactly what was written. Nothing more. He was not careless. The test script was incomplete, and nobody had ever watched him work to see the gap.\nThe test script did not list all the fields that needed verification during PDF and XLS exports. The developer checked what was written, not what mattered. During the observation, the developer also told me he needed the most critical and most frequent use cases from the business, which nobody had provided.\nFixes: We updated the test script to include the missing verification items. We identified the most-used and most critical test cases from the business and handed them over to the development team. We created a test template with a cover page so developers only entered their name once, rather than on every test item.\nDefects per delivery dropped. The team standardized this approach: at the end of every scoping phase, collect the critical use cases from the business and provide them to development before coding starts.\nManaging Local Projects A client complaint landed: more than a dozen missing functionalities and a delayed delivery on a local project (run by a local subsidiary, outside the central IT team’s direct oversight). The project manager team had no process for managing local projects. They had no visibility on progress, no defined roles between the business and IT, and no way to follow delivery during the build.\nOne project manager audited the project value stream and recommended corrective actions. The project team then ran a workshop to define roles, responsibilities, and guidelines for local projects. They created a Local Project Implementation Checklist covering every phase from identification through roll-out: when to share guidelines, when to supply development environments, when to do mid-term code reviews, and what the definition of done looked like for each gate.\nThe project team did not resist defining the standard. They resisted the idea that they needed one. Local projects had always been “the business’s problem.” Once the client complaint made it clear that the central team’s reputation suffered regardless of who ran the project, they accepted ownership. The workshop produced the checklist in one day.\nThe standard was ready a few weeks later. The team applied it immediately to the next local project.\nThe Results Three months passed, and the same project team continued to manage their projects with the same vendors. The performance shifted across all three indicators: delivery, quality, and customer satisfaction. Delivery pace accelerated from 9 projects delivered in October to 27 by December.\nThe CIO came to the Obeya in late November with the division head. He walked the macro planning wall from left to right, stopped at two projects with overlapping milestones, and asked the team what they were doing about it. The project managers answered directly, pointing at the wall, no slides, no preparation. After the visit, the team stood a little taller. Leadership had seen their work, their problems, and their method for solving them.\nThe division head adopted the obeya as his primary management tool. Budget conversations became data-driven. Risk discussions focused on the wall rather than circling through opinions.\nBeyond the metrics, the Obeya changed how the team worked. Discussions moved from “I think we are on track” to “the wall shows we have three milestones colliding in the same week, so which one do we move?” Conversations about quality shifted from frustration to root-cause analysis. Project managers who had worked in isolation started solving problems together because they could see each other’s projects on the same wall. They started to learn.\nWhat Made It Work The Obeya did not add a process. It made existing problems visible so the team could solve them. It helps as a discovery tool for better risk management.\nThree things mattered. The handwritten charts on the wall, updated weekly, created accountability that no digital dashboard could match. When your numbers are on the wall, and the stakeholders see them every week, you do not let them slide.\nThe PDCAs forced the team to go beyond symptoms. ‘Deliveries are late’ is a complaint. “The test script does not list all required verification fields” is a root cause you can fix.\nAnd the macro planning wall gave the division head something he never had: a single view of every project with their real status, not the filtered version from a status report.\nIf you manage multiple IT projects and your delivery rate sits below 50%, the problem is rarely that your project managers lack skills. They lack visibility. An Obeya room gives them that visibility, and with it, the ability to act before problems become crises.\nDownload the Virtual Project Obeya Template to see the boards we used, with placeholder fields you can adapt to your own projects.\nGet the Full Project Obeya Template with all the boards layout: Strategy, performance, macro planning, and problem-solving. Ready to print and fill in.\n[Download Free Template →]\nThis case is drawn from a real engagement. The client, the project, and some figures have been anonymized or generalized to protect confidentiality. The methods, the sequence, and the outcomes are unchanged.\n","permalink":"https://leantechpro.com/project-obeya-room-case-study/","summary":"\u003cdiv class=\"key-takeaways\"\u003e\n\u003ch2 id=\"key-takeaways\"\u003eKEY TAKEAWAYS\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eA BI team managing nearly 20 projects across several continents built an Obeya room and doubled on-time delivery in 3 months.\u003c/li\u003e\n\u003cli\u003eThe Obeya surfaced milestone collisions, quality failures, and ownership gaps that no status report had ever shown.\u003c/li\u003e\n\u003cli\u003eThree PDCAs run inside the Obeya rescued a go-live, halved defects per delivery, and created a standard that the team still uses.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003cdiv class=\"key-takeaways\"\u003e\n\u003cp\u003eGet the Full Project Obeya Template with all the boards layout: Strategy, performance, macro planning, and problem-solving. Ready to print and fill in.\u003cbr\u003e\n\u003ca href=\"https://jlcossi.activehosted.com/f/77\" class=\"button primary\" target=\"_blank\"\u003e[Download Free Template →]\u003c/a\u003e\u003c/p\u003e\n\u003c/div\u003e","title":"From 24% to 55% On-Time Delivery: A Project Obeya Room Case Study"},{"content":" KEY TAKEAWAYS Lead time measures a process from start to finish, at any scope. Cycle time measures the duration of a recurring process. The scope you define determines which lead time or cycle time you measure. Define it explicitly, to have meaningful numbers for improvement leverage. High cycle time variability makes reliable delivery impossible. Reducing it is what turns a capable team into a predictable one. A product owner adds a feature request to the backlog. A developer picks it up 38 days later. He does the coding, then the testing, and pushes it to the deployment team. All that takes 7 more days. In the end, it takes the client 45 days to see anything.\nThe developer started a fresh story every four days, a four day cycle time per story. Yet the client waited 45 days. Both numbers describe durations within the same delivery, but they reveal completely different problems.\nLead time and cycle time are not the same metric. They answer different questions.\nWhat Is Lead Time? Considering a process, lead time is the duration from the beginning to the end. It includes all steps: waiting times, processing times, and any delays or bottlenecks along the way.\nIn software delivery, for example, lead time starts when a client or team submits a request and ends when that request is delivered. A DevOps team I worked with had a lead time of 64 days for infrastructure deployments. Those 64 days included active engineering work, but also included 31 days sitting in a single routing queue, 7 days lost because an engineer lacked admin rights, and 10 days of a security request bouncing between teams. All of it counts within the lead time. Lead time applies to any process, at any scope. You define the start and the end, and measure everything in between. The full request-to-delivery span is one scope. A single deployment pipeline is another. A code review handoff is another. DORA’s lead time for changes is simply lead time applied to one specific scope: from commit to production.\nWhat Is Cycle Time? Cycle time focuses on the duration of a specific recurring process. It measures the time from the start of one cycle to the beginning of the next. It includes active work time and any waiting periods before the next cycle begins.\nIn software delivery, for example, cycle time starts when a developer picks up a task and ends when they pick up the next one. Going back to the first example: the developer’s cycle time was four days per user story. That covered coding, internal testing, and deployment preparation. Four days, repeated across each story. It seems reasonable. But the client still waited 45 days, because that cycle time here does not capture what happens before and after the developer touches the work.\nThe key point in this example: a short cycle time within the process does not guarantee a short lead time from the client’s perspective.\nPractitioners often distinguish between actual cycle time and target cycle time. Actual cycle time reflects current performance, waste included. Target cycle time represents the desired goal. Working from actual cycle time matters because it shows you the real state of the process, not the ideal one. You cannot improve what you are not measuring honestly.\nLead Time vs Cycle Time: The Key Differences Why Both Metrics Matter Understanding and optimizing both lead time and cycle time can significantly improve an organization’s ability to meet client expectations, boost operational performance, and identify different areas for process improvement.\nBy focusing on these metrics, businesses can reduce overall delivery times, improve resource allocation, and enhance process predictability.\nAny lead time, whether end-to-end or at the subprocess level, is eventually felt by the client. A 64-day infrastructure lead time stalls development teams. A 45-day feature lead time frustrates the business. The client does not see your process; they only see the wait.\nCycle time matters because of variability. A team with an average cycle time of four days might have individual cycles ranging from one day to twelve. That spread makes planning impossible and delivery unpredictable. Reducing cycle time variability is what turns a capable team into a reliable one.\nHow to Measure Lead Time in Tech Lead Time = End Date – Start Date\nThe start and end points depend on the scope you define, but the formula stays the same.\nCalendar days, not working days.\nThis matters more than most teams think. A five-working-day estimate becomes a seven-calendar-day wait for the client. That gap compounds frustration, especially for urgent fixes.\nCounting calendar days also eliminates a common manipulation: teams artificially improving their numbers by starting work on Fridays or timing deployments to avoid weekends in the count. Calendar-based lead time closes that loophole.\nA feature sitting in a ready-to-deploy state over a weekend due to deployment restrictions shows up in the calendar lead time. In working-day tracking, that wait disappears.\nWhat to track:\nDate the request was logged (backlog entry, ticket creation) Date the work was delivered to production or the client. The difference in calendar days That is your lead time. Simple to calculate, but often uncomfortable to look at. That’s how you find improvement leverage.\nHow to Measure Cycle Time Cycle time requires you to define what one cycle is. That definition changes depending on what you are measuring.\nFor a developer processing user stories: cycle time starts when they pick up a story and ends when they pick up the next one.\nFor a deployment process: cycle time starts when a deployment request is submitted to the team and ends when the next deployment request is submitted.\nFor a support ticket team: cycle time starts when a technician claims a ticket and ends when they claim the next one.\nFor all three examples, the cycle time includes the time spent waiting before picking the next item to work on, the next user story, or a deployment or support ticket.\nOnce defined, collect the data across multiple cycles. You want to see the distribution. A team with an average cycle time of four days might have individual cycles ranging from one day to twelve. That variability is where the problems hide.\nCycle time formula:\nCycle Time = Time next cycle starts – Time this cycle started.\nYou can anchor this on the start of each cycle or on its completion, output to output. Either way, the interval is the same for a stable process. Pick one and stay with it.\nPlot it and look for the outliers. The spikes in cycle time point directly at your root causes.\nWhy Cycle Time Variability Is the Real Problem A cycle is a series of actions that repeat in the same order without interruption. Cycle time variability describes how much that duration fluctuates from one cycle to the next. Technically, it measures the difference between the actual cycle time and the average or expected duration. High variability makes planning impossible. If a team’s cycle time ranges from 1 day to 3 weeks, sprint commitments are unreliable.\nI use the 4M Framework to find the root causes of variability. The 4Ms are Man, Machine, Method, and Material.\nMan: Are the people doing the work well-trained? Did new team members get proper onboarding? One engineer I worked with had no admin rights to complete a critical configuration step. Seven days were lost while the tech lead was on vacation.\nMachine: Is the tooling working correctly? Is the infrastructure reliable? Dysfunctional deployment pipelines and unreliable test environments generate cycle time spikes that look like people problems.\nMethod: Is the process clearly documented? Does everyone follow the same steps? On that DevOps team, nobody had written down which ticket to create or where to route a security group request. Each engineer figured it out differently. Some got it wrong.\nMaterial: Are the inputs to the work correct and complete? Missing service account templates, wrong documentation, unclear requirements at handoff. These are material problems. They generate rework cycles that inflate both cycle time and lead time.\nThe 4M framework turns a vague “we have variability” observation into a specific list of root causes you can actually fix.\nReal Example: Reducing Lead Time From 64 to 29 Days The DevOps team I mentioned at the start did have a lead time problem. The deployment requests took 64 days on average. Development teams waited over two months for an environment, so projects stalled.\nA value stream mapping across all five teams involved in a single deployment revealed where the time actually went:\n31 days in one queue, because nobody knew which ticket type to create 7 days lost when a cloud engineer had no admin rights 4 days lost when a subnet was deleted due to an undocumented process change 10 days lost on a single security group request bouncing between teams The interventions we did were not complex. A deployment checklist, front-loaded service account requests, early handover meetings, documented routing for each request type, and an infrastructure-as-code pipeline.\nResult: 29 days. Down from 64. No new tools. No reorganization.\nThe full case study is here: How We Reduced DevOps Lead Time From 64 to 29 Days.\nReal Example: Reducing Cycle Time Variability in a Support Team A tech support team of 12 Level 1 technicians had a cycle-time issue. The average time to resolve a ticket appeared acceptable, but the variability in ticket processing cycle time was not.\nSome technicians closed three tickets a day. Others bounced between tickets and completed none by the end of the day. The range was so wide as to render any planning meaningless.\nDirect observation revealed the root causes. Technicians cherry-picked tickets without any systematic distribution. Assignments did not consider ticket complexity or technical competencies. Each technician maintained a local backlog, with no visibility into the team’s backlog. Only four of the twelve understood the service contract and SLA.\nUsing the 4M framework: the cherry-picking was a Method problem, the competency mismatch was a Man problem, the local backlogs were a Material problem, and the SLA gaps were a Method and Man problem combined.\nThe interventions targeted each root cause directly. A dispatcher role to route incoming tickets systematically, set daily productivity targets, conduct twice-daily check-ins, and provide real-time ticket flow visualization.\nWithin two months, the variability dropped. The team eliminated a 145-ticket backlog. The productivity rose 72%.\nThe full case study is here: A3 Problem Solving: A Complete Guide With Template and Examples.\nLead Time and DORA Metrics DORA (DevOps Research and Assessment) defines lead time for changes as the time from code commit to deployment in production. That is a lead time measurement, but at a specific scope: the development and deployment pipeline only.\nYour process end-to-end lead time and DORA’s lead time for changes measure different spans of the same delivery. A team can be DORA elite on commit-to-production and still have a 45-day process lead time, because the waste sits upstream: in the backlog, in planning, in the handoffs before a developer ever touches the work. The DORA scope will not surface that, but seeing the end-to-end process lead time will.\nThe DORA benchmark ranges for lead time for changes:\nElite: less than one hour High: one day to one week Medium: one week to one month Low: more than one month The DevOps team I worked with started at 64 days, so firmly low performer on that scale. After the interventions, 29 days moved them into medium performer range. Meaningful progress, with more room to go.\nKnowing where you stand on DORA benchmarks is useful. But also track your full process lead time. The two measurements together indicate whether your problem is within the pipeline or upstream of it.\nFrequently Asked Questions What scope should I use to measure lead time or cycle time?\nIt depends on the problem you are trying to solve. Lead time and cycle time apply to any process, regardless of scope. You define the start and end points, and the metric follows. A team that tracks end-to-end feature delivery and another that tracks commit-to-production both measure lead time, just at different scopes. Define your scope first, make it explicit, and keep it consistent. Comparing lead times across different scopes produces meaningless numbers.\nWhat is the difference between lead time and cycle time?\nLead time measures a process from start to finish, at whatever scope you define. Cycle time refers to a single recurring unit of work within a process. Typically, a long lead time can yield short cycle times when waste is in queues between stages.\nShould I measure in calendar days or working days?\nCalendar days. Your client experiences calendar time. A five-working-day promise is a seven-calendar-day wait. Calendar-based measurement also eliminates gaming and reveals weekend wait states that working-day metrics hide.\nMy cycle time is fine, but the end-to-end lead time is still long. Why?\nYour cycle time might be about one step of your end-to-end process. The cycle time that looks fine here tells you that the specific recurring unit or work you are watching is not your bottleneck. Map the full end-to-end lead time to find which stage is actually absorbing the time. The problem is in another cycle (for another working step), you are not yet measuring.\nWhat is a good lead time for a software team?\nIt all depends on the scope of the software development work you are considering. DORA classifies elite teams as those with code changes that take less than 1 hour to reach production. For infrastructure or feature delivery, context matters more than a benchmark. Start by consistently measuring your current lead time, then set a target based on your specific delivery chain.\n","permalink":"https://leantechpro.com/lead-time-vs-cycle-time/","summary":"\u003cdiv class=\"key-takeaways\"\u003e\n\u003ch2 id=\"key-takeaways\"\u003eKEY TAKEAWAYS\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eLead time measures a process from start to finish, at any scope. Cycle time measures the duration of a recurring process.\u003c/li\u003e\n\u003cli\u003eThe scope you define determines which lead time or cycle time you measure. Define it explicitly, to have meaningful numbers for improvement leverage.\u003c/li\u003e\n\u003cli\u003eHigh cycle time variability makes reliable delivery impossible. Reducing it is what turns a capable team into a predictable one.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003cp\u003eA product owner adds a feature request to the backlog. A developer picks it up 38 days later. He does the coding, then the testing, and pushes it to the deployment team. All that takes 7 more days. In the end, it takes the client 45 days to see anything.\u003c/p\u003e","title":"Lead Time vs Cycle Time: Complete Guide for Tech Teams"},{"content":" KEY TAKEAWAYS A DevOps team cut its infrastructure deployment lead time by more than half. The team followed Agile practices well. The blockers hid in cross-team handoffs where no ceremony could reach. Value stream mapping revealed about half the lead time lost in a single queue due to unclear routing and missing documentation. Simple interventions drove the result: checklists, front-loaded requests, early handovers. No new tools. No reorganization. The Problem A DevOps team at a large enterprise handled cloud infrastructure deployments. A small DevOps team, working across multiple projects, supported development teams who needed environments to build and test their applications.\nThe team ran Scrum. They had two-week sprints, daily standups, sprint planning, and retrospectives. They had a Scrum Master too. They tracked velocity, so they were basically following the framework.\nYet deployment requests took roughly two months on average. Development teams waited that long for an environment, so projects stalled. The DevOps team blamed external dependencies, including networking, security, and architecture validation.\nIn retrospectives, they discussed “improving communication with other teams” and “better planning.” Sprint after sprint, nothing changed.\nFor context on where this sits : the DORA framework classifies teams by lead time for changes. Elite teams measure it in hours. At that level, this team was firmly in the low-performer category.\nThe Performance Gap I started with the numbers. The business had a clear constraint: the infrastructure deployment lead time had to drop below 30 days to keep the entire deployment phase within 60 days. The current state: roughly two months, about double the target.\nThat gap meant development teams sat idle for weeks. Projects missed milestones. Frustration built across the organization. The cost was real. Every delayed deployment pushed back feature releases and burned budget on waiting.\nWhat Direct Observation Revealed I did not attend their Scrum ceremonies. I traced actual deployment requests through the system. I followed one specific deployment, from request to completion.\nThe process had multiple steps involving several teams. The DevOps team controlled only a portion of the work. The real problems I observed were not about coordination or communication. They were specific failures at specific points.\nHere is what I observed:\nA team member lacked the access rights needed to proceed. The only person who could grant them was unavailable. Days lost.\nA team unfamiliar with a recently introduced process inadvertently removed a resource, requiring re-validation from the architecture team. Days lost.\nNobody documented where to find entry points for key infrastructure requests. The team spent days figuring it out each time.\nRequests for access controls bounced between teams because neither side knew which ticket type to create or where to route it. Over a week lost on a single request.\nA document template for a critical provisioning step was wrong. Even the second version was incorrect. Nobody knew the correct process.\nTeams sometimes created the wrong resource type because the routing between cloud-based and legacy systems was unclear.\nNone of these problems surfaced in standups. None appeared on the visual board. The ceremonies captured “waiting on networking” as a blocker, but never revealed why.\nSix Root Causes I traced the deployment and found six root causes, none of them visible in a standup. They fell into four groups:\nAccess and permissions. Key team members were missing the access rights they needed, and only one person could grant them, who was unavailable. A process nobody knew. A team was unaware of a recently introduced infrastructure process, and that gap caused rework. No documentation, unclear routing. Nobody had documented the entry points for key infrastructure requests, and several teams were unclear on how to route access control requests. Wrong templates and resources. The template for a critical provisioning step was wrong, and so was the second version. Unclear routing between cloud-based and legacy systems also led teams to create the wrong resource type. Four groups, six root causes, all at the handoffs. That is where the time went.\nEach cause was verified. There was no guessing, no assumptions from retrospective discussions. This is how root cause analysis works when you go where the work happens, rather than discussing it in a meeting room.\nThe Value Stream Map The value stream told the story:\nAbout half the lead time disappeared in a single queue. Requests sat for weeks because teams did not know which ticket to create or where to route it (for task assignment to another team).\nThe visual board showed “in progress” and “blocked.” It did not show that requests bounced between teams, sat in the wrong queues, or waited because someone used the wrong template. The framework made work visible at the team level. It could not see the handoffs between teams, where most of the time vanished.\nThe Interventions Deployment checklist. The team created a checklist covering every request type, entry point, and routing decision. No more guessing about which ticket to create or which team to contact. Each step listed what to do and the entry point for each request.\nFront-loaded requests. They established a rule: start long-lead-time provisioning requests (such as access controls and service accounts) at the very beginning of deployment, rather than mid-process. Starting these requests early meant they could be completed in parallel with other work, rather than extending the critical path.\nInfrastructure-as-code pipeline. The team built a pipeline that could deploy resources identically across all environments. It is one pipeline, customizable per environment. This eliminated manual configuration errors and significantly reduced the “automate deployment” step.\nEarly handover meetings. They scheduled handover meetings with receiving teams before deployment completion, not after. This surfaced missing information while there was still time to act. Previously, handovers happened at the end, and missing service accounts or configuration issues caused delays of days.\nDocumentation. We documented the correct processes for provisioning requests, access control routing, and key infrastructure entry points. Simple, but it did not exist before.\nThe Results The deployment I traced: under 30 days. Down from about two months.\nThe team continued running Scrum. The ceremonies did not cause the problem, and stopping them was not the solution. But the improvement came from outside the framework: mapping the actual flow across teams, observing specific failures at specific points, identifying root causes through direct observation, implementing targeted fixes, and empowering the team.\nWhy Scrum Did Not Surface This The retrospectives had discussed “communication with other teams” for months. Direct observation revealed that the problem was not communication. It was: missing documentation, unclear routing, wrong templates, and sequential requests that could run in parallel. Those are solvable problems using a structured problem-solving approach. “Better communication” is not.\nScrum makes team-level work visible. It does well at that. But when the waste hides in the handoffs between multiple teams, no standup or retrospective will find it. You have to trace the actual work, end to end, through the system. That is what value stream mapping does. And that is what Lean Tech adds to teams that have already adopted Agile.\nI have seen this play out in every Agile team I have coached. The ceremonies run well, but the delivery still suffers. The system-level problems sit outside the team’s field of vision. I wrote about this dynamic here: The ‘Top Priority’ Problem: Why Engineering Teams Struggle With Delivery.\nHow This Connects to DORA Metrics This case study attacked lead time for changes directly. Roughly halving the lead time moved the team from a low performer to a medium performer on DORA benchmarks.\nThe interventions also created conditions for the other three metrics. Deployment frequency can increase when infrastructure provisioning no longer bottlenecks the pipeline. Change failure rate dropped because the infrastructure-as-code pipeline eliminated manual configuration errors. We had the same code, the same result, and the same across every environment. Mean time to recovery improved because documented processes and clear routing mean faster resolution when issues arise.\nLessons Learned Start deployment activities earlier. Request access controls and provisioning dependencies at the beginning, not when you need them. Long-lead-time dependencies should start first.\nDocument the handoffs. The work inside each team was reasonably efficient. The waste hid in the handoffs: wrong tickets, wrong queues, wrong templates. Document these explicitly.\nTrace real work, not process maps. The official process showed a handful of steps. Reality showed dozens of failure points within those steps. You only find these by following actual requests through the system.\nChecklists beat training. The teams knew their jobs. They failed at the boundaries because nobody documented what to do at each handoff. A checklist solved in days what “better communication” could not solve in months.\nMore than 50% lead time reduction. We had the same team, technology, and organizational structure. What changed was visibility into the actual flow and structured problem-solving aimed at specific failures.\n","permalink":"https://leantechpro.com/devops-lead-time-reduction-case-study/","summary":"\u003cdiv class=\"key-takeaways\"\u003e\n\u003ch2 id=\"key-takeaways\"\u003eKEY TAKEAWAYS\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eA DevOps team cut its infrastructure deployment lead time by more than half. The team followed Agile practices well. The blockers hid in cross-team handoffs where no ceremony could reach.\u003c/li\u003e\n\u003cli\u003eValue stream mapping revealed about half the lead time lost in a single queue due to unclear routing and missing documentation.\u003c/li\u003e\n\u003cli\u003eSimple interventions drove the result: checklists, front-loaded requests, early handovers. No new tools. No reorganization.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003ch2 id=\"the-problem\"\u003e\u003cstrong\u003eThe Problem\u003c/strong\u003e\u003c/h2\u003e\n\u003cp\u003eA DevOps team at a large enterprise handled cloud infrastructure deployments. A small DevOps team, working across multiple projects, supported development teams who needed environments to build and test their applications.\u003c/p\u003e","title":"How We Halved DevOps Deployment Lead Time"},{"content":"A financial software case study. How visual management, daily flash meetings, and team-led PDCAs replaced rework with ownership.\nKEY TAKEAWAYS A 15-person COBOL team at a financial institution reduced defects from 93 per month to 8 in two months. The team ran their own PDCAs using visual management and daily flash meetings. The method works the same for different tech teams: software development, testing, tech support, IT operations, and project delivery. Results from real coached teams: 91% defect reduction in financial software, 160% testing productivity gain, 94% backlog cleared in e-services support, 70% on-time resolution improvement in energy sector IT operations. Does Your Team Have the Same Problem? Take the 3-minute Delivery Scorecard to find out:\nWhere your delivery system breaks down Whether you’re fixing symptoms or root causes Your biggest improvement opportunity right now Find Your Team’s #1 Bottleneck (Free) →\nA 15-person COBOL team at a financial institution logged 93 defects in one month. Two months later, the number was 8. They got there with three practices: visual management, daily flash meetings, and team-led PDCAs. Here is how it happened.\nThe method comes from Toyota’s production system, adapted for tech work. I have used it for 15 years across banking, pharma, energy, IT services, and government agencies. The principles do not change with the stack. Start from what the customer experiences. Make problems visible. Go where the work happens. Build the team’s ability to solve problems. Measure before and after.\nInside the COBOL Team The team of fifteen developers built and maintained financial software in COBOL. When I arrived, the situation was clear: 93 defects logged in one month, zero milestones delivered on time, customer satisfaction sat at 7.7 out of 10, and was dropping.\nThe developers worked hard. Nobody questioned their effort, but the system around them produced defects faster than they could fix them. During the diagnostic phase, I noticed that the analyses were incomplete. Unit tests lacked realistic data. I also noted that when bugs surfaced, developers patched code that had already been patched by someone else. So, at the end, rework generated more rework.\nI started where Lean always starts: making the work visible. We built a visual management board that tracks every application design through the following specific flow: to-do (input), analysis, construction, unit tests, and migration. For the first time, the whole team could see where work piled up and where it stalled.\nWe introduced daily flash meetings. During fifteen minutes, the team stands in front of the board. They focused on what’s blocked, what moved, and what needs attention now.\nThen the team ran PDCAs. Marco led the first one: reduce defects by 50%. He collected actual defects and observed causes on the ground. Incorrect analyses accounted for 13 out of 25 sampled defects. Missing or poor unit tests caused another 4 defects. The team built countermeasures: intake reviews between analysts and developers before coding starts; a red bin system to flag bad analyses immediately; and a test plan requirement before any development begins.\nTom ran the second PDCA on unit test quality. He found that developers entered the project lifecycle too late. They never saw the data models or business requirements early enough to write meaningful tests. He fixed it by creating a developer checklist that requires access to user requirements, business examples, data models, and realistic test data before writing a single line of code.\nTwo months later, defects dropped from 93 to 8. Right-first-time fixes went from 9% to 100%. On-time delivery, which had been at 0, began to track upward.\nSomething shifted beyond the numbers. By month two, I stopped seeing fifteen individuals sitting in their corners across the open space. I saw a team. People walked to the visual board during the day, unprompted. They moved tasks, studied the flow, and asked questions to the person next to them. Handwritten PDCA sheets appeared on the wall, some still incomplete. Nobody told them to put those up. The team leader started updating KPIs on the board every morning. Everyone knew where the team stood before the flash meeting even started. The board became theirs. When management visited, I watched the developers walk their leaders through the tasks, the metrics, and the PDCAs in progress. They were not presenting to impress. They were explaining because they owned it. That ownership is the part no framework can install. It grows when people clearly see their own problems and build their own fixes.\nThe method did not depend on the technology stack. It was not specific to the type of team either. Teams change. The Lean principles do not. Make problems visible. Go where the work happens. Build the team’s capability to solve problems. Measure before and after.\nWhy Previous Attempts Failed Most tech leaders I work with have already tried two or three things before. But the delivery problems persisted. Here is why.\nAgile gives you rituals. Lean fixes the delivery system. With Scrum, SAFe, Kanban boards, and related practices, your team runs sprints, conducts retrospectives, and tracks velocity. You see ceremonies in action, but defects keep slipping through, and lead times stay flat. In the worst cases, I see retrospectives produce the same action items every month.\nAgile organizes how work moves through your team. It does not explain why defects occur or how to eliminate them. Lean does. There, you do PDCA on real defect data. You perform root cause analysis at the point where the problem occurs. That is the difference between talking about improvement and doing it.\nI wrote about this pattern in detail: When Agile Coaching Doesn’t Deliver.\nNew tools do not fix broken systems. You paid for Claude Code, Copilot, CI/CD pipelines, automated testing suites, observability platforms, and more. Your team adopted them, but the delivery speed did not change. Or it got faster in one area, only to create new bottlenecks elsewhere.\nTools accelerate what your system already does. If your system produces rework, tools help you produce rework faster. The COBOL team I coached did not need a new tool. They needed a checklist that required access to user requirements and realistic test data before writing code. Tom built that in week three. Defects dropped 91%.\nI wrote about this trap here: Your AI Tools Aren’t Delivering. The Problem Isn’t the Tools.\nConsultants deliver reports. I stay until results hold. A consulting firm runs interviews, writes a 60-page assessment, presents recommendations to leadership, and leaves. Six months later, nothing had changed. The report sits in a shared drive.\nI start by watching the team at work. The improvement levers you need are not in interviewing managers. They appear when observing how code moves from requirements to production: where it stalls, where rework occurs, and where people wait. Then the team builds the fix, changing the way they work. I coach while they own the outcome. I stay until the numbers prove it works.\nThree Practices Behind Every Result Every engagement I run uses the same three practices. The context may change, for example, banking, energy, government, testing, and technical support. The practices do not.\nVisual management: make the work visible. If the team cannot see where work piles up, they cannot fix it. I build visual management boards with every team I coach. It is a physical or digital board that tracks each piece of work through its actual flow, with clear signals when something stalls or fails.\nThe COBOL team tracked every application design through five stages: input, analysis, construction, unit tests, and migration. It was their specific work process. For the first time, the whole team could see where things broke. That visibility triggered the first PDCA within a week.\nLearn more about visual management in the full Obeya guide I wrote: What Is an Obeya Room?\nPDCA: structured problem-solving on real data. PDCA stands for Plan-Do-Check-Act. It sounds simple. Most teams skip the first step. They jump to solutions without diagnosing the root cause.\nMarco did not guess why the defect rate was high. He collected 25 defects and categorized them by root causes. Thirteen came from incomplete analyses. Four from missing test plans. He built countermeasures for each root cause and measured the result. That is PDCA. It is specific, measurable, and grounded in observation.\nFull guide here: The PDCA Cycle: A Complete Guide With Examples\nPull flow: stop pushing work, start pulling what matters now. Most teams push work through the system. Managers fill backlogs, assign tasks, and keep everyone busy. The result: 12 features in progress, none finished; developers context-switching between 3 projects; code sitting in review for days. Everything moves, but nothing ships.\nPull flow reverses that. The team works on one thing at a time, pulled by what the customer or the next step in the flow actually needs right now. When a developer finishes a task, he pulls the next highest-priority item instead of starting something new from a stacked backlog. The work-in-progress and lead time drop with it.\nThe e-services support team I coached had a drowning backlog because every request entered the system at the same priority. We capped work in progress and let the team pull tickets based on customer impact. Within three months, 94% of the backlog was cleared, and on-time resolution doubled from 40% to 68%. It was not by working harder. We just stopped the habit of starting everything and finishing nothing.\nResults From Real Teams I coached each of these teams. The numbers were measured on the ground within three months.\nDevOps infrastructure deployment. A small DevOps team deploying cloud environments for development teams. Requests took about two months. Their Scrum practices ran fine, but never surfaced the real blockers hiding in cross-team handoffs. Using value stream mapping, we found about half the lead time lost in a single queue. Checklists, front-loaded requests, and documented routing cut it to under 30 days. More than halved.\nTesting at Sopra Steria. A 15-person testing team kept flagging false defects. 44% of everything they flagged turned out wrong. Visual management, daily PDCA, and pull flow reduced it to 4%. The productivity jumped 160%.\nE-services support. Six people, drowning in a backlog. Within three months, 94% of it was cleared. Customer satisfaction rose 37%. On-time resolution doubled from 40% to 68%.\nEnergy sector IT operations. Nine technicians were stuck in reactive mode. On-time resolution improved 70%, and escalations dropped 45%. By the end, the team was preventing incidents instead of chasing them.\nEvery engagement started the same way. I went to the team, observed how the work actually moved. I highlighted the performance gaps and the improvement levers. Then I coached the team. Once the problems surfaced, the teams solved them correctly. And the method stayed after I left.\nHow We Work The generic consulting playbook runs in four phases: assess, pilot, scale, and sustain. You have seen it before. So, here is what actually happens when you work with me.\nDiagnose: 5 days, on-site, with the team.\nI do not start with interviews or surveys. I go where the work happens. I watch how code moves from requirement to production. I sit with testers, developers, and support agents. I map the actual flow. It is not a process documentation. By day five, I know where delivery breaks occur and why, which informs the improvement levers.\nWorkshop: the team designs the fix.\nI do not hand over a report with recommendations. I lead the team in identifying root causes from diagnostic data and building countermeasures. I teach them specific techniques. They own the solution because they built it. My role is to facilitate, challenge assumptions, and connect what I observed to what they experience daily. They grow by themselves.\nCoach: Stay until results hold.\nTypical engagement runs three months. I run weekly problem-solving sessions with the team. I transfer the methodology so they sustain it after I leave. The COBOL team ran their own PDCAs without me by month two. The Sopra Steria team continued improving after the engagement ended. When I leave, the numbers prove the fix works. Book a discovery call or take the free Delivery Scorecard.\nFrequently Asked Questions What ROI can I expect? Here are results from teams I coached. Every number was measured on the ground within three months.\nResults vary by team size, problem severity, and leadership engagement. Most teams see measurable improvement within the first month. The method works faster when leaders are involved throughout and conduct regular go-and-sees within their teams.\nHow does this work with existing Agile practices? Most of my clients already run some form of Agile. Sprints, standups, retrospectives. Lean management does not replace any of it.\nAgile organizes how work flows through the team. Lean gives the team a problem-solving system that makes those rituals produce results. When retrospectives keep surfacing the same issues, PDCA breaks the loop by forcing root cause analysis on real data. When sprint velocity looks fine but defects keep escaping, visual management makes the quality gap visible.\nOrganizations already practicing Agile often hit a plateau. Lean breaks through it by addressing system-level problems that no ceremony can fix on its own.\nWhere do these transformations fail? Three patterns kill most transformations before they start.\nFirst, leadership delegates without participating. The CIO approves the initiative, assigns it to a middle manager, and never shows up at the team areas where the work is happening. The team reads that signal clearly. If leadership does not care, why should they?\nSecond, teams focus on tools instead of behaviors. They install a Kanban board, set up dashboards, and automate reports. None of it changes how people solve problems. Visual management without problem-solving is decoration. Same for pull flow.\nThird, organizations try to scale before proving the method works. They roll out Lean across five teams before one team has a measurable result. Start with one team, one problem, one PDCA. Get the numbers. Then you expand.\nHow do I get started? Two paths.\nIf you know the delivery is broken, and you want it fixed, book a discovery call. It is thirty minutes. There is no pitch. We talk about what is happening in your team and whether I can help. If it fits, we start with a 5-day on-site diagnostic.\nIn case you are not sure yet, take the free Delivery Scorecard. It is ten questions, two minutes. It shows you where your delivery system breaks down. You will know immediately whether it is worth a conversation.\nThis is not a framework you adopt. It is a system your team builds. One problem at a time, one PDCA at a time, one measurable result at a time. The technology stack will change. The principles that make teams perform will not.\n","permalink":"https://leantechpro.com/cobol-defect-reduction-case-study/","summary":"\u003cp\u003eA financial software case study. How visual management, daily flash meetings, and team-led PDCAs replaced rework with ownership.\u003c/p\u003e\n\u003cdiv class=\"key-takeaways\"\u003e\n\u003ch2 id=\"key-takeaways\"\u003eKEY TAKEAWAYS\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eA 15-person COBOL team at a financial institution reduced defects from 93 per month to 8 in two months. The team ran their own PDCAs using visual management and daily flash meetings.\u003c/li\u003e\n\u003cli\u003eThe method works the same for different tech teams: software development, testing, tech support, IT operations, and project delivery.\u003c/li\u003e\n\u003cli\u003eResults from real coached teams: 91% defect reduction in financial software, 160% testing productivity gain, 94% backlog cleared in e-services support, 70% on-time resolution improvement in energy sector IT operations.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003cdiv class=\"key-takeaways\"\u003e\n\u003ch3 id=\"does-your-team-have-the-same-problem\"\u003e\u003cstrong\u003eDoes Your Team Have the Same Problem?\u003c/strong\u003e\u003c/h3\u003e\n\u003cp\u003eTake the 3-minute Delivery Scorecard to find out:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eWhere your delivery system breaks down\u003c/li\u003e\n\u003cli\u003eWhether you’re fixing symptoms or root causes\u003c/li\u003e\n\u003cli\u003eYour biggest improvement opportunity right now\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://jlcossi.activehosted.com/f/59\" class=\"button primary\"\u003eFind Your Team’s #1 Bottleneck (Free) →\u003c/a\u003e\u003c/strong\u003e\u003c/p\u003e\n\u003c/div\u003e","title":"How a 15-Person COBOL Team Cut Defects 91% in 60 Days"},{"content":" KEY TAKEAWAYS If your sprint velocity looks fine but features keep slipping, the problem is invisible to any dashboard you have access to. A non-technical founder can assess engineering health without reading code. You just need to know which signals to look for. The most expensive engineering teams are often the quietest ones. Silence is not a good sign. Not sure your engineering team is performing? Book a free 30-min call. I’ll tell you exactly what to look for.\nBook a Free Call\nYou are spending $20,000 a month on engineers. Maybe more. The Jira board shows tickets moving. The weekly standup runs smoothly. Your lead developer says everything is “on track.”\nAnd yet the feature your sales team promised a client three months ago is still not live.\nThis is the black box problem. You cannot read the code or assess architecture quality. Instead, you trust the process, trust the people, and wait.\nMost non-technical founders I work with are in this situation. They are not asking questions because they don’t know which ones will help.\nThis article gives you those questions. No coding required.\nThe Black Box Problem I have walked into many engineering teams that looked fine from the outside. The developers seemed busy, but six months later, the team still had not shipped the feature the CEO promised at the last board meeting.\nSurface signals lie. A busy-looking team can be completely stuck, and a calm team can be shipping clean work every single week. Ticket counts tell you nothing about code quality. Sprint velocity tells you nothing about whether your architecture holds when you hit 500 paying users.\nWhat actually tells you something is behavior. The things your team does and says when no one prepared the narrative in advance.\nA Team That Looked Fine The CEO had numbers. Client satisfaction is at 7.7 out of 10. Developers are busy every sprint. A team lead who answered every question with confidence.\nWhat he lacked was delivery. Every single development request that quarter came in late. When I went inside, the picture was different. Bug correction lead times ranged from 2 days to 194 days on the same team, for the same type of defect. Only 2 out of 10 fixes were done right the first time. The other 8 went back into the cycle, retested, reassigned, reexplained. The analysis documents were sitting in the team lead’s inbox for up to 11 days before anyone touched them.\nThere was a third problem, quieter than the other two. The engineers who flagged issues during testing were ignored. It was not deliberate. The process simply had no place for their input. By the time a defect reached a developer, the context was gone. The requirements were misread, and the fix was wrong before anyone wrote a line of code.\nThe team was not slow; the system was broken. Nobody had told the CEO because nobody inside could see it clearly enough to name it.\nThat is the black box problem.\nThe Warning Signs 1. Every estimate is wrong in the same direction Estimates being off is normal. Software is sometimes uncertain. But if your team consistently underestimates by 2x or 3x, in every sprint, for months, there is a system problem. Either the team does not understand the codebase well enough to estimate, or there is a hidden technical debt, quietly eating up 40% of every sprint. Ask your lead one question: how much of last quarter’s capacity went to unplanned work? If the answer takes time, you already have your answer.\n2. Bug fixes take longer than new features This one is counterintuitive because new features are complex. Everyone assumes fixes are fast, but they are not when the codebase is fragile. When fixing one thing routinely breaks two others, your architecture is already compromised. Engineers call this “tight coupling.” You will experience it as an endless cycle of regressions, hotfixes, and “we thought we fixed that” conversations.\n3. Your team avoids talking about the past Pay attention in meetings. Healthy teams reference past work freely. They say, “We built this six months ago; we can extend it.” Struggling teams avoid the past. They talk in circles about what to build next, never grounding the conversation in what already exists. That avoidance is often shame, or fear, or both.\n4. New engineers take months to become productive A well-structured codebase with decent documentation gets a new developer shipping within two to four weeks. If your team tells you it takes three months to onboard someone, your codebase is a labyrinth. No one wrote anything down. The knowledge resides in the heads of one or two people. That is a fragility risk, not just a speed problem.\n5. The answer to “why is this taking so long?” is always technical Technical reasons for delays may be true. But if you never hear scope misjudgments or shifting priorities, you aren’t getting the full story. Encourage business-focused translations from your team.\nNoise, Pattern, Problem Generally, one incident means nothing. Software development can be messy. For example, estimates slip, and a sprint goes sideways. These things happen in every team, including the good ones.\nWatch for repetition. If the same signal shows up three weeks in a row, something is wrong with the system. Two signals at the same time means you have a real conversation to initiate, deliberately, not in a corridor between two meetings. If there are three or more issues simultaneously, you are looking at a structural problem, and it is already costing you more than you think. They will not resolve on their own. I have been in that room.\nYou do not need certainty before acting. Stop explaining away what you are seeing.\nWhat Good Actually Looks Like 1. They push back on your feature requests This is the one that surprises founders most. A healthy engineering team says no, or “not like that.” They ask why before they ask how. They raise concerns about scope, about dependencies, about things you did not think to think about. A team that says yes to everything is not agreeable. They are disengaged, or afraid, or both.\n2. They can explain what they built last month in one sentence Ask your lead developer, “What did the team ship in the last four weeks? One sentence.” A healthy team provides clear and precise business-oriented answers. Otherwise, vague responses mean the team lacks direction.\n3. Production incidents are rare, and post-mortems happen Every team ships bugs. What matters is the response. Healthy teams hold post-mortems to learn, not blame. Treating incidents as exceptions leads to repeats.\n4. They talk about users I have worked with dozens of engineering teams. The ones that move fast and build the right things talk about users constantly. “What does the user actually need here?” “Have we tested this with a real user?” When engineers are disconnected from the people using the product, they optimize for the wrong things. Clever architecture. Interesting technical problems. Not user outcomes.\n5. They say “I don’t know” without panic Healthy engineers are comfortable with uncertainty. When you ask a question they cannot answer, they say so, and they tell you how they will find out. A team that always has an immediate answer to every question is either performing with confidence or not thinking hard enough about the problem.\nThe One Conversation to Have This Week Pick one metric your engineering team tracks. Velocity, cycle time, deployment frequency, whatever is available for you. Ask your lead two questions.\nFirst: “What does this number mean for the business?” Not for the team. For the business.\nSecond: “What would make this number worse next quarter?”\nThe quality of those answers will tell you more about your team’s health than six months of standup notes. A team that can connect its technical metrics to business outcomes understands what it is building. A team that answers with technical jargon and shrugs at the business question has a communication problem at minimum, and possibly an alignment problem.\nYou do not need to understand the metric to evaluate the answer.\nWhen the System Evaluates Itself The conversation in the section above assumes something important: the person you are asking can give you a straight answer.\nThat is not always true. If your lead developer is the one managing estimates badly, asking him to self-assess produces theater. I have sat in those conversations, and I walked out feeling reassured. Nothing changed.\nA CTO does not solve this automatically. He is a translation layer between you and the team. When that layer is honest and sharp, it is worth every euro. When it is not, you have the most expensive blind spot in your company. Most technical leads are not lying. They manage up, they protect their team, and because of that, they genuinely cannot see what is right in front of them. People inside a broken system rarely see it clearly. That is not a character flaw. It is just how systems work.\nThere is a point where the internal conversation stops producing useful information. You are asking the system to evaluate itself.\nWhen You Need Outside Eyes Three situations make this urgent. You are about to raise a Series A, and investors will run technical due diligence.\nYour CTO just resigned, and you need to understand what they left behind. You have been scaling the team for six months, and delivery has gotten slower, not faster.\nIn those situations, you need someone who can go inside the codebase, not just observe behavior from the outside. Someone who speaks both languages: technical enough to see what is actually there, and business-minded enough to tell you what it means for your roadmap, your team, and your investors.\nThat is when you need an outside diagnostic. Someone who comes in, observes the team, measures the delivery data, and gives you a clear picture in language you can act on.\nIn practice, that means looking at how your team actually works. It is not how it reports. How long does a fix take from the moment it is identified to the moment it is live? Where does work pile up? Who holds knowledge that no one else has? The output is not a list of technical recommendations. It is a business picture: what is slowing you down, what it is costing you, and what to address first.\nThe team from earlier in this article is a good example. Ninety-two defects per month, zero on-time deliveries, 80% of fixes done wrong the first time. Three months after the diagnostic, defect volume was falling, the NRFT rate had dropped significantly, and the team had its first on-time deliveries. No new engineers. No new tools. The same people, working inside a system they could finally see clearly.\nNot every team needs one. But if you have been running on gut feel for more than six months, and you cannot confidently answer “is my team performing?”, the cost of not knowing is probably higher than the cost of finding out.\nFrequently Asked Questions Can I run this assessment myself? Partly. Every signal in this article is visible without technical knowledge. To notice that estimates are always wrong in the same direction, you do not need to read code. Same, to see that your team goes quiet when you ask about the past six months.\nBut there is a ceiling. You can see that features are slow. But you cannot see why. Is it one fragile module? Two years of accumulated debt? An architecture that will hold for now but crack the moment you hit 2,000 users? Those distinctions change every decision you make for the next two quarters. From the outside, they are invisible.\nI have worked with founders who spent six months convinced their team had a motivation problem. The real issue was an architecture decision made two years earlier by a developer who had since left. No behavioral signal points clearly at that. You see the symptoms. The cause stays hidden.\nMy team is offshore. Does any of this still apply? Yes, and the gap between what you are told and the reality tends to be wider.\nOffshore teams add distance, making behavioral signals harder to detect. Time zones compress communications. In some team cultures, engineers simply do not surface problems to their supervisors. It is not because they are hiding something. It is not how they were trained to work. I have seen founders spend eight months reassured by weekly status updates while the codebase was quietly becoming unmaintainable.\nThe warning signs are the same. They are just easier to miss.\nHow do I know if things are really that bad? Founders who are confident in their team do not usually read articles like this one.\nIf you finished this article and nodded at two or three warning signs, that is already your answer. You have enough to stop waiting and start looking.\nI have a CTO. Does this article still apply to me? Yes. And the question is worth asking clearly.\nA CTO gives you a translator. He does not give you independent visibility. If your CTO is the one setting estimates, making hiring calls, and choosing the architecture, you have no outside reference point to assess whether those decisions are sound. Most founders with a CTO feel more reassured. That is not the same as being better informed.\nThe signals in this article apply whether you have a CTO or not. What you are looking for is the gap between what you are told and what is actually happening. A CTO can close that gap, or widen it.\nWhat actually happens during a diagnostic? I come in and look at how work actually moves through your team, from the moment a feature is requested to the moment it is live. I observe the team at work. I measure delivery data: cycle times, handoffs, rework rates, where work piles up, where context gets lost between people.\nI am not collecting your team’s self-assessment. I am watching what really happens. The output is a live dashboard with baseline metrics, a clear picture of what is slowing delivery down, and why. Then, I create a tailored workshop plan so your team can design the fix themselves.\nThere is no slide deck. Only a dashboard you keep, and a team that understands its own system for the first time.\nMy team is early. Is it too soon for a diagnostic? It depends on one thing: are you already spending more than €15,000 a month on development?\nIf yes, you are past the point where gut feel is free. Every month you run without visibility, decisions accumulate on top of each other. By the time delivery slows down or investors start asking hard questions, those decisions are already baked in. A diagnostic at this stage is cheap compared to six months of compounding problems you cannot see.\nIf you are pre-product or have fewer than five developers, the behavioral signals in this article are enough for now. Start with the conversation I described above: one metric, two questions. Then come back when you are scaling and the answers stop making sense.\nI help non-technical founders understand what is really happening inside their engineering teams. If you are spending more than €15,000 a month on development and cannot clearly answer whether it is working, book a free 30-minute call. I’ll tell you exactly what to look for.\n","permalink":"https://leantechpro.com/engineering-team-performance-non-technical-founder/","summary":"\u003cdiv class=\"key-takeaways\"\u003e\n\u003ch2 id=\"key-takeaways\"\u003eKEY TAKEAWAYS\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eIf your sprint velocity looks fine but features keep slipping, the problem is invisible to any dashboard you have access to.\u003c/li\u003e\n\u003cli\u003eA non-technical founder can assess engineering health without reading code. You just need to know which signals to look for.\u003c/li\u003e\n\u003cli\u003eThe most expensive engineering teams are often the quietest ones. Silence is not a good sign.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003cdiv class=\"key-takeaways\"\u003e\n\u003cp\u003e\u003cstrong\u003eNot sure your engineering team is performing? Book a free 30-min call. I’ll tell you exactly what to look for.\u003cbr\u003e\n\u003ca href=\"https://cal.com/jlcossi/leantechpro-discovery-call\" class=\"button primary\" target=\"_blank\"\u003eBook a Free Call\u003c/a\u003e\u003c/strong\u003e\u003c/p\u003e\n\u003c/div\u003e","title":"Engineering Team Performance: A Non-Technical Founder’s Guide"},{"content":" KEY TAKEAWAYS AI tools made your developers faster. Your delivery system wasn’t built to absorb that speed. The bottleneck moved from writing code to reviewing it, and most teams haven’t noticed. You don’t need new tools. You need to redesign the system around the ones you have. Before you read on: I built a free diagnostic guide that covers everything in this article as a step-by-step framework. If you’d rather act than read, start there.\nGet the Free Diagnostic Guide\nSix months ago, you rolled out both Claude Code and Cursor across your engineering team. Developers started producing code faster, and the Pull request volume went up. For a few weeks, it looked like your investment was paying off.\nThen your last three releases shipped late.\nLooking closer, pull requests pile up waiting for review. Code that looked fine at review breaks weeks later. The team goes back to fix what they thought was done. Your senior engineers spend half their day reviewing AI-generated pull requests instead of building. Nothing is wrong with the tools. The problem is everywhere else.\nYou are not the only one seeing this. I wrote this for CTO and engineering leaders who approved the AI investment and now need to explain why delivery didn’t improve.\nI fix delivery systems. I have done it for 15 years. Here is the pattern I see now: teams adopt AI coding tools, and delivery gets worse most of the time. The tools do what they promise. The problem is that everything around them stayed the same.\nFaster Code, Slower Releases The 2025 DORA Report explains that teams that adopted AI tools are shipping more frequently, but they are also shipping less stable software. More of what they ship breaks. If you only look at the code production speed, you think everything is fine. DORA’s conclusion says it plainly: successful AI adoption is a systems problem, not a tools problem.\nI see the same thing in the Faros AI Productivity Paradox report, which tracked 10,000 developers across 1,255 teams. Developers using AI produce 21% more tasks and 98% more pull requests. But the time spent reviewing pull requests jumped by 91%. It means that the code is coming in faster than anyone can check it.\nPR size went up 154% on average. But pull requests take longer to review and pose greater risk when merged. They also go against everything we know about small batches and delivery stability.\nOpenAI’s own numbers show where this ends. Nearly every engineer there uses Codex and merges 70 percent more pull requests each week. Human review could not absorb that volume, so the agent itself now reviews almost every PR before a person sees it. Even the company that builds the tool had to rebuild its review step around the new speed. Most teams adopted the speed and skipped that part.\nAI Creates Five New Forms of Waste The traditional delivery metrics miss AI-specific waste. Here are five patterns from teams that adopted AI tools without redesigning their workflow.\nRework from hallucinated code. AI generates plausible-looking code that passes initial review. But two sprints later, the team discovers edge cases that the AI didn’t handle. The fix costs more than writing it from scratch would have.\nReview bottleneck inflation. Your senior engineers come from reviewing a normal amount of PRs to three times that volume. They can’t keep up, so reviews get rushed, and bugs get through. Nobody thought to add more reviewers or change the way of working.\nDuplicate and conflicting tests. AI test case generators can easily generate hundreds of tests. Many overlap. Some even contradict each other. As a result, the test suite’s runtime doubles. The team spends more time maintaining AI-generated tests than the tests actually save.\nFalse confidence in coverage. AI tools report high code coverage numbers. Managers see 90%+ coverage and assume quality improved. But AI-generated tests often cover trivial paths while missing critical business logic. So, coverage went up, and quality didn’t.\nContext switching between AI tools. 89% of engineers say jumping between tools disrupts their workflow. Think about it: your team might be running Copilot for code, a separate tool for reviews, another one for tests, and something else for ticket triage. Each one comes with a different interface, and your engineers have to validate the output from all of them.\nWhy Traditional Metrics Don’t Catch This Your sprint velocity looks fine. The deployment frequency might even be up, and the dashboard is green across the board.\nThe point is that your current metrics were built before AI, and don’t catch what AI breaks. The velocity measures effort, not outcome. The deployment frequency is how often you ship, not whether you shipped the right thing with acceptable quality. So, these metrics were designed for human-only teams. That is the reason why they don’t capture AI-specific failure modes.\nThere are also two different clocks, and most dashboards only show one. Cycle time is how fast your team moves an item through its own process. Lead time is how long the customer waits, from request to delivery. AI improves the first clock, most of the time. The customer only feels the second.\nI once mapped a request that a team finished in four working days. The customer waited forty-five. The other forty-one days, the request sat in queues. The team’s board was green the entire time.\nAccording to McKinsey, only 39% of organizations report any financial impact from AI at the enterprise level. The rest invested but can’t point to a business result.\nThe Root Cause Is System Design Your delivery system was designed for the following process: humans writing code, reviewing, writing tests, and triaging bugs. You added AI to each step but kept the same handoffs, review gates, capacity planning, and metrics.\nAI doesn’t replace steps in your delivery pipeline. In fact, it changes the ratio between steps. Code generation got 10x faster. Code review didn’t. Testing capacity didn’t scale. The deployment risk assessment didn’t adapt.\nWhen one part of a system speeds up, and the rest doesn’t, work piles up at the constraint. Your AI investment increased the rate of input into the same bottleneck. The system tells you this through late deliveries, growing review queues, and increasing rework, but only if you know where to look.\nWhat to Fix First There is no need to rip out your AI tools. You need to redesign the system around them.\nMeasure AI-specific metrics. Start by tracking rework caused by AI-generated code separately from human-authored rework. Then, measure review queue depth and wait time. Calculate the real cost per AI tool. Compare it to measurable delivery gains.\nRebalance capacity at the constraint. If code review is the bottleneck, invest there, whether that means more reviewers, better AI-assisted review tools, or smaller PR size limits that keep batches reviewable.\nThis rebalancing is now visible at the market level. Anthropic shipped a multi-agent code review tool in March 2026 to check the flood of AI-generated code. HubSpot built Sidekick, a multi-model review agent, after six months of iteration on its own pipeline. Augment’s Intent splits the work across coordinator, implementor, and verifier agents. The pattern is identical everywhere: machines absorb pattern recognition and verification, and the human layer concentrates on judgment, what is needed, what fits, what is worth the cost. The review bottleneck is not being eliminated. It is being clarified down to the part that cannot be automated, and allocating that judgment is a system-design question, not a tooling one.\nSet AI output quality gates. Don’t let AI-generated code bypass the standards you’d apply to human code. Define acceptance criteria for AI output that include edge case coverage.\nRedesign handoffs for “human + AI” work. Here is where I start when working with a team: map your delivery flow end to end. Identify every point where AI output feeds into a human step. Then, ask: Did we adjust capacity, expectations, and quality checks to accommodate the increased volume?\nThe AI Delivery Audit Every CTO I talk to bought AI tools expecting faster delivery. At the time to prove the tools delivered on that promise, difficulties appear. Many can’t even measure it.\nThe problem is treating AI as a drop-in upgrade when it actually changes how your entire delivery system operates.\nIf you can’t answer “Are my AI tools making delivery faster or slower?” in 30 seconds with real numbers, you have a measurement gap. And that gap is costing you in delayed releases, wasted AI spend, and frustrated engineering teams.\nI built a free scorecard that helps you identify where your delivery system breaks down. Ten questions, for two minutes. You’ll know exactly where to look.\n→ Take the Free Delivery Scorecard\n→ Download the full diagnostic framework: 7 Questions Every CTO Should Ask About AI and Delivery\n","permalink":"https://leantechpro.com/ai-tools-not-delivering/","summary":"\u003cdiv class=\"key-takeaways\"\u003e\n\u003ch2 id=\"key-takeaways\"\u003eKEY TAKEAWAYS\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eAI tools made your developers faster. Your delivery system wasn’t built to absorb that speed.\u003c/li\u003e\n\u003cli\u003eThe bottleneck moved from writing code to reviewing it, and most teams haven’t noticed.\u003c/li\u003e\n\u003cli\u003eYou don’t need new tools. You need to redesign the system around the ones you have.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003cdiv class=\"key-takeaways\"\u003e\n\u003cp\u003e\u003cstrong\u003eBefore you read on: I built a free diagnostic guide that covers everything in this article as a step-by-step framework. If you’d rather act than read, start there.\u003cbr\u003e\n\u003ca href=\"https://jlcossi.activehosted.com/f/69\" class=\"button primary\" target=\"_blank\"\u003eGet the Free Diagnostic Guide\u003c/a\u003e\u003c/strong\u003e\u003c/p\u003e\n\u003c/div\u003e","title":"Your AI Tools Aren’t Delivering. The Problem Isn’t the Tools"},{"content":" Free Guide · AI \u0026amp; Delivery Performance\nIs Your Tech Delivery System Ready for the AI Era? 7 diagnostic questions every CTO should ask right now, with the data, the blind spots, and a scoring framework to find where your delivery breaks down.\nWhat’s inside the guide\nA 12-page diagnostic framework built for engineering leaders managing AI-augmented teams 📊\nThe AI Delivery Paradox DORA 2025: 90% of tech professionals now use AI at work and over 80% say it made them more productive. Delivery instability rose too. Adoption went up; the system underneath did not change.\n🔍\n7 Diagnostic Questions Each question targets a specific blind spot in your delivery system. Red flag indicators tell you if you have the problem.\n📈\nThe Measurement Gap What your current metrics measure vs. what you’re missing. Five AI-specific metrics your DORA dashboard won’t show you.\n🎯\nScoring Framework Rate your delivery system across all 7 dimensions. Know exactly where to focus first, before spending another euro on AI tools.\nBuilt for engineering leaders who: ✓Adopted AI coding tools but can’t prove delivery improved\n✓Face board or CFO questions about AI tool ROI\n✓See developers working faster but releases still shipping late\n✓Suspect their delivery metrics miss AI-specific problems\nGet the Free Guide. 12 pages. 10-minute read. You’ll know exactly where your AI-era delivery system breaks down.\nDownload the Free Guide →\nNo spam. Unsubscribe anytime. Your email stays with us.\nAbout the author\nJean-Luc COSSI — AI Adoption \u0026amp; Delivery Transformation Director. 15+ years diagnosing and fixing delivery performance inside tech teams across Europe, Africa and Asia. MBA ESSEC.\nMichelin BNP Paribas Sopra Steria Sodexo Docaposte\nNot ready for the guide yet? Take the 2-minute delivery scorecard instead. 10 questions. Instant results.\nTake the Free Scorecard →\n","permalink":"https://leantechpro.com/ai-delivery-guide/","summary":"\u003cdiv class=\"section hp-hero\" style=\"text-align: left; padding: 80px 24px 60px;\"\u003e\n\u003cdiv style=\"max-width: 720px; margin: 0 auto;\"\u003e\n\u003cdiv class=\"hp-hero-label hp-fade\"\u003e\n\u003cp\u003eFree Guide · AI \u0026amp; Delivery Performance\u003c/p\u003e\n\u003c/div\u003e\n\u003ch1 id=\"is-your-tech-delivery-system-ready-for-the-ai-era\"\u003eIs Your Tech Delivery System Ready for the AI Era?\u003c/h1\u003e\n\u003cp\u003e7 diagnostic questions every CTO should ask right now, with the data, the blind spots, and a scoring framework to find where your delivery breaks down.\u003c/p\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003cdiv class=\"section\" style=\"padding: 60px 24px; max-width: 720px; margin: 0 auto;\"\u003e\n\u003cdiv class=\"hp-section-label\"\u003e\n\u003cp\u003eWhat’s inside the guide\u003c/p\u003e\n\u003c/div\u003e\n\u003ch2 id=\"a-12-page-diagnostic-framework-built-for-engineering-leaders-managing-ai-augmented-teams\"\u003eA 12-page diagnostic framework built for engineering leaders managing AI-augmented teams\u003c/h2\u003e\n\u003cdiv style=\"display: grid; grid-template-columns: 1fr 1fr; gap: 20px; margin-bottom: 40px;\"\u003e\n\u003cdiv class=\"deliverable-card\"\u003e\n\u003cdiv class=\"deliverable-icon\"\u003e\n\u003cp\u003e📊\u003c/p\u003e\n\u003c/div\u003e\n\u003ch3 id=\"the-ai-delivery-paradox\"\u003eThe AI Delivery Paradox\u003c/h3\u003e\n\u003cp\u003eDORA 2025: 90% of tech professionals now use AI at work and over 80% say it made them more productive. Delivery instability rose too. Adoption went up; the system underneath did not change.\u003c/p\u003e\n\u003c/div\u003e\n\u003cdiv class=\"deliverable-card\"\u003e\n\u003cdiv class=\"deliverable-icon\"\u003e\n\u003cp\u003e🔍\u003c/p\u003e\n\u003c/div\u003e\n\u003ch3 id=\"7-diagnostic-questions\"\u003e7 Diagnostic Questions\u003c/h3\u003e\n\u003cp\u003eEach question targets a specific blind spot in your delivery system. Red flag indicators tell you if you have the problem.\u003c/p\u003e\n\u003c/div\u003e\n\u003cdiv class=\"deliverable-card\"\u003e\n\u003cdiv class=\"deliverable-icon\"\u003e\n\u003cp\u003e📈\u003c/p\u003e\n\u003c/div\u003e\n\u003ch3 id=\"the-measurement-gap\"\u003eThe Measurement Gap\u003c/h3\u003e\n\u003cp\u003eWhat your current metrics measure vs. what you’re missing. Five AI-specific metrics your DORA dashboard won’t show you.\u003c/p\u003e\n\u003c/div\u003e\n\u003cdiv class=\"deliverable-card\"\u003e\n\u003cdiv class=\"deliverable-icon\"\u003e\n\u003cp\u003e🎯\u003c/p\u003e\n\u003c/div\u003e\n\u003ch3 id=\"scoring-framework\"\u003eScoring Framework\u003c/h3\u003e\n\u003cp\u003eRate your delivery system across all 7 dimensions. Know exactly where to focus first, before spending another euro on AI tools.\u003c/p\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003c/div\u003e","title":"AI Delivery Guide"},{"content":" KEY TAKEAWAYS A 13-person billing test team increased productivity by 24% in three months by making work visible, setting daily targets, and solving problems one at a time with PDCA. Diagnostic before action: observing testers at their workstations revealed hidden waste like seven help requests in three hours, repeated tests without conclusions, and two-hour solo investigations. When the project manager changed mid-project, the new manager walked into a team that ran itself. Visual boards, tracked indicators, and clear action plans made the transition seamless. Get the Lean Testing Quick-Start Kit. 4 practices, real results, a two-week plan to start Monday.\nGet the Kit →\nThirteen testers worked across two sites, a main one and a smaller offshore team. They validated billing scenarios before each production release: invoice generation paths and migration batches.\nThe client had complaints. Tests started too slowly at the beginning of each phase. Nobody could see what was happening with billing tests on a day-to-day basis. The client kept asking for more tester autonomy and felt like he was repeating himself.\nDiagnostic Before Action Before starting this Lean Testing transformation, I spent time collecting data and observing the team at work. I interviewed the client, measured current performance, and watched testers at their workstations. This phase produced a report including baseline numbers and targets.\nWhat the Data Showed Customer satisfaction sat at 6 out of 10. The team validated 0.37 billing scenarios per person per day. And 15% of the defects they reported turned out to be false alarms or got assigned to the wrong team. That last number caused friction among developers and ate up everyone’s time.\nThe manager saw something else, too. Two or three testers held critical knowledge, and if one got sick during a release, the whole thing could collapse.\nWhat I Saw at the Workstations One observation session caught a tester asking colleagues for help seven times in three hours. Another showed someone running the same test multiple times, getting the same result each time, but not concluding. A third revealed two-hour investigation sessions before anyone thought to escalate or open a defect.\nTechnical environment incidents piled up, too. Dozens in a single month, right at the start of a release phase. The billing cycle kept failing with cryptic errors. Nobody had told the testers that an internal project somewhere else had been cancelled, leaving orphan data in the system that broke their test runs.\nTesters put in effort, but much of it went into rework, waiting, or solving problems alone that the team could have fixed together in minutes.\nThree Days to Build the Action Plan I brought a few testers into a three-day workshop while the others stayed on production to keep deliveries running. At the end, they presented their findings to their colleagues, so everyone could learn and contribute to the final action plan.\nFirst, I taught them the Voice of Client as a lean technique and how to collect it. I shared the customer satisfaction I collected. They drafted a questionnaire to systematically collect clients’ feedback.\nThat first day, testers also observed their own process. They watched colleagues execute tests, write defect reports, and handle blockers. They timed activities. They counted interruptions. By the end of the day, they saw problems they had stopped noticing.\nI then taught specific Lean techniques matched to what we had found during the diagnostic. Waste identification: spotting rework, waiting, and handoffs that add no value. Quality management: understanding why defects get rejected and how to prevent false reports. Pull flow: setting daily targets backwards from delivery dates. Visual management: making work status visible to everyone at a glance. PDCA: a structured way to solve problems one by one. Performance indicators: measuring what matters daily, not monthly.\nTesters applied each technique to their real work during the workshop. They analyzed actual defects from the current release. They mapped their actual test execution flow. They also calculated their actual productivity gaps.\nBy the third day, the team had built its own action plan. I was acting as a Coach so it was not something I handed them. They had identified what to change, how to measure progress, and who would do what. They presented the plan to their manager, including the rest of the team, and committed to starting immediately.\nVisual Board, Daily Targets, Pull Flow The team started with a visual management board on the wall. It showed every test scenario moving through stages: backlog, design, execution, and done. Anyone walking by could see what was stuck and what was flowing, in real time.\nEvery morning, the team held a 15-minute flash meeting. They go through: yesterday’s results, today’s targets, and problems blocking progress. The team leader assigned work based on what the board showed, not on assumptions.\nPull flow tied everything to delivery dates. The team calculated backwards from delivery dates. If 30 scenarios had to be completed by Friday, that would mean 6 per day. They tracked progress daily at 11 AM and 3 PM. If they fell behind by lunch, they reorganized the afternoon. No more discovering on Thursday that Monday’s plan had failed.\nA new rule changed behavior: call the team leader immediately when blocked or without work. There were no more two-hour solo investigations. Problems surfaced in minutes instead of days.\nProblem-Solving in Action The visual system exposed problems, a core Lean Testing principle. PDCA gave the team a way to fix them.\nOne day mid-release, productivity dropped to about 0.1 scenarios per person per day. The PDCA analysis found three causes. Seven defects had been reported that day, but the pre-diagnosis step rejected three as false. Two testers spent two hours each on that dead end. Three blocking defects left nothing to test. And contribution requests from other projects pulled testers away without anyone tracking them.\nThe team acted. Testers now called the leader when blocked. External contribution requests got declared at the morning flash meeting. Progress updates happened in real time on the visual board. Two days later, it was back near target, around 0.9.\nAnother PDCA tackled the billing cycle failures. The root cause: a hundred or so contracts still referenced products from the cancelled project I mentioned earlier. Those products no longer existed in the database, but nobody had cleaned up the test data. The fix took a few table updates. The prevention: add a step to every release asking for the list of cancelled projects and their data impacts.\nA third PDCA attacked blocked scenarios. Early in a cycle, around twenty scenarios sat stuck. The causes included migration issues, technical environment problems, and a script that couldn’t handle empty files. Priority conflicts between test cycles. The team worked through each cause, resolved nearly all of them, and documented the patterns to catch earlier next time.\nResults After Three Months Productivity rose from 0.37 to 0.46 scenarios per person per day. That’s a 24% increase with no additional headcount.\nThe bad diagnosis rate (false defects plus wrong assignments) dropped from 15% to 10.5%. The team set a target to push below 10%.\nCustomer satisfaction moved from 6 to 7 out of 10. The client noticed changes in how the team communicated, how quickly problems were raised, and how visible progress had become.\nSomething unexpected happened mid-project. The team’s project manager changed overnight. In most situations, this would cause chaos. Here, the new manager walked in to find a visual board showing exactly what was happening, indicators being tracked, action plans on the wall, and a team that knew how to run itself. The transition happened without drama.\nWhat Made It Work Three factors made the difference: visible work, team-owned daily targets, and solving problems one at a time.\nThe work was visible. The board on the wall meant no one could pretend things were fine when they weren’t. Stuck items showed up immediately. The 11 AM check revealed problems, allowing time to fix them and ensure the performance by the end of the day.\nThe team owned daily targets. The number came from delivery dates, not from a manager’s wishful thinking. Testers calculated it themselves. That ownership mattered.\nThey solved problems one at a time. The team didn’t try to fix everything in a big process redesign. They picked the problem hurting them most that day, ran a PDCA, fixed it, and moved to the next one. Small wins accumulated into real change.\nThis is Lean Testing in practice: visible work, team-owned targets, and problems solved one at a time.\nThe manager visited monthly to see reality firsthand. Lean practitioners call this Genchi Genbutsu. Those visits kept leadership connected to the actual work rather than filtered reports.\nOther teams in the shared service center noticed. Colleagues watched the transformation and asked to join the approach. The experiment became a model.\nA testing team with a frustrated client found a way to work better. Not by adding tools or people, but by watching their own work, making it visible, and fixing problems as they found them. Lean Testing scales. It starts with observation.\nGet the Lean Testing Quick-Start Kit. 4 practices, real results, a two-week plan to start Monday.\nGet the Kit →\n","permalink":"https://leantechpro.com/lean-testing-case-study-24-productivity-gain-three-months/","summary":"\u003cdiv class=\"key-takeaways\"\u003e\n\u003ch2 id=\"key-takeaways\"\u003eKEY TAKEAWAYS\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eA 13-person billing test team increased productivity by 24% in three months by making work visible, setting daily targets, and solving problems one at a time with PDCA.\u003c/li\u003e\n\u003cli\u003eDiagnostic before action: observing testers at their workstations revealed hidden waste like seven help requests in three hours, repeated tests without conclusions, and two-hour solo investigations.\u003c/li\u003e\n\u003cli\u003eWhen the project manager changed mid-project, the new manager walked into a team that ran itself. Visual boards, tracked indicators, and clear action plans made the transition seamless.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003cdiv class=\"key-takeaways\"\u003e\n\u003cp\u003e\u003cstrong\u003eGet the Lean Testing Quick-Start Kit. 4 practices, real results, a two-week plan to start Monday.\u003cbr\u003e\n\u003ca href=\"https://jlcossi.activehosted.com/f/65\" class=\"button primary\" target=\"_blank\"\u003eGet the Kit →\u003c/a\u003e\u003c/strong\u003e\u003c/p\u003e\n\u003c/div\u003e","title":"Lean Testing Case Study: 24% Productivity Gain in Three Months"},{"content":" KEY TAKEAWAYS The product vs. productivity debate creates a false choice: Delivery capability is not separate from your product—it’s part of what customers buy and experience. Product ≠ offer: A product includes features, delivery system, quality level, and support experience. Toyota never separated “the car” from “how the car is made.” Customers experience your delivery system directly: They pay for speed, uptime, and responsive support. Amazon’s product isn’t “stuff online”, it’s “stuff online, delivered tomorrow.” Speed enables learning, learning finds value: Faster delivery creates faster feedback loops. Teams that ship quickly learn what customers actually want. Slow teams guess. Most teams don’t lack ideas—they lack delivery capability: The bottleneck is rarely “we don’t know what to build.” It’s “we can’t ship what we know we should build.” I keep hearing the same advice: focus on your product, not your productivity. The argument sounds strategic: focus on what matters rather than internal mechanics. Stop rearranging deck chairs. Build something customers want.\nI’ve heard this for years. It contains a grain of truth wrapped in a fundamental misunderstanding: that product and delivery are separate things. But in reality, they’re not.\nThe Critique That Sounds Right The case against operational improvement goes like this: While you run workshops on lead time reduction, competitors ship new features. While you map value streams, they capture market share.\nProductivity gains are incremental. Product breakthroughs are exponential. Why optimize a 10% efficiency gain when you could build something customers love?\nStrategy consultants and product coaches repeat versions of this argument. It appeals to executives who want transformation, not continuous improvement. It flatters teams who prefer discovery over delivery discipline.\nAnd it misses the point entirely.\nProduct Is Not Just the Offer When people say “product,” they usually mean the offer: features, design, positioning, and price. It is about the thing you sell and how you package it.\nBut a product is everything required to deliver value to a customer, which includes:\nThe offer (features, design, positioning) The delivery system (how it gets built, tested, deployed) The quality level (how reliably it works) The support experience (how problems get resolved) Toyota understood this decades ago. The Toyota Production System is not a back-office function separate from “the product.” The production system is the competitive advantage. When customers buy a Toyota, they buy reliability that comes directly from manufacturing discipline based on people development.\nTaiichi Ohno did not view waste in the process as an operational problem. He viewed it as a defect in the product. The car and how it’s made are inseparable.\nThe same logic applies to software. A feature delivered late, shipped with bugs, or unsupported when it breaks, is a worse product than a simpler feature delivered well. Delivery capability shapes the product that customers actually experience.\nCustomers Experience Your Delivery System Customers don’t buy features in isolation. They buy outcomes that include:\nWhat they get (the feature) When they get it (lead time) How reliably it works (quality) How quickly problems get fixed (support) Three of those four depend on delivery capability. Only the first one is “the offer.”\nEvidence shows up in what customers pay for. SaaS companies charge more for:\n99.99% uptime vs. 99% uptime Same-day support vs. 48-hour response Weekly release cycles vs. quarterly releases Faster onboarding and implementation If delivery capability were separate from the product, customers wouldn’t pay premiums for it. But they do, because they experience it directly.\nAmazon Built a Delivery Company Amazon’s product isn’t “stuff you can buy online.” Plenty of websites sell stuff online. Amazon’s product is “stuff you can buy online and receive tomorrow.”\nBezos invested billions in logistics infrastructure: warehouses, planes, delivery networks, and routing algorithms. Not in features or marketing. Instead, he invested in delivery capability.\nHe did that because he understood that delivery speed is the product. The ability to get something tomorrow instead of next week changes what customers buy and how they buy it.\nAmazon didn’t separate “product” from “operations.” Operations became the product.\nApple Controls the Factory Apple designs products. Apple also obsesses over manufacturing. Jonathan Ive’s design team worked directly with manufacturing engineers in China. They didn’t hand off specs and wait for results. They iterated on production processes alongside product design.\nThe reason is: manufacturing capability determines what’s possible to design. And manufacturing quality determines what customers actually receive.\nThe product and the process that creates it are the same system.\nSpeed and Value are not Opposites A subtler version: “The point isn’t using AI to be faster. The point is creating better value.”\nThat is true in principle. Speed without direction produces garbage faster, and nobody needs that.\nBut the statement creates a false choice between speed and value. In practice, they reinforce each other.\nSpeed Enables Learning Teams that ship quickly get feedback quickly. Feedback reveals what customers actually value, not what you assumed they’d value.\nA team with a 2-week release cycle runs 26 experiments per year. A team with a 3-month release cycle runs 4. The fast team learns what customers want. The slow one guesses.\nSpeed doesn’t replace product thinking. Speed accelerates product learning. The teams that discover “better value” are usually the teams that can test ideas fast enough to learn from them.\nSlow Teams Guess When delivery takes months, teams make big bets. They spend weeks on discovery, build detailed roadmaps, and hope they got it right. By the time they ship, the market has moved.\nWhen delivery takes days, teams make small bets. They ship something minimal, watch what happens, and adjust. They don’t need perfect upfront insight because they can course-correct quickly.\nThe organizations that create “better value” aren’t the ones with better initial ideas. They’re the ones who can iterate faster toward what works.\nValue Includes Timing and Friction Value has a precise definition in Lean thinking: solving a problem the customer cares about.\nBetter value means:\nSolving a more important problem Solving it more completely Solving it with less friction required from the customer Solving it when they need it solved Two of four items (less friction, better timing) depend directly on delivery capability. You can’t solve a problem “when they need it” if your lead time is 6 months. You can’t reduce friction if your support queue runs 2 weeks behind.\nThe Lean test for value is simple: would the customer pay for this? Customers pay for speed, reliability, and responsive support. Delivery capability passes the value test.\nMost Teams Cannot Ship What They Know Most teams don’t fail because they lack good ideas. They fail because good ideas die in backlogs, get delayed by dependencies, ship with defects, or never reach production at all.\nThe constraint is usually execution, not ideation.\nWhen I run diagnostics, I find teams drowning in work-in-progress, waiting on approvals, fixing the same bugs repeatedly, and firefighting instead of building. They know what they should build, but they can’t get it done.\nTelling these teams to “focus on product, not productivity” is like telling someone stuck in traffic to “focus on the destination, not driving.” The destination matters. But you won’t reach it until you fix what’s blocking movement.\nRemove Execution Constraints First When a team reduces defects by 90%, they free capacity that was consumed by rework. That capacity can go toward product improvement.\nWhen a team cuts lead time from 64 days to 29 days, they ship features while they’re still relevant. They learn from production instead of guessing in planning meetings.\nWhen a support team moves from 40% to 68% on-time resolution, customers experience a better product. Their problems get solved faster. That is value creation.\nProcess improvement doesn’t compete with product improvement. Process improvement removes the constraints that block product improvement.\nWhen Product Focus Is Right The critique fits one situation: when the real constraint is “we don’t know what to build.” Some teams ship fast but ship the wrong things. So, they need discovery, not delivery optimization.\nBut test that assumption. Most teams who think they have a product problem actually have a delivery problem in disguise. They can’t learn what customers want because they can’t ship fast enough to find out.\nWhat To Say When You Hear This When someone says “focus on product, not productivity,” try this response:\n“I agree, the product matters most. But the product isn’t just about features. It’s everything the customer experiences: the feature, the quality, the speed, the support. I improve the parts of the product that most teams ignore.”\nOr, even shorter:\n“Delivery capability is part of the product. Improving how you deliver improves what customers receive.”\nThe dichotomy between product and process is false. Toyota proved it in manufacturing. Amazon proved it in e-commerce. Every SaaS company that charges for uptime and support speed proves it daily.\nThe teams that win don’t choose between product and productivity. They understand these are two views of the same system.\nYour delivery system shapes your product as much as your feature decisions do. Customers experience both. Improving either improves what they receive.\nThe debate is not product vs. productivity. The real debate is whether you can clearly see your product, including the parts that deliver it.\n","permalink":"https://leantechpro.com/your-delivery-system-is-part-of-your-product/","summary":"\u003cdiv class=\"key-takeaways\"\u003e\n\u003ch2 id=\"key-takeaways\"\u003eKEY TAKEAWAYS\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eThe product vs. productivity debate creates a false choice:\u003c/strong\u003e Delivery capability is not separate from your product—it’s part of what customers buy and experience.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eProduct ≠ offer:\u003c/strong\u003e A product includes features, delivery system, quality level, and support experience. Toyota never separated “the car” from “how the car is made.”\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCustomers experience your delivery system directly:\u003c/strong\u003e They pay for speed, uptime, and responsive support. Amazon’s product isn’t “stuff online”, it’s “stuff online, delivered tomorrow.”\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSpeed enables learning, learning finds value:\u003c/strong\u003e Faster delivery creates faster feedback loops. Teams that ship quickly learn what customers actually want. Slow teams guess.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMost teams don’t lack ideas—they lack delivery capability:\u003c/strong\u003e The bottleneck is rarely “we don’t know what to build.” It’s “we can’t ship what we know we should build.”\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003cp\u003eI keep hearing the same advice: focus on your product, not your productivity. The argument sounds strategic: focus on what matters rather than internal mechanics. Stop rearranging deck chairs. Build something customers want.\u003c/p\u003e","title":"Your Delivery System Is Part of Your Product"},{"content":"Measure how work really flows through your team. Answer the 10 questions honestly — you get your score, your #1 bottleneck, and a 3-step action plan.\nAccess Restricted This scorecard is only accessible after subscribing.\n← Back to Blog Question 1 of 10 ← Previous Next → 0 out of 100 Calculating... Your Scores by Area 🔴 Your #1 Bottleneck Loading... Your 3-Step Action Plan Want to Find the Root Cause? A 30-minute diagnostic call can pinpoint exactly what's blocking your delivery — and what to fix first. Book a Free Diagnostic Call → ","permalink":"https://leantechpro.com/delivery-flow-scorecard/","summary":"\u003cp\u003eMeasure how work really flows through your team. Answer the 10 questions\nhonestly — you get your score, your #1 bottleneck, and a 3-step action plan.\u003c/p\u003e\n\u003cstyle\u003e\n \n.scorecard-container {\n    max-width: 700px;\n    margin: 40px auto;\n    padding: 0 20px;\n    font-family: 'Inter', -apple-system, BlinkMacSystemFont, sans-serif;\n}\n\n \n.access-denied {\n    text-align: center;\n    padding: 60px 20px;\n    background-color: #fafaf9;\n    border: 1px solid #e7e5e4;\n    border-radius: 8px;\n}\n\n.access-denied h2 {\n    color: #44403c;\n    font-size: 24px;\n    font-weight: 600;\n    margin-bottom: 15px;\n    border: none;\n    padding: 0;\n}\n\n.access-denied p {\n    color: #78716c;\n    font-size: 16px;\n    margin-bottom: 25px;\n}\n\n.access-denied .button-back {\n    display: inline-block;\n    background-color: #f97316;\n    color: white !important;\n    padding: 12px 24px;\n    border-radius: 6px;\n    text-decoration: none;\n    font-weight: 600;\n    transition: background-color 0.3s ease;\n}\n\n.access-denied .button-back:hover {\n    background-color: #ea580c;\n}\n\n \n.progress-container {\n    margin-bottom: 30px;\n}\n\n.progress-bar {\n    height: 8px;\n    background-color: #e7e5e4;\n    border-radius: 4px;\n    overflow: hidden;\n}\n\n.progress-fill {\n    height: 100%;\n    background-color: #f97316;\n    border-radius: 4px;\n    transition: width 0.3s ease;\n    width: 0%;\n}\n\n.progress-text {\n    text-align: center;\n    margin-top: 10px;\n    color: #78716c;\n    font-size: 14px;\n}\n\n \n.question-card {\n    background-color: #ffffff;\n    border: 1px solid #e7e5e4;\n    border-radius: 8px;\n    padding: 30px;\n    margin-bottom: 20px;\n    box-shadow: 0 2px 6px rgba(0,0,0,0.05);\n}\n\n.question-number {\n    color: #f97316;\n    font-size: 14px;\n    font-weight: 600;\n    text-transform: uppercase;\n    letter-spacing: 1px;\n    margin-bottom: 10px;\n}\n\n.question-text {\n    color: #44403c;\n    font-size: 20px;\n    font-weight: 600;\n    line-height: 1.4;\n    margin-bottom: 25px;\n}\n\n \n.answer-options {\n    display: flex;\n    flex-direction: column;\n    gap: 12px;\n}\n\n.answer-option {\n    display: flex;\n    align-items: center;\n    padding: 16px 20px;\n    background-color: #fafaf9;\n    border: 2px solid #e7e5e4;\n    border-radius: 8px;\n    cursor: pointer;\n    transition: all 0.2s ease;\n}\n\n.answer-option:hover {\n    border-color: #f97316;\n    background-color: #fff7ed;\n}\n\n.answer-option.selected {\n    border-color: #f97316;\n    background-color: #fff7ed;\n}\n\n.answer-option input[type=\"radio\"] {\n    display: none;\n}\n\n.answer-radio {\n    width: 20px;\n    height: 20px;\n    border: 2px solid #d6d3d1;\n    border-radius: 50%;\n    margin-right: 15px;\n    display: flex;\n    align-items: center;\n    justify-content: center;\n    flex-shrink: 0;\n    transition: all 0.2s ease;\n}\n\n.answer-option.selected .answer-radio {\n    border-color: #f97316;\n}\n\n.answer-option.selected .answer-radio::after {\n    content: '';\n    width: 10px;\n    height: 10px;\n    background-color: #f97316;\n    border-radius: 50%;\n}\n\n.answer-text {\n    color: #44403c;\n    font-size: 16px;\n    line-height: 1.4;\n}\n\n \n.nav-buttons {\n    display: flex;\n    justify-content: space-between;\n    margin-top: 25px;\n    gap: 15px;\n}\n\n.btn-nav {\n    padding: 14px 28px;\n    border-radius: 6px;\n    font-size: 16px;\n    font-weight: 600;\n    cursor: pointer;\n    transition: all 0.3s ease;\n    border: none;\n}\n\n.btn-prev {\n    background-color: transparent;\n    color: #78716c;\n    border: 2px solid #e7e5e4;\n}\n\n.btn-prev:hover {\n    border-color: #d6d3d1;\n    background-color: #fafaf9;\n}\n\n.btn-prev:disabled {\n    opacity: 0.5;\n    cursor: not-allowed;\n}\n\n.btn-next {\n    background-color: #f97316;\n    color: white;\n    flex-grow: 1;\n    max-width: 200px;\n}\n\n.btn-next:hover {\n    background-color: #ea580c;\n}\n\n.btn-next:disabled {\n    background-color: #d6d3d1;\n    cursor: not-allowed;\n}\n\n \n.results-container {\n    display: none;\n}\n\n.results-container.active {\n    display: block;\n}\n\n.score-display {\n    text-align: center;\n    padding: 40px;\n    background: linear-gradient(135deg, #fff7ed 0%, #ffffff 100%);\n    border: 2px solid #f97316;\n    border-radius: 12px;\n    margin-bottom: 30px;\n}\n\n.score-number {\n    font-size: 72px;\n    font-weight: 700;\n    color: #f97316;\n    line-height: 1;\n}\n\n.score-max {\n    font-size: 24px;\n    color: #78716c;\n    margin-bottom: 15px;\n}\n\n.score-category {\n    font-size: 28px;\n    font-weight: 600;\n    color: #44403c;\n    margin-bottom: 10px;\n}\n\n.score-tagline {\n    font-size: 16px;\n    color: #78716c;\n}\n\n \n.results-breakdown {\n    background-color: #fafaf9;\n    border: 1px solid #e7e5e4;\n    border-radius: 8px;\n    padding: 25px;\n    margin-bottom: 30px;\n}\n\n.breakdown-title {\n    font-size: 18px;\n    font-weight: 600;\n    color: #44403c;\n    margin-bottom: 20px;\n}\n\n.breakdown-item {\n    display: flex;\n    justify-content: space-between;\n    align-items: center;\n    padding: 12px 0;\n    border-bottom: 1px solid #e7e5e4;\n}\n\n.breakdown-item:last-child {\n    border-bottom: none;\n}\n\n.breakdown-label {\n    color: #44403c;\n    font-size: 14px;\n}\n\n.breakdown-score {\n    font-weight: 600;\n    padding: 4px 10px;\n    border-radius: 4px;\n    font-size: 14px;\n}\n\n.breakdown-score.critical {\n    background-color: #fef2f2;\n    color: #dc2626;\n}\n\n.breakdown-score.warning {\n    background-color: #fff7ed;\n    color: #f97316;\n}\n\n.breakdown-score.good {\n    background-color: #f0fdf4;\n    color: #16a34a;\n}\n\n \n.bottleneck-card {\n    background-color: #fef2f2;\n    border-left: 4px solid #dc2626;\n    border-radius: 8px;\n    padding: 25px;\n    margin-bottom: 30px;\n}\n\n.bottleneck-title {\n    font-size: 14px;\n    font-weight: 600;\n    color: #dc2626;\n    text-transform: uppercase;\n    letter-spacing: 1px;\n    margin-bottom: 10px;\n}\n\n.bottleneck-name {\n    font-size: 22px;\n    font-weight: 600;\n    color: #44403c;\n    margin-bottom: 15px;\n}\n\n.bottleneck-description {\n    color: #78716c;\n    font-size: 15px;\n    line-height: 1.6;\n}\n\n \n.action-plan {\n    background-color: #ffffff;\n    border: 1px solid #e7e5e4;\n    border-radius: 8px;\n    padding: 25px;\n    margin-bottom: 30px;\n}\n\n.action-plan-title {\n    font-size: 18px;\n    font-weight: 600;\n    color: #44403c;\n    margin-bottom: 20px;\n}\n\n.action-item {\n    display: flex;\n    align-items: flex-start;\n    margin-bottom: 15px;\n}\n\n.action-number {\n    width: 28px;\n    height: 28px;\n    background-color: #f97316;\n    color: white;\n    border-radius: 50%;\n    display: flex;\n    align-items: center;\n    justify-content: center;\n    font-weight: 600;\n    font-size: 14px;\n    margin-right: 15px;\n    flex-shrink: 0;\n}\n\n.action-text {\n    color: #44403c;\n    font-size: 15px;\n    line-height: 1.5;\n    padding-top: 3px;\n}\n\n \n.cta-section {\n    background-color: #fff7ed;\n    border: 2px solid #f97316;\n    border-radius: 8px;\n    padding: 30px;\n    text-align: center;\n}\n\n.cta-title {\n    font-size: 22px;\n    font-weight: 600;\n    color: #44403c;\n    margin-bottom: 15px;\n}\n\n.cta-text {\n    color: #78716c;\n    font-size: 16px;\n    margin-bottom: 20px;\n    line-height: 1.5;\n}\n\n.cta-button {\n    display: inline-block;\n    background-color: #f97316;\n    color: white !important;\n    padding: 14px 32px;\n    border-radius: 6px;\n    text-decoration: none;\n    font-weight: 600;\n    font-size: 16px;\n    transition: background-color 0.3s ease;\n}\n\n.cta-button:hover {\n    background-color: #ea580c;\n    color: white !important;\n}\n\n \n.questions-container.hidden {\n    display: none;\n}\n\n \n@media (max-width: 640px) {\n    .scorecard-container {\n        padding: 0 15px;\n    }\n\n    .question-card {\n        padding: 20px;\n    }\n\n    .question-text {\n        font-size: 18px;\n    }\n\n    .score-number {\n        font-size: 56px;\n    }\n\n    .nav-buttons {\n        flex-direction: column;\n    }\n\n    .btn-next {\n        max-width: 100%;\n        order: -1;\n    }\n}\n\u003c/style\u003e\n\n\u003cdiv class=\"scorecard-container\"\u003e\n\n    \n    \u003cdiv id=\"access-denied\" class=\"access-denied\" style=\"display: none;\"\u003e\n        \u003ch2\u003eAccess Restricted\u003c/h2\u003e\n        \u003cp\u003eThis scorecard is only accessible after subscribing.\u003c/p\u003e\n        \u003ca href=\"/archives/\" class=\"button-back\"\u003e← Back to Blog\u003c/a\u003e\n    \u003c/div\u003e\n\n    \n    \u003cdiv id=\"quiz-container\"\u003e\n\n        \n        \u003cdiv class=\"progress-container\"\u003e\n            \u003cdiv class=\"progress-bar\"\u003e\n                \u003cdiv class=\"progress-fill\" id=\"progress-fill\"\u003e\u003c/div\u003e\n            \u003c/div\u003e\n            \u003cdiv class=\"progress-text\"\u003e\n                Question \u003cspan id=\"current-q\"\u003e1\u003c/span\u003e of 10\n            \u003c/div\u003e\n        \u003c/div\u003e\n\n        \n        \u003cdiv class=\"questions-container\" id=\"questions-container\"\u003e\n            \n        \u003c/div\u003e\n\n        \n        \u003cdiv class=\"nav-buttons\"\u003e\n            \u003cbutton class=\"btn-nav btn-prev\" id=\"btn-prev\" disabled\u003e← Previous\u003c/button\u003e\n            \u003cbutton class=\"btn-nav btn-next\" id=\"btn-next\" disabled\u003eNext →\u003c/button\u003e\n        \u003c/div\u003e\n\n    \u003c/div\u003e\n\n    \n    \u003cdiv class=\"results-container\" id=\"results-container\"\u003e\n\n        \n        \u003cdiv class=\"score-display\"\u003e\n            \u003cdiv class=\"score-number\" id=\"final-score\"\u003e0\u003c/div\u003e\n            \u003cdiv class=\"score-max\"\u003eout of 100\u003c/div\u003e\n            \u003cdiv class=\"score-category\" id=\"score-category\"\u003eCalculating...\u003c/div\u003e\n            \u003cdiv class=\"score-tagline\" id=\"score-tagline\"\u003e\u003c/div\u003e\n        \u003c/div\u003e\n\n        \n        \u003cdiv class=\"results-breakdown\"\u003e\n            \u003cdiv class=\"breakdown-title\"\u003eYour Scores by Area\u003c/div\u003e\n            \u003cdiv id=\"breakdown-list\"\u003e\n                \n            \u003c/div\u003e\n        \u003c/div\u003e\n\n        \n        \u003cdiv class=\"bottleneck-card\"\u003e\n            \u003cdiv class=\"bottleneck-title\"\u003e🔴 Your #1 Bottleneck\u003c/div\u003e\n            \u003cdiv class=\"bottleneck-name\" id=\"bottleneck-name\"\u003eLoading...\u003c/div\u003e\n            \u003cdiv class=\"bottleneck-description\" id=\"bottleneck-description\"\u003e\u003c/div\u003e\n        \u003c/div\u003e\n\n        \n        \u003cdiv class=\"action-plan\"\u003e\n            \u003cdiv class=\"action-plan-title\"\u003eYour 3-Step Action Plan\u003c/div\u003e\n            \u003cdiv id=\"action-items\"\u003e\n                \n            \u003c/div\u003e\n        \u003c/div\u003e\n\n        \n        \u003cdiv class=\"cta-section\"\u003e\n            \u003cdiv class=\"cta-title\"\u003eWant to Find the Root Cause?\u003c/div\u003e\n            \u003cdiv class=\"cta-text\"\u003e\n                A 30-minute diagnostic call can pinpoint exactly what's blocking your delivery — and what to fix first.\n            \u003c/div\u003e\n            \u003ca href=\"https://cal.com/jlcossi/leantechpro-discovery-call\" class=\"cta-button\"\u003eBook a Free Diagnostic Call →\u003c/a\u003e\n        \u003c/div\u003e\n\n    \u003c/div\u003e\n\n\u003c/div\u003e","title":"Delivery Flow Scorecard"},{"content":" KEY TAKEAWAYS Lean Testing makes testing problems visible so teams can solve them at the root, instead of hiding waste behind status reports. One team cut false defects from 44% to 4% and nearly tripled productivity by using visual boards, andon signals, and PDCA. Teams that practice Lean Testing are ready for AI. Teams that don’t will automate their waste instead of removing it. Get the Lean Testing Quick-Start Kit. 4 practices, real results, a two-week plan to start Monday.\nGet the Kit →\nLean Testing applies Lean management principles to software testing. It focuses on eliminating waste, making problems visible, and building people’s capabilities to solve them. The goal is smarter testing that delivers more value with less friction.\nThis guide covers everything you need to know: the principles, how it works in practice, a real transformation story, and how Lean Testing connects to the emerging world of AI-powered testing.\nThe Core Idea Lean Testing is Lean Management applied to software testing teams.\nLean Management builds people’s capability to see and solve problems. It makes work visible, not for tracking, but for learning. When people can see what’s happening, they can identify what’s wrong and fix it at the root, so waste disappears as a consequence.\nSoftware testing teams face challenges that rarely make it into status reports. Priorities shift mid-sprint. Test environments are broken or unavailable. Requirements are unclear, incomplete, or arrive late. Testers discover defects that developers close as “works as designed.” Automation scripts fail for reasons unrelated to the application. Knowledge lives in one person’s head, and that person is on vacation.\nYou know the symptoms. Testers wait: for environments, for clarifications, for builds, for fixes, for approvals. They report bugs that get rejected. They retest corrections that fail again. They spend hours investigating on their own before asking for help. They context-switch between projects, losing focus. They feel the pressure but can’t pinpoint where the time goes. They deliver on time, but only by cutting corners that no one talks about.\nLean Testing starts by making these problems visible. It gives testers a way to see what’s blocking them, surface issues early, and solve them together. The team develops its own capability to improve rather than following a new process imposed from above by learning to see its work differently.\nThe results speak for themselves: teams that test smarter, solve their own problems, and waste less time on work that adds no value. For IT services companies, this translates into a strategic advantage: delivering the quality the client expects at the pace they require, while developing people who can solve problems — that becomes a market differentiator.\nWhy Lean Testing Matters For Tech Leaders Classic approaches are running out of steam. Process reviews, audits, knowledge bases, offshoring, none of these help teams evolve as fast as clients demand. Meanwhile, pressure to reduce costs never stops, and Excel reports no longer provide the visibility you need.\nLean Testing offers something different: concrete visibility on what’s actually happening, teams that can handle demand fluctuations, and a way to reduce costs by eliminating waste rather than cutting corners.\nFor Testers Testing is often perceived as repetitive, with no clear path forward. Many testers are looking for meaning: a way to grow, to stay employable, to bring more value than just executing scripts.\nLean Testing changes the role. Testers learn to identify problems, solve them, and drive continuous improvement within their organization. They understand client challenges and contribute to solutions. The job becomes a path to growth, not a dead end.\nThe Principles of Lean Testing These principles emerged from a Lean transformation I led with a software testing team in 2014. The results surprised us: false defects dropped from 44% to 4%, productivity nearly tripled, and client satisfaction jumped from 6 to 8 out of 10. Since then, I’ve applied and refined this approach with other teams. What follows is what I’ve learned, the patterns I’ve observed, tested, and seen work. As more teams adopt Lean Testing, these principles will continue to sharpen.\n1. Make the Flow Visible (Value Stream \u0026amp; Flow) Test cases follow a flow: design, write, execute, done. That flow may come from any work organization you use. Make it visible. Track test case production daily.\nOne team tracked progress at 11 AM, 3 PM, and the end of the day. A simple board showed how many test cases were designed, written, and executed against the daily target. When execution lagged behind at 3 PM, the team reorganized priorities before the day ended, but not after the deadline passed.\nWhen flow is visible, bottlenecks reveal themselves. Blocked work isn’t hidden in a spreadsheet; it’s a red card everyone can see.\n2. Stop and Signal (Andon) When a tester hits a wall (blocked, stuck, or unsure), he does not waste time guessing. He raises a signal. Immediately, a functional expert comes to help, and they solve the problem together.\nOne team noticed testers struggling alone for hours before asking for help. They introduced a simple rule: when in doubt, call the expert. The expert comes to the tester’s workstation, sees the problem firsthand, and unblocks the situation on the spot. False defect reports dropped from 23% to 4% not through review, but because testers stopped guessing.\nThe andon also reveals learning opportunities. Each time the expert responds, they observe the tester’s gestures: how they investigate, interpret results, and report defects. Patterns emerge. The expert then plans short, focused training sessions called “Dojo” — 20 minutes on a specific topic. It could be a functional aspect of the application under test, or a testing gesture, like how to write a clear defect report. The andon becomes a feedback loop: signal, unblock, observe, teach.\nThe andon system comes from Toyota’s production lines, where workers pull a cord to stop the line when they spot a defect. In testing, the “cord” is a visible signal: a sticky note, a flag on the board, or a quick message. The response is immediate: an expert joins the tester to unblock the situation. The problem gets fixed before it compounds.\n3. Build quality into the gesture (Built-in Quality) Built-in quality means designing the work so that doing it right is the natural path. Instead of being a separate step, the quality check is embedded in the gesture itself.\nIn testing, a “gesture” is any repeatable action: writing a test case, executing a test, or reporting a defect. Each gesture can either invite errors or prevent them, depending on how it’s designed.\nConsider defect reporting. Without a standard, a tester sees unexpected behavior, types a quick description, and submits. Later, the developer rejects it as “cannot reproduce” or “works as designed.” Time wasted on both sides.\nNow let’s redesign the gesture. Every defect report requires a screenshot, steps to reproduce, and expected vs. actual behavior with a spec reference. No screenshot, no submission. The tester can no longer report on impulse. To fill in expected behavior, they check the spec and sometimes discover the behavior is correct. The quality check becomes invisible. It’s just part of how defects get reported.\nBuilt-in quality is about making mistakes harder to make.\n4. Pull from the Delivery Date (Pull) Don’t push tests through the system and hope you finish on time. Pull from the deadline. If 80 tests are due Friday, that’s 16 per day. Now you have a daily target to hit, and gaps surface early, when there’s still time to react.\nOne team checked progress three times a day: at 11 AM, 3 PM, and the end of the day. At 11 AM, they knew if the morning was on track. At 3 PM, they still had time to adjust: reassign testers, shift priorities, escalate blockers. By the end of the day, they knew exactly where they stood. No surprises on Friday. Problems that used to surface at the deadline now appeared on Tuesday afternoon, with time to fix them.\nThe principle: the delivery date drives the daily target. The daily target drives the hourly check. React early, not late.\n5. Solve Problems to Learn (Kaizen \u0026amp; Respect for People) Every gap, every false defect, every delay is a learning opportunity. Use structured problem-solving, such as PDCA, to identify root causes. For deeper investigations, the 5 Whys technique helps uncover why problems keep recurring. The goal isn’t just fixing today’s problem. It’s building the team’s capability to solve tomorrow’s problems.\nOne team saw productivity crash on a single day: 0.11 tests per person, down from the target of 1.0. Instead of moving on, they investigated. The root cause: invisible interruptions (urgent emails, ad hoc questions, environmental issues) that fragmented testers’ focus. Within two days, they identified the sources and put countermeasures in place. Productivity recovered. More importantly, the team learned a method they could apply to the next problem and the one after that.\nThe principle: problems are not failures to hide, they are opportunities to grow.\nI presented this PDCA approach at the Journée Française des Tests Logiciels (JFTL) in 2020.\nThe talk focuses on a single problem-solving cycle: how a testing team used PDCA to reduce false defects from 24% to 4% in three months. It covers the root cause analysis, the andon system we implemented, and the dojo practice that made the improvement stick. The full case study behind this presentation is available in the Sopra Steria article.\n[Download PDF] (French — presented at CFTL)\nRooted in Lean Management These principles emerged from the first Lean projects I led with software testing teams, starting in 2013. They aren’t invented from scratch. They’re adaptations of proven Lean Management concepts to the specific context of software testing:\nThe value of these principles is that they translate Lean’s abstract concepts into concrete actions for software testing teams. “Flow” becomes a board with columns showing test cases in motion. “Jidoka” becomes a rule about calling for help. “Pull” becomes a daily target calculated from the deadline.\nHow Lean Testing Works A team practicing Lean Testing works differently. Here’s how.\nThe Visual Board A board dominates the workspace, physical or digital. Test cases move through columns: Backlog → Designed → Written → Executed → Done. Rows are organized by delivery date, not by tester. Daily targets are written at the top of each row. Colored markers show progress checkpoints: 11 AM, 3 PM, and the end of the day.\nRed cards stand out. They signal blocked work. You’d also see a section tracking “invisible” work: support requests, urgent emails, and ad-hoc meetings. The team learned to make interruptions visible because that’s where time disappears.\nThe Daily Stand-up At 9 AM, the team gathers at the board. Fifteen minutes, no more. Each person provides input, but most importantly, the team leader shares the day’s objectives and explains how they were calculated. He recalls the specific strategies to improve the daily performance. The conversation stays anchored to the board and the KPIs. When someone mentions a blocker, the team decides who will help, right there.\nThe Andon in Action A tester stops typing. Something doesn’t look right. Instead of investigating alone, she places a red marker on her screen and calls the functional expert. He walks over, looks at the issue with her, and within five minutes, they’ve resolved it: the behavior was correct, just poorly documented. No false defect. No wasted hour.\nThe PDCA on the Wall Near the board, a flipchart shows an ongoing investigation. Yesterday, the team hit only 2 tests against a target of 8. The chart breaks it down: problem statement, identified root causes (environment unavailable for 3 hours; two testers pulled into a meeting), proposed countermeasures, owner, deadline. By Friday, the team will know if the fix worked.\nThe Defect Report Standard You notice a tester opening a defect in the tracking tool. The form won’t let her submit until three fields are filled: screenshot, steps to reproduce, and expected behavior with a spec reference. She pauses, checks the spec, and closes the form. The behavior was correct. No defect filed. The standard did its job silently.\nCase Study: A Real Transformation Here’s how these principles and practices come together. This story comes from a testing team responsible for validating billing scenarios for a telecom client. A separate case study covers an insurance testing team that achieved similar results.\nThe Starting Point The team had 13 testers across two sites. Their job: validate invoice generation scenarios before production releases. The client was frustrated. Testing started too slowly at the beginning of each phase. Testers lacked autonomy. The same questions kept coming up.\nThe numbers told the story:\nClient satisfaction: 6 out of 10 Productivity: 0.37 scenarios per person per day False defect rate: 15% of reported defects were abandoned due to diagnostic errors Observations revealed deeper issues. Testers constantly asked colleagues for help. I observed seven requests in three hours. Some testers ran the same test repeatedly without reaching a conclusion. Others investigated for over two hours before escalating, without opening a defect ticket. The work was invisible, the problems hidden.\nMaking Work Visible The team built a visual management board. Test scenarios flowed through columns: Backlog, Designed, Written, Executed, Done. Each row represented a delivery date. Progress was checked at 11 AM, 3 PM, and at the end of the day.\nCritically, the board also tracked “contributions”: support requests, meetings, and interruptions from other projects. Testers made these visible using sticky notes. For the first time, everyone could see where the time actually went.\nA Crisis Reveals the System On July 7th, the visual board showed a disaster: productivity had crashed to 0.11 scenarios per person. The target was 1.0. Something was very wrong.\nThe team gathered around the board and traced through the day:\nSeven defects had been reported. Three were rejected as false defects. Two testers had spent two hours each investigating. Three blocking defects were awaiting fixes; no scenarios could be run while waiting. Two testers had spent 3 hours and 40 minutes on support requests from other projects. Two testers had attended a 2-hour defect meeting with the client. The root cause was clear: invisible interruptions were consuming the team’s capacity. Without visual management, this would have remained hidden. The team would have been blamed for “low productivity” without anyone understanding why.\nThe Countermeasures The team implemented four actions:\nCall the team leader immediately when blocked, rather than silently absorbing the delay Declare known support requests during the morning stand-up, so they can be planned Update the visual board in real-time as interruptions occur Each tester makes their contributions visible using sticky notes Two days later, productivity was back to 0.92, close to the target. More importantly, the team discovered the reality of their workload. They found that support requests from other projects had consumed nearly four hours in a single day. This data gave the manager leverage to negotiate better boundaries.\nThe Results After three months, the transformation was measurable:\nThe client noticed the change: “I’m satisfied with the visibility on test progress.” The team had demonstrated a repeatable productivity peak of 0.7 scenarios per person per day, nearly double the starting point.\nThe false defect rate dropped from 15% to 10.5%, partly through better use of andon. Testers stopped guessing and started asking.\nBeyond the numbers, the team had transformed. They could see their own work. They could identify problems, solve them, and had become autonomous.\nLean Testing and AI-Powered Testing Teams often asked: with AI tools emerging for test generation, defect prediction, and automated analysis, is Lean Testing still relevant?\nYes. And they’re deeply connected.\nThe Common Ground Both Lean Testing and AI-Powered Testing attack the same fundamental problem: testers spend too much time on low-value activities.\nWriting repetitive test cases, hunting for false defects, re-executing known scenarios, and searching for root causes. These activities consume hours but add little value.\nLean Testing solves this through human systems: visual management to reveal waste, andon to prevent false defects, PDCA to find root causes, and standards to share best practices.\nAI can accelerate all of these:\nAI can analyze test data to reveal patterns of waste AI can flag potential duplicate defects before they’re reported AI can pattern-match to suggest likely root causes before observation AI can prioritize tests by risk and business impact AI can learn from the best testers and encode their approaches The Deeper Insight Lean Testing prepares teams for AI adoption.\nTeams that practice Lean Testing already track defects, blockers, and cycle times through visual management and PDCA. That data is clean and structured, ready to feed AI tools. They know what “good” looks like, so they can validate AI suggestions. They already question assumptions rather than blindly following procedures.\nTeams that haven’t practiced Lean Testing will struggle with AI. They’ll automate their waste. They’ll accept AI suggestions without the judgment to evaluate them. They’ll lack the data AI needs to learn from.\nLean Testing was the manual way to do what AI can now accelerate, but without Lean thinking, AI just automates the waste.\nGetting Started with Lean Testing You don’t need to transform everything at once. Start small:\nMake one thing visible. Create a simple board showing test cases flowing toward a delivery date. Track progress at midday and the end of the day. Measure one problem. Pick your biggest pain point (false defects, failed retests, or missed deadlines) and measure it for two weeks. Run one PDCA. When you see a gap between target and actual, gather the team and investigate. Find the root cause, then try a countermeasure. Implement one andon. Establish a rule: when in doubt, call for help before reporting a defect. These four steps will teach you more about Lean Testing than any book. You’ll see immediate results, and you’ll build the capability to go further.\nWhat Lean Testing Actually Is Lean Testing is not a methodology you install. It’s a way of thinking about work for better tester development.\nMake the flow visible, stop and signal, build quality into the gesture, pull from the delivery date, and solve problems to learn.\nTeams that embrace these principles test smarter and faster. They spend less time on waste and more time on value. They build capability instead of dependence.\nAnd when AI tools arrive, they are ready.\nFrequently Asked Questions How quickly can teams expect results from Lean Testing? Most teams see improved clarity within the first two weeks as visual management reveals previously hidden bottlenecks. Measurable results typically appear within three months. One team achieved a 200% increase in productivity and a 14% reduction in client-reported defects during that timeframe. The key is starting with small, focused improvements rather than attempting a complete transformation overnight.\nDoes Lean Testing require certification or specialized expertise? No. The principles are accessible to any testing team willing to honestly observe their own work. That said, working with someone experienced in Lean Management accelerates the learning curve. The first teams I worked with had a Lean expert guiding them through the initial months. The real requirement is curiosity first; credentials come later.\nDoes Lean Testing work in Agile environments? Yes. Lean principles complement Agile frameworks well. Both emphasize continuous improvement, visual management, and responding to change. Lean Testing adds rigor to sprint retrospectives with problem-solving and by tracking specific metrics that highlight improvement opportunities. Many teams find that Lean Testing provides the practical tools to achieve the quality goals Agile describes, but doesn’t always detail how to implement them.\nWhat’s the biggest challenge when implementing Lean Testing? The mindset shift. Managers must move from directing work to enabling problem-solving. They must resist solving problems for the team and instead coach testers to develop their own solutions. This requires patience and trust, especially when deadlines loom. The payoff comes when testers develop stronger analytical skills and take ownership of quality issues.\nHow is Lean Testing different from traditional test management? Traditional test management focuses on planning, tracking, and reporting. Lean Testing focuses on learning, problem-solving, and developing testers’ autonomy. Instead of managing outputs, you build capability. Instead of hiding problems in status reports, you make them visible so the team can fix them. Testers evolve from executing scripts to investigating root causes and improving the process itself.\nCan Lean Testing work with distributed or remote teams? Yes, with adaptation. The visual board becomes digital. Stand-ups happen over video. The andon signal becomes a message or a flag in a shared tool. The principles remain the same: make work visible, surface problems fast, solve them together. One team in the case study had testers across two sites and still achieved significant improvements. The discipline matters more than the physical setup.\nGet the Lean Testing Quick-Start Kit. 4 practices, real results, a two-week plan to start Monday.\nGet the Kit →\n","permalink":"https://leantechpro.com/what-is-lean-testing/","summary":"\u003cdiv class=\"key-takeaways\"\u003e\n\u003ch2 id=\"key-takeaways\"\u003eKEY TAKEAWAYS\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eLean Testing makes testing problems visible so teams can solve them at the root, instead of hiding waste behind status reports.\u003c/li\u003e\n\u003cli\u003eOne team cut false defects from 44% to 4% and nearly tripled productivity by using visual boards, andon signals, and PDCA.\u003c/li\u003e\n\u003cli\u003eTeams that practice Lean Testing are ready for AI. Teams that don’t will automate their waste instead of removing it.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003cdiv class=\"key-takeaways\"\u003e\n\u003cp\u003e\u003cstrong\u003eGet the Lean Testing Quick-Start Kit. 4 practices, real results, a two-week plan to start Monday.\u003cbr\u003e\n\u003ca href=\"https://jlcossi.activehosted.com/f/65\" class=\"button primary\" target=\"_blank\"\u003eGet the Kit →\u003c/a\u003e\u003c/strong\u003e\u003c/p\u003e\n\u003c/div\u003e","title":"What Is Lean Testing?"},{"content":" KEY TAKEAWAYS False defects dropped from 44% to 4% by implementing an andon system where testers call for help before reporting uncertain bugs Testing productivity more than tripled (from 1.5 to 8 tests per person per day) through a pull flow system with daily targets Failed corrections dropped from 23% to 10% using a quality wall with expert verification Client satisfaction recovered after years of complaints, with the client noting clear improvement in service quality This case study was co-presented with Arnaud Cailleau, then Director of Testing Services at Sopra Steria.\n[Download the original presentation (PDF)]\nThis Lean Testing case study documents one of the sharpest transformations I’ve seen in my career as a Lean coach.\nGet the Quick-Start Kit to apply these practices on your team. 4 practices, templates, two-week plan.\nGet the Kit →\nThe Call The manager carried a mix of frustration and determination. His testing team, fifteen people strong, had become the bottleneck everyone complained about. The client was not happy. Defects kept slipping through to production. Deadlines felt like a constant threat.\nThat conversation started one of the sharpest transformations I’ve see in my career as a Lean coach. What happened next surprised me.\nThe Setting The team worked for a major IT services company, testing a complex insurance application. That platform handled healthcare claims processing for several mutual insurance companies, calculating reimbursements, managing coverage rules, and processing payments. The kind of software where a single bug could result in thousands of people receiving incorrect reimbursement amounts.\nFifteen testers received software versions from the development team and ensured quality before delivery to the client. On paper, the mission sounded straightforward. In practice, the team struggled with problems they could not see clearly.\nThe client’s feedback stung: “Too many defects, it’s too important!” They complained about recurring bugs, fixes that broke other things, and a chronic pattern that eroded trust. One recent version contained seven regression defects that had already appeared and supposedly been fixed before. The client’s patience had worn thin.\nWhat I Found When I first walked into the team’s workspace, tension filled the air. Testers sat isolated at their desks, focused on their screens. No visible indication of who worked on what, which tests ran behind schedule, or where problems lurked.\nI spend time observing because it always reveals more than questions do. I watched testers write tests, execute them, and report defects. I measured and listened.\nThe numbers painted a grim picture. Client satisfaction had dropped to 4.6 out of 10. Productivity stood at 0.7 tests per person per day, far below the workload demand. When I analyzed correction cycles, I discovered that 23% of bug fixes failed on first delivery. The developers would fix something, testers would verify it, declare it working, and then the client would find it still broken. Twenty-three percent of the time.\nBut one number shocked me more than any other. When I examined defects reported by the testing team to the development team, I found that 44% of them got rejected. Almost half the bugs testers reported turned out not to be bugs at all.\nI had never encountered a false defect rate that high.\nDigging Into the Root Causes The false defects problem fascinated me. Why would experienced testers report so many issues that were not real bugs? I analyzed ten rejected defects in detail, and the causes told a story of systemic dysfunction:\nThirty percent came from wrongful rejections: bugs that actually existed but had already been fixed in a different version. Testers worked on outdated environments without knowing it. Twenty percent were duplicates, the same problem reported multiple times because no one tracked what had already been flagged. Twenty percent stemmed from testers not understanding the application’s expected behavior: they saw something unfamiliar and assumed it was wrong. Ten percent came from a misconfigured Firefox browser that cached old data, making testers believe they saw bugs when they actually saw stale information.\nThe pattern was clear: testers lacked visibility. They could not see what colleagues had already reported. They did not know when the environments changed. They had no easy way to verify expected behavior before logging a defect. When in doubt, they filed a bug report and moved on.\nGood individual practices existed within the team, but no one shared them. Some testers knew tricks others did not. Everyone understood use cases differently. No common vision united their work.\nStarting the Transformation I proposed a Lean Testing approach, built on four principles: support testers directly in the field, foster critical thinking about their own work, establish realistic daily goals, and build new skills systematically. The manager agreed to try it. Half the team showed skepticism. The team leader looked openly doubtful.\nWe began with a three-day workshop. I taught the testers to observe their own activities with fresh eyes. They learned diagnostic tools: how to identify waste in their processes, analyze their clients’ voices, and trace defects back to root causes.\nThe exercises forced uncomfortable realizations. Testers saw for themselves how much time they lost searching for information, waiting for environments, and redoing work. They examined the defects the client had reported and mapped out why those bugs had escaped detection. They made observations without ambiguity.\nBy the end of the workshop, the team had built its own action plan. It was not mine, but theirs. They committed to five changes: build a new working environment, manage the test flow differently, learn problem-solving methods, actively manage quality, and share knowledge systematically.\nMaking Work Visible The first thing we built was a visual management system. The team created performance indicators and displayed them on the wall for everyone to see: client satisfaction scores, defect rates, and productivity metrics. No more hiding from reality.\nThen came the pull flow board. On a large whiteboard, testers tracked every software lot as it moved through the testing process. Horizontal lines represented different delivery batches. Colored sticky notes showed progress: designed, written, and executed tests. At any moment, anyone walking by could see which lots were running ahead of schedule and which were falling behind.\nThe key insight came from setting daily objectives. Instead of vague weekly goals, we calculated backward from delivery dates. If a lot needed 100 tests completed by Friday, that meant 20 tests per day. The board tracked actual progress against that target at 11 AM, 3 PM, and the end of the day. When a gap appeared, the objective was 8, the actual was 1, and the team saw it immediately and could react.\nThis visibility changed everything. Problems that had stayed hidden for weeks now surfaced within hours. The team started holding fifteen-minute daily meetings to share blockers and redistribute work. They began solving problems (PDCA) together instead of struggling alone.\nThe Andon For the false defect problem, we implemented a core Lean Testing practice: the andon system. It is a mechanism borrowed from Toyota’s manufacturing lines. The principle: when a tester encountered doubt about whether something was actually a bug, they would not file a report immediately. Instead, they would call the functional expert, who would come to their workstation and examine the situation together.\nThis was a bigger shift than it sounds. Previously, testers who had questions would either file a defect “just to be safe” or spend long stretches trying to figure things out on their own. Now they had permission (obligation, even) to ask for help before committing to a defect report.\nThe functional expert went beyond just answering questions. Each interaction became a teaching moment. Twenty minutes with a tester, explaining the expected behavior, showing how to verify it, and transferring knowledge that would prevent the same doubt from arising again.\nWithin weeks, the false defect rate collapsed. From 44% in April to 8% in May to 4% in June. Testers stopped wasting time writing invalid bug reports. Developers stopped wasting time investigating non-issues. The whole cycle accelerated.\nLearning to Solve Problems The visual management board kept revealing problems: gaps between objectives and actuals, bottlenecks that slowed entire lots, and recurring quality issues.\nI taught the team the PDCA cycle, “Plan, Do, Check, Act,” a structured approach to problem-solving. When the board showed a gap, the team leader would initiate a PDCA. Why did we complete only one test when we planned eight? What blocked us? What can we try differently tomorrow?\nOne PDCA tackled the problem of “corrections KO”: bug fixes that failed verification. The team analyzed recent failures and identified three root causes: test cases that did not cover all scenarios affected by a bug, insufficient documentation of what had actually been tested, and sometimes features disguised as bug reports. They built a quality wall: after testers verified a batch of corrections, a functional expert would perform additional checks specifically designed to catch escapes.\nAnother PDCA addressed a productivity crash in a specific module. Writing productivity had dropped to zero when it needed to be four tests per day. Investigation revealed that testers were working with an incorrect reference file for reimbursement amounts and lacked knowledge of a dental coverage module required for the tests. The expert provided the correct file, trained the relevant testers on dental coverage, and reviewed their first corrected tests. Productivity recovered immediately.\nThe Results After three months, the numbers told a story that exceeded everyone’s expectations.\nTest execution productivity jumped from 1.5 tests per person per day in April to 3.9 in May to 8 in June, more than tripling. Writing productivity doubled. The false defect rate fell from 44% to 4%. The failed corrections rate dropped from 23% to 10% and continued to fall.\nThe client noticed. After years of complaints, they expressed satisfaction for the first time. They noted a clear improvement in service quality.\nThe Human Transformation The manager noticed changes he had not anticipated. Testers who had seemed disengaged now showed genuine motivation for solving problems. The visual management board became a gathering point; people would stop by, look at the status, and discuss what they saw. Conversations shifted from complaints to problem-solving.\nNew team members onboarded faster. The visual environment gave them immediate context. They could see what their colleagues worked on, understand the flow, and identify who to ask about what. The skeptical team leader became one of the strongest advocates for the new approach.\nTeam members took ownership of their workspace. They maintained the boards themselves, updated metrics, and initiated problem-solving sessions. The change management happened transparently, driven by the people doing the work rather than imposed from above.\nThe manager’s own practice changed. Monthly, he visited the team and spent time observing reality firsthand, what the Japanese call genchi gembutsu, “go and see.” These visits gave testers a chance to discuss progress directly with leadership. They created alignment between field realities and strategic goals.\nAn Unexpected Benefit Midway through the project, a new project manager joined the team. In normal circumstances, onboarding a manager takes weeks: learning the project status, understanding the dynamics, and figuring out where problems hide.\nThis time, the new manager understood the situation immediately. The visual boards showed exactly where things stood. The performance indicators revealed the trajectory. The established routines provided structure. Within days, not weeks, the new manager operated effectively. The system had become self-documenting.\nWhat This Project Taught Me This Lean Testing project taught me practices I now use on every engagement:\nMake the work visible. Testing happens inside tools, inside people’s heads. Without visual management tailored to test case flow, problems stay hidden until they become crises. The board we built, “tracking lots through design, writing, and execution,” gave everyone a shared understanding of reality.\nSet daily objectives. Weekly or sprint-level goals can lead to problems compounding. Daily targets create daily feedback loops. When you know by 11 AM that you are falling behind, you can still recover. When you discover it on Friday, you cannot.\nBuild an andon culture. Giving people permission to ask for help “requiring it, even,” transforms quality. The false defect problem vanished because they stopped guessing on their own.\nTeach problem-solving, not just solutions. Every PDCA the team completed built capability. They learned to diagnose root causes, test countermeasures, and verify results. Those skills outlast any specific fix.\nInvest in knowledge transfer. Twenty minutes per day, one-on-one with a tester, teaching specific skills; this investment compounds. Good practices spread, variability decreases, and the team grows stronger.\nYou just saw the results. Now start your own.\nGet the Lean Testing Quick-Start Kit: the 4 practices from this case study, a visual board template, and a two-week action plan.\nGet the Kit →\n","permalink":"https://leantechpro.com/lean-testing-in-action-how-we-tripled-testing-productivity-in-3-months/","summary":"\u003cdiv class=\"key-takeaways\"\u003e\n\u003ch2 id=\"key-takeaways\"\u003eKEY TAKEAWAYS\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eFalse defects dropped from 44% to 4%\u003c/strong\u003e by implementing an andon system where testers call for help before reporting uncertain bugs\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTesting productivity more than tripled\u003c/strong\u003e (from 1.5 to 8 tests per person per day) through a pull flow system with daily targets\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eFailed corrections dropped from 23% to 10%\u003c/strong\u003e using a quality wall with expert verification\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eClient satisfaction recovered\u003c/strong\u003e after years of complaints, with the client noting clear improvement in service quality\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003cdiv class=\"key-takeaways\"\u003e\n\u003cp\u003e\u003cstrong\u003eThis case study was co-presented with Arnaud Cailleau, then Director of Testing Services at Sopra Steria.\u003cbr\u003e\n\u003ca href=\"https://docsend.com/view/cpgrqmvwmdy4ewyu\" class=\"button primary\" target=\"_blank\"\u003e[Download the original presentation (PDF)]\u003c/a\u003e\u003c/strong\u003e\u003c/p\u003e\n\u003c/div\u003e","title":"Lean Testing at Sopra Steria: How We Tripled Testing Productivity in 3 Months"},{"content":"A Lean approach for startups growing faster than their support team can handle\nKEY TAKEAWAYS On-time resolution jumped from 40% to 68% by switching from push-based assignment to a pull system where technicians take tickets when they have capacity Escalation rate dropped from 20% to 11% through quality standards and visual management Client satisfaction improved from 7/10 to 8/10 with no additional headcount 44-ticket backlog cleared by making flow visible and enforcing a 24-hour assignment rule Your inbox is a disaster. Tickets are piling up. Your support team is stressed, working late, and still falling behind. Customers are getting angrier. Response times are slipping.\nThe tempting solution is to hire more people.\nThe problem: if your process is broken, hiring more people just means you’ll be paying more people to do broken work. You’re not fixing the problem. Instead, you’re scaling the chaos.\nYou’re Scaling What’s Broken When a support team is overwhelmed, the knee-jerk reaction is to add headcount. It makes sense because more tickets require more agents. But it does not work.\nI’ve seen a company hire three new support agents. Six months later, as they’re drowning again, they hire three more. The cycle continues.\nThe issue isn’t about capacity. It’s about flow.\nBefore you write another job posting, you need to understand where your support process actually breaks down.\nWhy Tools Alone Don’t Fix It Either If you search “how to scale customer support,” you’ll find article after article from software companies telling you to buy their tool: a new ticketing system, an AI chatbot, or an automation platform.\nWhat I’ve learned: a new tool on top of a broken process just gives you faster chaos.\nAutomation without understanding the flow means you’re automating waste. You’ll route tickets faster to the wrong people. You’ll auto-respond to questions that shouldn’t exist in the first place. You’ll generate dashboards full of metrics that don’t tell you what’s actually wrong.\nTools amplify what’s already there. If your process is solid, tools make it better. In case your process is broken, tools make it break faster.\nThe Lean Approach: Performance Gaps, Root Causes, and Lean Techniques I start with a diagnostic. The objective is to understand the real performance gaps and what’s actually happening on the ground.\nI go sit with the team. I watch how tickets come in, who picks them up, and where they stall. I interview customers and capture their words exactly as they say them — things like: “The response didn’t answer my question,” “I had to explain my problem three times,” “Nobody followed up.” I look at the data: what’s the non-resolution rate? How many tickets bounce back because the first response missed the point? Where does variability come from — the ticket type, the agent’s skills, blockers, the time of day? I dig into the root causes behind repeat issues: skills gaps, unclear procedures, product defects nobody owns, vague ticket descriptions.\nBy the end of this phase, I have a clear picture of the performance gaps, their root causes, and the improvement levers available. That’s when we decide together whether to move forward.\nThen, I bring the team together for a dedicated workshop. It isn’t a training where I lecture. We dive into their work. We process tickets in real-time. It’s where the team learns to see their own problems and acknowledges the need to change. I lead them through specific Lean techniques tailored to their reality: understanding variability in their ticket flow, designing a pull system to improve flow management, building visual management boards, applying structured problem-solving methods, and establishing quality standards for tech support. By the end, we have a concrete action plan they’ve built themselves, ready to put in motion immediately.\nFrom there, I stay with the team. I don’t disappear after the workshop. I stay with the team as they implement: helping them use their visual boards daily, facilitating their first problem-solving cycles, and coaching the team lead to spot obstacles early and address them. My job is to make myself unnecessary: transfer the capability so the team can sustain and improve on their own.\nWhat This Looks Like in Practice – Use Case In 2017, I worked with a tech support team at an energy company in France. Nine technicians were handling billing software issues for business teams. The client was frustrated: response times were too slow, and too many tickets were bouncing back unresolved.\nDuring the diagnostic, the numbers confirmed what the team already felt. On-time resolution was at 40%. The escalation rate was 20%: 1 in 5 tickets were escalated because the initial response didn’t resolve the issue. Client satisfaction was 7 out of 10. Not terrible, but not what they were paying for.\nI sat with the team and listened to customers. The feedback was blunt: “The response didn’t answer my question.” “I had to explain my problem three times.” I dug into the data. 36% of responses were poorly formulated: unclear, incomplete, or missing the point entirely. Tickets were assigned based on assumed specialties rather than actual skills or workload. There was no visibility on the incoming flow, no way to spot a pile-up before it became a crisis.\nWe ran a three-day workshop. The team mapped their own ticket flow, saw where variability was killing them, and designed a pull-based system to manage work in progress. They built visual boards to track tickets in real time. They agreed on quality standards for responses. They owned the action plan.\nTo manage flow, we attacked the backlog problem head-on. At the start, 44 tickets were sitting unassigned, some for over a week, a few for more than a month. Tickets were assigned to technicians based on supposed specialties, with no regard for their actual workload or the ticket’s complexity. Nobody knew which tickets were aging out.\nWe flipped to a pull system. Instead of pushing tickets onto people, technicians pull the next ticket when they have capacity. A shared board made everything visible: every ticket, its age, its status, who’s working on what. Daily stand-ups to review what was stuck and reprioritize based on SLA deadlines. Simple rule: no ticket sits unassigned for more than 24 hours.\nThree months later: on-time resolution had jumped from 40% to 68%. Escalation rate dropped from 20% to 11%. Client satisfaction moved from 7/10 to 8/10.\nThere was no additional headcount. The problem wasn’t capacity; it was flow, visibility, and method.\nWhat You Can Do Today Spend one hour sitting with your support team. I don’t mean to look at dashboards, but watching the actual work. Notice where agents face blockers, hesitate, search for information, or ask a colleague for help. That’s a waste.\nPull your last 20 resolved tickets. As an example, you can check: How many got it right on the first response? How many bounced back at least once? That’s your real resolution quality, not the number your ticketing system shows.\nAsk three agents the same question: “Show me how you resolve a ticket?” If you see three different approaches for the same type of ticket, you have a working standard and a visibility problem. The question is ‘why?’. Now you know where to dig.\nLook at your backlog right now. How many tickets are sitting unassigned? How old is the oldest one? If nobody knows, that’s the problem.\nThis won’t fix anything yet. But it will show you whether your issue is capacity-related or something else entirely.\nFix The Flow First Scaling support doesn’t mean scaling headcount.\nIf your process is broken, more people just means more people doing broken work. If your flow is invisible, no tool will fix that.\nStart by understanding what’s actually happening, which is not what you assume is happening. Find the performance gaps. Dig into root causes, then fix the flow. Understand the performance before you add resources.\nThe companies that scale successfully aren’t the ones that hire fastest. They’re the ones that see their problems clearly and fix them at the root.\nIf you’re tired of firefighting and want to find the real bottleneck in your support process, let’s talk. A short diagnostic conversation can often reveal what’s actually slowing you down, and it’s rarely what you think.\n","permalink":"https://leantechpro.com/how-to-scale-customer-support-without-just-hiring-more-people/","summary":"\u003cp\u003e\u003cem\u003eA Lean approach for startups growing faster than their support team can handle\u003c/em\u003e\u003c/p\u003e\n\u003cdiv class=\"key-takeaways\"\u003e\n\u003ch2 id=\"key-takeaways\"\u003eKEY TAKEAWAYS\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eOn-time resolution jumped from 40% to 68%\u003c/strong\u003e by switching from push-based assignment to a pull system where technicians take tickets when they have capacity\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEscalation rate dropped from 20% to 11%\u003c/strong\u003e through quality standards and visual management\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eClient satisfaction improved from 7/10 to 8/10\u003c/strong\u003e with no additional headcount\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e44-ticket backlog cleared\u003c/strong\u003e by making flow visible and enforcing a 24-hour assignment rule\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003cp\u003eYour inbox is a disaster. Tickets are piling up. Your support team is stressed, working late, and still falling behind. Customers are getting angrier. Response times are slipping.\u003c/p\u003e","title":"How to Scale Customer Support Without Just Hiring More People"},{"content":" KEY TAKEAWAYS Frameworks organize work, they don’t fix it: 84-96% of Agile transformations fail because they optimize the container (sprints, ceremonies, roles) without addressing how work actually flows through the system. Define outcomes first, then work backward: Results-based coaching starts with a specific, measurable performance gap and identifies the changes that will close it, rather than adopting a methodology and hoping for results. Four practices drive measurable improvement: Performance gap framing, direct observation, value stream mapping, and root cause analysis reveal problems that retrospectives and dashboards miss. Case study proof: A DevOps team running Scrum reduced infrastructure deployment lead time from 64 to 29 days (55%) by tracing actual work across team boundaries and fixing specific root causes. Start this week: Trace one feature end-to-end, spend one hour observing your team work, and define one performance gap with specific metrics. If coaching engagements have disappointed you by promising transformation yet delivering nothing more than process buzzwords, you are not alone.\nIBM found that 84% of digital transformations fail. Other studies put Agile transformation failure rates at 96%. The numbers vary. The pattern doesn’t: most organizations invest in transformation and end up with ceremonies rather than results.\nI’ve spent more than 13 years coaching tech teams through operational improvements. The organizations that succeed share one thing: they focus on business outcomes, not solely on adopting methodologies. The ones that fail do the opposite.\nThis article explains why most transformations stall and what actually drives measurable results.\nWhy Most Agile Transformations Stall Agile is valuable. The principles are sound, but the problem is how many organizations adopt it.\nMost transformations follow a predictable pattern: leadership announces the initiative, teams get trained on Scrum or SAFe, coaches facilitate ceremonies, and everyone waits for results. Months pass. Standups, retros, and sprints happen, but delivery doesn’t improve. Typically, Quality and Lead times don’t improve.\nWhen leaders ask why, they hear explanations about “culture” and “mindset” and “the journey.” They hear that transformation takes time. They also hear that they need more training, more coaches, more commitment.\nEventually, the organization declares the transformation complete (or quietly abandons it) and moves on. Leaders conclude that “Agile doesn’t work for us” or that their teams “aren’t ready.” Neither conclusion is accurate.\nThe Real Problem: Optimizing the Container, Not the Content Scrum, SAFe, Kanban, and other frameworks optimize how work is organized. They provide containers for work: sprints, backlogs, ceremonies, and roles. These containers are useful, no doubt.\nBut containers don’t fix what’s inside them.\nIf your code review process creates a 3-day bottleneck, putting it inside a sprint doesn’t remove it. If 40% of your sprint capacity goes to unplanned work and firefighting, a Kanban board makes that visible but doesn’t fix it. If your testing finds defects too late, retrospectives will identify the pattern, but here too won’t eliminate the root cause.\nThose Agile frameworks assume the work itself is efficient. They assume the problem is coordination and communication. Sometimes it is, but often it isn’t.\nThe real problems hide in the actual flow of value: how a feature request becomes working software, where work waits, why defects escape to production, and what causes the firefighting that consumes your capacity. Those frameworks don’t examine this. Instead, they organize around it.\nWhat Results-Based Coaching Looks Like When I work with tech teams, the same practices appear in every successful engagement. They’re not new. They’re foundational Lean practices that most Agile transformations skip entirely. The difference is how they’re applied: aimed at specific business outcomes, not methodology adoption.\nI call this results-based coaching: instead of adopting a framework and hoping for outcomes, you define the outcome first and work backward to the changes that will produce it.\nThese four practices reinforce each other. Performance gap framing tells you what to measure and, therefore, what problem to solve. Direct observation and value stream mapping reveal why the gap exists. Root cause analysis identifies what to change. They do not happen sequentially. Direct Observation of Work Reports and dashboards show outcomes. They don’t show causes.\nDORA metrics tell you that your lead time is 30 days. They don’t tell you why. Jira tells you that a ticket sat in “In Review” for 5 days. It doesn’t tell you that the reviewer was in back-to-back meetings and couldn’t focus on code reviews until Friday afternoon.\nThe only way to understand what actually happens is to observe it directly. I mean sitting with teams, watching how work flows, seeing where interruptions occur, and noticing what the data doesn’t capture.\nIn manufacturing, this practice is called Gemba: going to where value is created, to see. The same principle applies to software. You cannot fix what you cannot see, and you cannot see the real problems from a dashboard.\nWhen I observe teams, I consistently find problems that never show up in reports:\nDevelopers wait days for environment access or credentials The same bug was fixed multiple times because nobody addressed the root cause Knowledge trapped in one person’s head, creating bottlenecks whenever they’re unavailable Context switching that fragments focus and extends lead times Manual processes that could be automated, but “there’s never time.” These problems are invisible to frameworks, but they become visible through direct observation.\nValue Stream Mapping Most Agile implementations focus on the team level. But value doesn’t flow through a single team. It flows through the entire organization: from customer request to delivered solution.\nEven though SAFe includes value streams as a core concept, there’s a difference between organizing teams around value streams and actually mapping the flow of work to find waste. In my experience, concrete value stream mapping with process times, wait times, and % complete and accuracy rarely occurs in SAFe implementations.\nValue stream mapping traces the end-to-end flow. You pick a real piece of work and follow it from inception to delivery. At each step, you measure two things: how long the work takes (processing time) and how long it waits in the queue (queue time). You may add other things.\nThe results are often shocking. In a typical software organization, 10-15% of lead time is actual work. The rest is waiting: waiting for approval, waiting for review, waiting for a deployment window, waiting for someone to be available.\nThat finding reframes the question. Instead of asking “how do we make developers faster?” you ask “why does work spend 85% of its time waiting?” The answers lead to different interventions.\nValue stream mapping also reveals dependencies, handoffs, and rework loops that frameworks don’t address. When you can see the entire flow, you can identify where improvements will have the greatest impact.\nPerformance Gap Framing Vague goals produce vague results. “Improve delivery” is not actionable. “Reduce lead time from 45 days to 20 days by Q3” is actionable.\nPerformance gap framing makes problems concrete and measurable:\nCurrent state: What is happening now, with specific metrics Target state: What good looks like, with specific metrics Gap: The difference that needs to be closed Business impact: What closing the gap is worth in financial terms. Or, what is the actual business impact of the current state? This framing moves focus from blame to system improvement. “Developers are slow” becomes “the process creates 5 days of wait time that we can eliminate.” The team isn’t the problem. Actually, the system is the problem, and indeed, systems can be changed.\nPerformance gaps also create accountability. When the target is specific and measurable, you know whether you’re making progress. When the target is “be more agile,” nobody knows anything.\nRoot Cause Analysis Symptoms are easy to spot, but root causes take work to find.\nWhen delivery is late, the symptom is “we missed the deadline.” The root cause might be:\nDefects discovered late that required rework, testers lack the business-related skills Requirements that changed mid-sprint, because product owners don’t know how to manage them properly with the clients Dependencies on other teams that weren’t ready, because the team lacked the technical depth for proper user story sizing Unplanned work that consumed planned capacity, because the tech lead does not understand the kanban Estimation based on hope rather than data, because of a lack of technical depth Each root cause requires a different intervention. Fixing the wrong cause wastes effort and leaves the real problem untouched.\nRoot cause analysis uses structured methods (like the 5 Whys) to trace symptoms back to their origins. Combined with data, this analysis reveals what to fix, and more importantly, how much fixing it is worth.\nWhen you can say “this problem costs us $200,000 per quarter in rework and delays,” the business case for fixing it writes itself.\nCase Study: Reducing Infrastructure Deployment Lead Time by 55% A DevOps team at a large enterprise handled cloud infrastructure deployments. Eight engineers running Scrum: two-week sprints, daily standups, retrospectives, and a Scrum Master. They followed the framework.\nDevelopment teams complained about waiting too long for environments. In retrospectives, the DevOps team discussed many aspects of the issue, but nothing changed.\nPerformance gap framing: I started by measuring the actual lead time. I went through the last several deployments, step by step, and uncovered the reality: 64 days on average. Development teams waited two months for environments they could use properly. We decided to set the target to 30 days maximum. Every delayed deployment pushed back feature releases and burned budget on waiting. This was a time-to-market issue for the whole organization.\nDirect observation: I traced an actual deployment request through the system. I didn’t attend ceremonies. I just followed the work.\nWhat I found: the cloud engineer had no admin rights and waited 7 days for the tech lead to return from vacation. The networking team deleted a subnet because they weren’t notified about a new Azure ML process. Security group requests bounced between teams for 10 days because nobody knew which ticket to create. A document template was wrong. Even version two was incorrect.\nThe initial Agile reality: None of this surfaced in standups. The visual board showed “blocked.” It didn’t show why, nor was there any ongoing action to clarify the situation.\nMapping the flow: I mapped nine steps across five teams. I measured the lead time at each step. It was how we ended up with 64 days end-to-end. The mapping revealed where time disappeared: 31 days in a single queue for security group creation and flow opening requests. Requests waited in the queue because teams didn’t know where to route them.\nRoot causes identified through observation:\nNo admin rights for cloud engineers (in our case, only the tech lead could grant them, but he was not available) No documentation for request routing between teams Wrong templates for service-account creation No clarity on which security group to request for different environments The interventions: We created a deployment checklist with every entry point and routing decision. We front-loaded long lead-time requests (especially security groups) to run in parallel instead of sequentially. We scheduled early handover meetings before deployment completion. We documented what didn’t exist.\nThe results: The next deployment took 29 days. Down from 64, we achieved a 55% reduction.\nThe Scrum ceremonies continued. But the improvement came from tracing actual work across team boundaries, observing specific failures, and fixing specific root causes. The retrospectives had discussed “communication” for months. Direct observation revealed the real problems: missing documentation, unclear routing, and wrong templates. Those are fixable. “Better communication” is not.\nWhere This Approach Works Best This approach fits some situations better than others.\nIt works well when:\nYou have a specific performance problem you can measure. “Deployments take too long,” or “too many defects escape to production,” or “we miss commitments every sprint.” If you can put a number on it, you can improve it.\nYour team is stable enough to sustain changes. If people leave every few months or reorganizations happen quarterly, improvements won’t stick. You need enough continuity to implement changes and see results.\nLeadership will act on what the observations reveal. Direct observation surfaces uncomfortable truths. If leaders want validation rather than honesty, they won’t like what this approach uncovers.\nIt works less well when:\nThe goal is cultural change without operational targets. “We want to be more innovative” or “we need better collaboration” are worthy goals, but without specific metrics, there’s nothing to measure and no way to know if you’ve succeeded.\nThe organization is mid-reorganization. When reporting lines shift and teams dissolve, there’s no stable system to improve. Wait until the dust settles.\nNobody owns the problem. Every improvement needs someone accountable for the outcome. If the performance gap falls between teams and no one owns it, the approach stalls.\nGetting Started You don’t need a consultant to begin. Here are three things you can do this week:\n1. Trace One Feature End-to-End Pick a recently completed feature. Trace its journey from first request to production deployment. Note when work started at each stage, when it finished, and how long it took between stages.\nCalculate the ratio of working time to waiting time. If you’re like most teams, you’ll find opportunities hiding in the wait times that no framework addresses.\n2. Observe Without Agenda Spend one hour watching your team work. Don’t ask questions. Don’t facilitate. Just watch.\nNotice interruptions, context switches, and delays. Notice what problems surface in conversation that never appear in Jira. Notice the difference between what the process says should happen and what actually happens.\n3. Define One Performance Gap Identify one metric that matters to your business. Define where you are now and where you need to be. Make it specific: “Reduce escaped defects from 12 per month to 3 per month by the end of Q2.”\nThen ask: what would we need to change to close this gap? The answers will point toward the work that actually matters.\nConclusion Agile frameworks are tools, not solutions. They provide structure for organizing work but don’t address the operational problems that cause most delivery failures.\nWhen transformation stalls, the answer isn’t more training or more ceremonies. It’s looking at the actual flow of value: observing where work gets stuck, measuring the gaps between current and target performance, finding root causes, and implementing changes that produce measurable results.\nThis approach is less dramatic than a transformation. It doesn’t have a catchy framework name. But it produces outcomes you can measure and improvements that stick.\nIf your organization invested in transformation and got process buzzwords instead of business results, a different path exists. It starts with observation, seeing what’s actually happening, and fixing specific root causes.\n**Frequently Asked Questions ** Isn’t this just Lean? How is it different from Agile? This approach draws on Lean principles, particularly direct observation (Gemba), value stream mapping, and PDCA cycles for problem-solving. The difference from typical Agile coaching is the focus: Agile coaching often centers on framework adoption and team practices, while this approach centers on measurable business outcomes. The two can complement each other. The problem arises when framework adoption becomes the goal instead of the means.\nOur Agile coaches told us that transformation takes 2-3 years. Is that wrong? Culture change does take time. But operational improvements don’t require waiting for culture to change first. You can reduce defects, shorten lead times, and improve delivery reliability while culture evolves. In fact, visible operational improvements often accelerate culture change because people see that new approaches actually work.\nWe already track DORA metrics. Why isn’t that enough? DORA metrics tell you what’s happening. They don’t tell you why. Knowing your lead time is 30 days doesn’t explain the root causes of that lead time or which interventions will reduce it. Metrics identify where to look. Observation and analysis reveal what to do.\nHow do you avoid this from becoming another never-ending initiative? By defining success upfront with specific, measurable targets and timeframes. A targeted engagement might be “reduce escaped defects by 50% within 4 months.” When you hit the target, the engagement ends. The team owns the improvements and can independently apply the methods to future problems.\nWhat if leadership doesn’t support looking at root causes? Start small. Find one problem with a clear business cost. Solve it visibly. Use the results to build support for broader application. Leaders who resist abstract methodology often embrace concrete results.\nCan this work with remote or distributed teams? Yes. Observation can happen virtually through screen sharing, recorded work sessions, and analysis of communication patterns. The principle is the same: understand how work actually flows rather than relying solely on reports and metrics. Remote observation requires more intentional setup but reveals similar patterns.\n","permalink":"https://leantechpro.com/when-agile-coaching-doesnt-deliver-a-results-based-alternative-for-tech-leaders/","summary":"\u003cdiv class=\"key-takeaways\"\u003e\n\u003ch2 id=\"key-takeaways\"\u003eKEY TAKEAWAYS\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eFrameworks organize work, they don’t fix it:\u003c/strong\u003e 84-96% of Agile transformations fail because they optimize the container (sprints, ceremonies, roles) without addressing how work actually flows through the system.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDefine outcomes first, then work backward:\u003c/strong\u003e Results-based coaching starts with a specific, measurable performance gap and identifies the changes that will close it, rather than adopting a methodology and hoping for results.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eFour practices drive measurable improvement:\u003c/strong\u003e Performance gap framing, direct observation, value stream mapping, and root cause analysis reveal problems that retrospectives and dashboards miss.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCase study proof:\u003c/strong\u003e A DevOps team running Scrum reduced infrastructure deployment lead time from 64 to 29 days (55%) by tracing actual work across team boundaries and fixing specific root causes.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eStart this week:\u003c/strong\u003e Trace one feature end-to-end, spend one hour observing your team work, and define one performance gap with specific metrics.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003cp\u003eIf coaching engagements have disappointed you by promising transformation yet delivering nothing more than process buzzwords, you are not alone.\u003c/p\u003e","title":"When Agile Coaching Doesn’t Deliver: A Results-Based Alternative for Tech Leaders"},{"content":"Most LLM teams waste 40-60% of their AI budget without realizing it.\nKEY TAKEAWAYS Most LLM teams waste 40-60% of their API budget on operational inefficiencies, not model limitations Six common waste patterns: redundant API calls, missing caching, bloated prompts, slow retrieval, no quality measurement, and misallocated training investment University of Chicago research on 86,000 developers found experienced workers achieve 6% higher AI acceptance rates because they plan before implementing and evaluate systematically These are Lean skills: planning (PDCA), quality at the source, standard work, and gemba. The technology changes, but the operational capabilities that drive results remain constant Example savings: 67% reduction in API costs by combining redundant calls, 72% reduction by optimizing prompts, 64% faster responses by fixing retrieval pipelines Get the full framework →“The 12% Framework” explains what teams who ship AI to production do differently. Free PDF, 19 pages.\nDownload the 12% Framework →\nA University of Chicago study analyzing 86,000 developers found that experienced workers achieve significantly better results with AI agents. They plan before implementing, evaluate systematically, and avoid operational waste.\nI’ve spent 15 years eliminating waste in tech operations. The patterns in LLM teams are identical to what I’ve seen in software development, IT ops, and testing teams. My clients achieved 91% defect reduction in banking software, 50% productivity gains in government digital projects, and 68% improvements in on-time tech delivery operations for the energy sector.\nThe pattern: teams focus on model selection, fine-tuning, and GPU optimization. They ignore the operational waste that costs them half their budget.\nSix patterns. Six fixes.\nPattern 1: Redundant API Calls Pattern 2: Missing Caching Strategy Pattern 3: Unoptimized Prompts Pattern 4: Slow Retrieval Pipelines Pattern 5: No Quality Measurement Pattern 6: The Experience Paradox Pattern 1: Redundant API Calls The waste: The waste: three API calls where one would work. Classification. Generation. Validation. Each one costs money.\nUse Case: Consider a customer support team that processes 10,000 tickets monthly. Their workflow:\nCall 1: Classify ticket urgency Call 2: Generate response Call 3: Check response quality Three calls at $0.05 each = $0.15 per ticket.\nMonthly cost: $1,500\nThey combined these into a single call using structured outputs. Cost dropped to $0.05 per ticket.\nNew monthly cost: $500\nSavings: $1,000/month (67% reduction)\nWhy does this happen? The problem builds over time. Classification gets added first. Then response generation. Then quality checks. Each becomes a separate call. No one maps the workflow to catch the duplication.\nHow to fix it: Map your API call patterns for one typical user request. Count the calls. Ask: “Could we get all this information in one request?”\nModern LLMs handle complex, multi-part instructions. Use structured outputs (JSON mode) to get classification, content, and metadata in a single response.\nCheck your code for sequential API calls that process the same input. Batch them\nQuick win: Audit your five most common user flows. Find the redundant calls. Combine them. Most teams find 2-3x redundancy immediately.\nPattern 2: Missing Caching Strategy The waste: Identical content gets regenerated over and over. If the user asks the same question five times, the LLM generates the same answer five times. You pay five times.\nWithout caching, teams pay for the same generation multiple times.\nUse Case: A documentation search system handles 50,000 queries per month. Analysis showed 35% were identical queries (like “how to reset password” or “API rate limits”).\nWithout caching: 50,000 queries × $0.02 = $1,000/month\nWith caching (24-hour TTL): 32,500 queries × $0.02 = $650/month\nSavings: $350/month (35% reduction)\nAnd that’s just query caching. Embedding caching adds more savings.\nThe root cause: Get it working, ship it, move on. Caching feels like optimization for “later.” Later never comes. The API bills grow every month.\nHow to fix it: Implement caching at three levels:\nLevel 1 – Response caching: Cache final LLM responses for identical queries. Use Redis or similar. Set TTL based on how often your content changes (1 hour for dynamic content, 24 hours for stable content).\nLevel 2 – Embedding caching: Cache document embeddings. Most teams re-embed the same documents daily. Embeddings rarely change unless content changes. Cache them indefinitely. Only re-embed when documents update.\nLevel 3 – Retrieval caching: Cache retrieval results. If someone searches “pricing plans,” cache the top 10 relevant chunks for 6-24 hours.\nStart here: Implement response caching first. Log your queries for one week. Calculate the duplicate rate. That percentage is money you’re wasting. Implement basic Redis caching this week.\nPattern 3: Unoptimized Prompts The waste: Bloated prompts waste tokens. Teams include unnecessary context, verbose instructions, and redundant examples. Every extra token costs money.\nOpenAI’s GPT-4 charges $0.03 per 1K input tokens. A 1,000-token prompt that could be 250 tokens costs 4x more per request.\nUse Case: A content generation team using an 850-token system prompt. It included:\nLengthy background context (400 tokens) Five examples when two examples worked (200 tokens) Redundant instructions repeated three times (150 tokens) Formatting guidelines that could be 2 sentences (100 tokens) They processed 50,000 requests monthly at $0.025 per request.\nMonthly cost: $1,250\nAfter optimization, they cut the prompt to 220 tokens while maintaining the same quality of output.\nNew cost per request: $0.007\nNew monthly cost: $350\nSavings: $900/month (72% reduction)\nWhy teams miss this? It builds up over time. Teams add more instructions when outputs aren’t quite right. They never remove anything. The prompts grow like untended gardens.\nHow to fix it: Step 1 – Audit your prompts: List all your system prompts. Count tokens (use OpenAI’s tokenizer tool or tiktoken library). Sort by token count.\nStep 2 – Test shorter versions: Take your longest prompt. Cut 50% of the content. Test on 50 examples. Compare outputs. If quality holds, keep the shorter version.\nStep 3 – Remove these common wastes:\nBackground context, the LLM doesn’t need Examples beyond the first 2-3 (diminishing returns) Instructions repeated in different words Overly detailed formatting rules Apologetic or hedge language (“please,” “try to,” “if possible”) Step 4 – Set output limits: Use max_tokens parameter. Suppose you need 200-word summaries, set max_tokens to ~300. Don’t leave it at default (4096 or higher). You pay for every output token.\nImmediate action: Take your most-used prompt. Remove every sentence that isn’t a direct instruction. Test it. Quality probably stays the same. Cost drops 40-60%.\nSeeing these patterns in your own operations? I’m offering free 5-day diagnostics for 2 LLM teams this quarter. I’ll map your workflows, identify waste patterns, and give you specific recommendations with estimated savings.\n[Book your diagnostic call→]\nPattern 4: Slow Retrieval Pipelines The waste: Teams retrieve too many documents in RAG (Retrieval-Augmented Generation) systems. They pull 50 chunks when 10 provide the same answer. More retrieval = slower responses = worse user experience.\nIndustry benchmarks show typical RAG systems spend 60-70% of total latency on retrieval, not generation. Teams optimize the wrong bottleneck.\nUse Case: Consider a RAG-powered documentation system had these metrics:\nP95 latency: 8.5 seconds Breakdown: Retrieval 6.2s, Generation 2.3s The team obsessed over generation speed. They switched models, adjusted parameters, tried different providers. Latency barely improved.\nThen they measured retrieval. They were pulling 50 chunks per query. They tested with 10 chunks. Quality stayed the same.\nNew P95 latency: 3.1 seconds (Retrieval 1.3s, Generation 1.8s)\nImprovement: 64% faster\nWhy this happens: Nobody measures where time goes. They assume LLM generation is the bottleneck (it’s visible, it’s “AI”). They ignore retrieval because it’s “just database queries.”\nHow to fix it: Step 1 – Measure the pipeline: Add timing logs:\nTime to retrieve embeddings from vector DB Time to fetch actual documents Time to format context Time for LLM API call Time to parse response Step 2 – Optimize retrieval:\nReduce chunk count: Test 50 vs 20 vs 10 chunks. Find minimum that maintains quality. Parallel retrieval: Fetch chunks in parallel, not sequentially. Smaller chunks: Larger chunks = more tokens = slower processing. Test 256-token chunks vs 512-token chunks. Better indexing: If vector search is slow, check your index type (HNSW vs flat). Step 3 – Optimize context preparation: Don’t send all 10 chunks if the LLM only needs 3. Rank them. Send the top 3. Expand only if needed.\nFast test: Log P50, P95, P99 latencies with timing breakdown. Find your bottleneck. Most teams discover retrieval is60%+ of latency. Cut retrieved chunk count in half. Test quality. Usually it’s fine.\n**Planning advantage: **University of Chicago research on 86,000 developers shows that users who begin with a plan enjoy ~4 percentage‑point higher agent‑accept rates. Planning first improves alignment and downstream productivity.\nRetrieval‑side optimizations: Even a well‑planned request can be delayed if the retrieval stack dominates latency. Start by measuring each pipeline stage, then reduce the number of retrieved chunks (e.g., 50 → 10), parallelize fetches, and choose a performant index. After each change, re‑run the plan‑first test to ensure quality and acceptance stay high.\nTakeaway: Plan your retrieval strategy, test it, measure it, then optimize. Don’t just generate and hope.\nPattern 5: No Quality Measurement The waste: LLM features ship without measuring output quality. Tech teams change prompts, switch models, adjust parameters—with zero data on impact.\nQuality degrades silently. Users complain. Teams don’t know why.\nMost AI projects fail due to operational gaps, particularly the lack of measurement systems, rather than technical limitations.\nUse Case: A team deployed an LLM-powered classification system. It worked fine in testing.\nThree months later, users reported accuracy problems. The team had no metrics. They couldn’t tell when the decline started or what caused it.\nThey finally built an evaluation set. Accuracy had dropped from 87% to 61%.\nRoot cause: They’d changed the prompt four times. Each change degraded the quality slightly. No one measured it.\nWhy does this happen? Evaluation feels like extra work. Teams want to ship features. “It looks good” becomes the quality bar. LLMs are non-deterministic. The same prompt gives different outputs. Teams can’t tell whether a change improved quality or was just lucky.\nUniversity of Chicago research on AI coding agents found that teams with strong measurement systems maintained quality while increasing output by 39%. Without evaluation frameworks, teams couldn’t tell if changes helped or hurt.\nHow to fix it: Step 1 – Build evaluation dataset:\nCollect 100-200 representative examples Add expected outputs (human-labeled) Cover common cases and edge cases Update monthly as the product evolves Step 2 – Define metrics: For classification tasks: accuracy, precision, and recall. For generation tasks: relevance (1-5 scale), completeness, correctness. For RAG tasks: answer quality, source attribution accuracy\nStep 3 – Automate evaluation: Run your eval set on every prompt change. Track scores over time. If a change drops quality 5%+, revert it.\nUse LLM-as-judge for generation tasks (one LLM evaluates another’s outputs). This scales better than human evaluation.\nStep 4 – Monitor production: Sample 1-5% of production outputs daily. Evaluate them. Track quality trends. Catch degradation early.\nFirst step: Create a 50-example eval set this week. Run your current system against it. Establish a baseline. Now you can measure if changes help or hurt.\nPattern 6: The Experience Paradox The waste: Most organizations assume that AI tools help junior developers more. They invest training budget in junior staff. They expect experienced developers to “figure it out on their own.” But the University of Chicago study found the opposite.\nThe data: A University of Chicago study analyzing 44,000 developers found experienced developers use AI agents more effectively:\n6% higher acceptance rates for AI-generated code per additional 6.6 years of experience 1.6 percentage points more likely to send planning messages first (an ~11% relative increase) 0.8 percentage points less likely to need code explanations per 6.6 years of experience Consistently higher code acceptance across all experience levels It is the opposite of AI autocompletion tools, which junior developers accept more frequently.\nWhy this happens: Organizations see AI as a “leveling tool” that helps juniors catch up. That’s true for autocompletion tools that help during task execution.\nBut AI agents require task specification. Experienced workers are better at:\nDefining clear requirements Evaluating outputs systematically Understanding when to accept vs reject Planning before implementing These are Lean skills. Experience builds them. AI agents amplify them.\nThe research insight: The study found that experienced developers have higher acceptance rates because they:\nSend planning requests more frequently before implementation Provide clearer context from deeper codebase knowledge Need fewer explanations of existing code patterns Can evaluate quality more effectively Junior developers accept less AI-generated code not because the AI performs worse for them, but because they can’t evaluate quality as effectively. They also spend more time asking the agent to explain code they’re unfamiliar with.\nHow to fix it: Flip your training priority: Train experienced developers on AI agent usage patterns first. They’ll get more value immediately. They can then coach junior developers.\nMeasure accept rates by experience level: Track who’s accepting AI outputs and at what rate. If your experienced developers have low acceptance rates, they need better, prompt training.\nCoach on “plan-first” usage: Research shows that planning before implementation improves outcomes. Teach developers to ask agents to plan, review the plan, then implement.\nTrack context quality: Experienced developers provide better context because they understand the codebase. Make context-building a teachable skill.\nQuick diagnostic: Analyze your team’s AI agent usage by experience level. If experienced developers aren’t using agents effectively, you’re leaving money on the table. Start there.\nThe Real Problem These aren’t just technical problems. They’re operational skill problems.\nUniversity of Chicago research analyzing 86,000 developers found that experienced workers achieve 6% higher AI acceptance rates per 6.6 years of experience. They plan before implementing, evaluate systematically, and provide better context.\nThe same Lean skills apply:\nPlanning before execution (PDCA) Systematic evaluation (quality at the source) Clear specification (standard work) Context awareness (go and see / gemba) According to the research, this is the shift from “syntactic to semantic work”, from typing code to specifying objectives and evaluating results.\nIt is exactly where Lean expertise becomes critical.\nMost LLM teams focus on:\nWhich model to use Whether to fine-tune GPU optimization Prompt engineering techniques They ignore the operational skills that determine success:\nHow to specify tasks clearly How to evaluate outputs systematically When to accept vs. reject How to plan before implementing Evidence indicates the value of these skills: organizations using AI agents saw output increases of 26-39%. But those gains only materialized for teams with strong operational practices—planning, evaluation, and systematic improvement.\nI’ve built these operational capabilities in tech teams for 15 years. The technology changes, but the required skills remain constant: planning, measurement, systematic evaluation, and clear specification.\nThese drove results in software development (91% reduction in defects). They drove efficiency in IT operations (68% on-time improvement). Now they’re driving AI productivity.\nSame fix: build the operational capabilities to use the tools effectively.\nStart Here Pick one pattern based on your biggest pain point:\nHigh or growing API costs? → Start with Pattern 1 (redundant calls) or Pattern 2 (missing caching)\n→ Quick diagnostic: Log API calls for one typical user session. Count duplicates.\nSlow response times frustrating users? → Start with Pattern 4 (slow retrieval)\n→ Quick diagnostic: Add timing logs to each pipeline stage. Find your bottleneck.\nInconsistent or declining quality? → Start with Pattern 5 (no measurement)\n→ Quick diagnostic: Sample 20 recent outputs. If you can’t spot quality patterns, you need metrics.\nPrompts that feel bloated? → Start with Pattern 3 (unoptimized prompts)\n→ Quick diagnostic: Count tokens in your most-used prompt. Over 500? There’s waste.\nExperienced developers underperforming with AI? → Start with Pattern 6 (experience paradox)\n→ Quick diagnostic: Compare AI acceptance rates by experience level. If juniors outperform seniors, you have a training problem.\nMost teams find 30-50% savings in the first pattern they fix.\nCan’t decide where to start? That’s exactly what my 5-day diagnostic solves.\nReady to Find Your 40-60% Savings? I’m offering free 5-day diagnostics to 2 LLM teams this quarter. What you get:\nWorkflow mapping of your LLM operations Waste pattern identification across all 6 patterns Specific recommendations with estimated savings No cost. No obligation. Requirements: You’re spending $5K+/month on LLM APIs\n[Book your diagnostic call→]\n","permalink":"https://leantechpro.com/llm-cost-optimization-reduce-api-spending/","summary":"\u003cp\u003eMost LLM teams waste 40-60% of their AI budget without realizing it.\u003c/p\u003e\n\u003cdiv class=\"key-takeaways\"\u003e\n\u003ch2 id=\"key-takeaways\"\u003eKEY TAKEAWAYS\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMost LLM teams waste 40-60% of their API budget on operational inefficiencies, not model limitations\u003c/li\u003e\n\u003cli\u003eSix common waste patterns: redundant API calls, missing caching, bloated prompts, slow retrieval, no quality measurement, and misallocated training investment\u003c/li\u003e\n\u003cli\u003eUniversity of Chicago research on 86,000 developers found experienced workers achieve 6% higher AI acceptance rates because they plan before implementing and evaluate systematically\u003c/li\u003e\n\u003cli\u003eThese are Lean skills: \u003ca href=\"https://leantechpro.com/the-pdca-cycle-deming-cycle-a-complete-guide-with-examples/\"\u003eplanning (PDCA)\u003c/a\u003e, quality at the source, standard work, and gemba. The technology changes, but the operational capabilities that drive results remain constant\u003c/li\u003e\n\u003cli\u003eExample savings: 67% reduction in API costs by combining redundant calls, 72% reduction by optimizing prompts, 64% faster responses by fixing retrieval pipelines\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003cdiv class=\"key-takeaways\"\u003e\n\u003cp\u003e\u003cstrong\u003eGet the full framework →\u003c/strong\u003e“The 12% Framework” explains what teams who ship AI to production do differently. Free PDF, 19 pages.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://jlcossi.activehosted.com/f/61\" class=\"button primary\" target=\"_blank\"\u003eDownload the 12% Framework →\u003c/a\u003e\u003c/p\u003e\n\u003c/div\u003e","title":"LLM Cost Optimization: How to Reduce API Spending by 40-60%"},{"content":" KEY TAKEAWAYS Voice of Customer (VoC) captures what customers expect, prefer, and dislike, uncovering both expressed and hidden needs In Lean management, VoC defines value from the customer’s perspective, without it teams cannot distinguish value-adding work from waste Example: An IT operations team used structured VoC collection to improve client satisfaction from 6.4 to 8.7 (+45%), double their 2-hour resolution rate, and reduce daily incidents by 37% Collect VoC data fresh: same-day feedback yields actionable insights, delayed surveys suffer from recall bias VoC feeds directly into PDCA cycles, turning customer input into measurable improvement What is Voice of Customer? Voice of Customer (VoC) captures customer expectations, preferences, and dislikes about products or services. It uncovers both expressed needs (what customers state directly) and hidden needs (what they reveal through behavior but never articulate).\nIn Lean management, VoC sits at the foundation. Lean defines value strictly from the customer’s perspective. Without accurate VoC, teams cannot distinguish value-adding work from waste.\nVoC vs Traditional Customer Feedback Most companies collect feedback reactively: surveys, NPS scores, complaint logs. VoC operates differently. The goal is to structure feedback, identify patterns, and translate them into prioritized requirements.\nExample: a customer writes “your app crashes when I upload photos.” Traditional feedback logs the bug. VoC asks: how many users experience this? Does it block a critical workflow? The output is a prioritized requirement, not just a ticket.\nExpressed vs Hidden Needs Expressed needs are explicit: feature requests, complaints, praise. Hidden needs surface through observation: users abandon a flow, contact support repeatedly, or build workarounds.\nA customer asking for “better reporting” might actually need faster access to key metrics. The literal request points to one solution. The hidden need opens multiple paths.\nWhy VoC Matters for Tech Teams Tech teams face a unique challenge: customer expectations shift faster than release cycles. Users compare your product to every app on their phone. What satisfied them last quarter feels outdated today.\nBuilding software is expensive, and over half of new features fail to deliver expected value. The root cause is often the same: teams assumed what customers wanted instead of verifying it. VoC provides that verification. It replaces assumptions with evidence.\nVoC as Input to Prioritization Product backlogs overflow with requests from sales, support, executives, and customers themselves. Without a filter, teams default to whoever speaks loudest. Roadmaps serve internal politics rather than customer needs.\nVoC changes the conversation. When a stakeholder pushes for a feature, teams can ask: what does the customer data show? How many users reported this issue? Prioritization becomes evidence-based rather than opinion-based.\nSupport teams benefit equally. VoC analysis reveals which incidents damage satisfaction most, which issues recur because root causes remain unsolved, and where resolution delays actually hurt customers.\nConnection to Lean: Value Defined by the Customer Lean management rests on a simple principle: value is whatever the customer will pay for. Every other activity is waste. This sounds obvious until you watch a team spend three sprints on an internal refactoring project while users abandon the product over a login bug.\nVoC operationalizes this principle. It forces teams to define value from the customer’s perspective, not their own. Engineers naturally gravitate toward technical elegance. Product managers chase competitor features. Executives push strategic initiatives. VoC pulls everyone back to the same foundation: evidence of what customers actually experience and what they need solved.\nHow to Collect VoC Data Companies collect Voice of Customer (VoC) data through various channels, from traditional surveys and interviews to online reviews and social media analysis. This multi-faceted approach reveals both customer preferences and their underlying motivations.\nFor example, when customers request a specific feature, understanding their motivation helps companies innovate and anticipate future needs. Businesses combine quantitative methods, like rating-scale surveys, with qualitative techniques, such as open-ended questions. Some use text analytics to process large feedback volumes automatically, identifying trends and sentiment.\nReal-time collection via mobile apps or website pop-ups allows companies to address issues promptly. Effective VoC programs also map the customer journey, gathering insights from initial awareness to post-purchase support.\nCustomer journey Map – Example A comprehensive VoC approach guides decisions. It guides customer-centric decisions, driving improvements across products and services.\nHere’s how it works in practice.\nCase Study: IT Operations Team Improves Satisfaction by 45% The Starting Point The IT operations manager of a bank knew something was wrong. His team of 17 technicians handled phone and printer incidents across 12 office buildings. Complaints reached him regularly. Clients were unhappy. But he had no clear data on what exactly was broken, no way to prioritize, and no leverage points for improvement.\nHe heard frustration but could not act on it.\nVoC Collection As a Lean coach, I proposed starting with a structured Voice of Customer collection. Together with the tech team, we designed a questionnaire covering seven axes:\nRequest completion: Did the client get exactly and fully what he asked for? Channel: Did the exchanges happen where and how the client wanted them? Reliability: Did the fix hold after the technician closed the ticket? Lead time perception: How did the client experience the resolution time? Client involvement: How much did the client have to do himself? Satisfaction rating: From 1 to 10, on this specific resolution. Gap to excellence: If under 10, what was missing? Ideal resolution: From the client’s perspective, how should it have gone? Here is the script, as an example:\nWhat did you ask for, and what did you get in the end? Where and how did the exchanges happen on this incident? What would have suited you better? What has happened since the fix? Walk me through the timing, from when you reported it to when it was solved. How did that fit what you needed? What did you have to do yourself to get this resolved? Rate this resolution, 1 to 10. If under 10, what was missing to reach 10? From your side, how should this ideally have been resolved? Every question is anchored to the one incident that just closed, never to “our service” in general. The first five stay open on purpose. A closed question collects a polite yes; an open one collects what actually happened.\nI ran this questionnaire with 30 clients over several days. Each evening, I called only clients whose incidents had been resolved that day. That way, I got fresh feedback, actionable insights, and no recall bias.\nVoC Insights Processing the data revealed the baseline: client satisfaction averaged 6.4 out of 10.\nTwo issues emerged clearly from the verbatims and ratings:\nLead time: Clients perceived resolution as too slow. They did not know if their ticket was acknowledged, in progress, or stuck. This uncertainty drove frustration and repeat calls. Incident volume: Too many incidents. Clients felt they spent too much time reporting problems that should not happen in the first place. From there, I collected operational data to measure the current state: only 17% of incidents were resolved within 2 hours, and the team handled 19 incidents per day on average.\nNow the manager had data: issues, baselines, verbatims. He could act.\nThe Approach I coached the team leader and technicians through a structured improvement process. First, I led them through observations of their own work. They saw the queues building up, the repeat calls from frustrated clients, the time lost searching for incident status. They acknowledged the need to improve.\nNext, they walked through their own process end to end and identified improvement points themselves. I taught the relevant Lean techniques for their specific situations. They applied those techniques to identify and address root causes.\nThe improvements they implemented:\nVisual management: A real-time board tracked all ongoing incidents, giving technicians and managers immediate visibility into status and bottlenecks. This addressed the client frustration around not knowing ticket status.\nTechnician assignment coaching: Technicians learned to allocate resources based on incident impact and complexity, not just arrival order.\nPDCA on cable incidents: Root cause analysis revealed that many incidents traced back to cable-related problems. The team ran a structured problem-solving cycle and implemented preventive measures.\nTroubleshooting standards: Technicians received training on systematic diagnosis, reducing variability in how incidents were handled.\nResults Within 3 months, with minimal disruption to daily operations:\nThe VoC collection gave the manager what he lacked: clarity. The structured questionnaire transformed vague complaints into specific issues. The daily collection rhythm ensured fresh, actionable feedback. The baseline measurements made progress visible.\nVoC told them exactly where to focus.\nVoC and Continuous Improvement VoC collection and processing is not a one-time study. Customer needs shift and products evolve. New friction points emerge. A VoC snapshot from six months ago may no longer reflect reality.\nIn the IT operations case, I led the team to create their own VoC questionnaire. Every evening, technicians called a few clients whose issues they had resolved that day. They owned the feedback collection. They heard directly what worked and what frustrated customers.\nThis daily rhythm made continuous improvement real. Each VoC cycle surfaced new improvement points. The team ran short PDCA cycles to address them. Clients saw improvements regularly.\nAs a result, team members learned VoC techniques they could apply independently. Continuous improvement stopped being a management initiative and became how the team operated.\nConclusion Voice of Customer transforms vague complaints into clear action. It gives teams the baseline measurements they need to improve and the feedback loop to confirm progress.\nIn Lean management, VoC is how you define value from the customer’s perspective. Without it, teams guess. With it, they know where to focus.\nThe IT operations team started with a frustrated manager hearing complaints he could not act on. Structured VoC collection gave him clarity: satisfaction at 6.4, two-hour resolution at 17%, 19 incidents per day. Three months later, every metric had improved. The team owned the process and continued running VoC cycles independently.\nVoC is not complicated. Ask customers what they need. Listen to what they say and what they reveal through behavior. Measure, improve. Ask again.\nFrequently Asked Questions What is Voice of Customer (VoC)? Voice of Customer is the process of capturing what customers expect, prefer, and dislike about a product or service. It uncovers both expressed needs (what customers say directly) and hidden needs (what they reveal through behavior). VoC goes beyond collecting feedback: it structures customer input into prioritized requirements that guide decisions.\nWhat is the difference between VoC and customer feedback? Customer feedback is reactive. You send a survey, log complaints, track NPS scores. You get data after something happens.\nVoC is a structured process. It identifies patterns across feedback sources, translates customer statements into specific needs, assigns priority, and drives action. Feedback tells you something went wrong. VoC tells you what to fix, to learn, and in what order.\nHow does VoC connect to Lean? Lean defines value strictly from the customer’s perspective. Any activity that does not deliver what the customer values is waste. VoC is how you determine what customers actually value. Without it, teams cannot distinguish value-adding work from waste. VoC feeds directly into problem identification, baseline measurement, and PDCA cycles.\nHow often should you collect VoC data? It depends on how fast your environment changes. For support teams handling daily incidents, daily or weekly VoC collection works well. For product teams with longer release cycles, monthly or quarterly collection may suffice.\nThe key is freshness. Feedback collected the same day as the experience yields actionable insights. Feedback collected weeks later suffers from recall bias. Build VoC into your operating rhythm rather than treating it as a periodic study.\nHow do you turn VoC data into action? Start by identifying patterns. What issues appear repeatedly? What frustrates customers most? Translate those patterns into specific, measurable problems. Set a baseline. Then apply structured problem-solving (PDCA, A3) to address root causes. After implementing changes, collect VoC again to confirm the improvement worked.\nCan small teams use VoC? Yes. VoC process does not require sophisticated tools or large sample sizes. A five-person team calling ten customers per week learns more than a large organization sending annual surveys nobody reads. Start with one feedback channel you already have (support tickets, direct conversations). Structure how you capture and review that feedback. Act on what you learn. Scale later.\n","permalink":"https://leantechpro.com/voice-of-customer-voc-a-complete-guide-for-tech-teams/","summary":"\u003cdiv class=\"key-takeaways\"\u003e\n\u003ch2 id=\"key-takeaways\"\u003eKEY TAKEAWAYS\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eVoice of Customer (VoC) captures what customers expect, prefer, and dislike, uncovering both expressed and hidden needs\u003c/li\u003e\n\u003cli\u003eIn Lean management, VoC defines value from the customer’s perspective, without it teams cannot distinguish value-adding work from waste\u003c/li\u003e\n\u003cli\u003eExample: An IT operations team used structured VoC collection to improve client satisfaction from 6.4 to 8.7 (+45%), double their 2-hour resolution rate, and reduce daily incidents by 37%\u003c/li\u003e\n\u003cli\u003eCollect VoC data fresh: same-day feedback yields actionable insights, delayed surveys suffer from recall bias\u003c/li\u003e\n\u003cli\u003eVoC feeds directly into PDCA cycles, turning customer input into measurable improvement\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003ch2 id=\"what-is-voice-of-customer\"\u003e\u003cstrong\u003eWhat is Voice of Customer?\u003c/strong\u003e\u003c/h2\u003e\n\u003cp\u003eVoice of Customer (VoC) captures customer expectations, preferences, and dislikes about products or services. It uncovers both expressed needs (what customers state directly) and hidden needs (what they reveal through behavior but never articulate).\u003c/p\u003e","title":"Voice Of Customer (VoC): A Complete Guide for Tech Teams"},{"content":" KEY TAKEAWAYS An Obeya is a physical or virtual space where the project lives on the walls, and the team meets weekly to decide what to change. Toyota built the first one during the Prius program in the 1990s. The method now runs in software, hospitals, banks, and creative agencies. A BI team I coached went from 24% to 55% on-time delivery in three months, cut defects in half, and raised customer satisfaction from 5.5 to 9.4. Across my engagements, I’ve used three types: project Obeya for delivery, management Obeya for business health, and product Obeya for customer fit. Pick by what you are trying to manage. The wall is not the point. The weekly conversation in front of the wall is. Without an animator running it, the room becomes wall decoration. A BI (Business Intelligence) team went from 24% on-time delivery to 55% in three months, using one room and six visual boards.\nGet the Virtual Obeya Template All 6 boards with placeholder fields, meeting cadence guide, and quick-start checklist.\n[Download Free Template →]\nWhat is Obeya Room? An Obeya is a physical or virtual space where activities live on visual boards. It may include charts, sketches, plans, and customer feedback. It also includes the open problems. The whole point is that a cross-functional team can walk in, see everything at once, and decide what to do next.\nThe word means “large room” in Japanese. Toyota started using Obeyas in the 1990s during the Prius program, and Lean practitioners have been adapting the idea ever since. Today, you find Obeyas in software teams, hospitals, banks, and creative agencies, wherever multiple specialists need to coordinate quickly.\nWhat sets it apart from standard project tools is what happens in the room, not what’s on the walls. An Obeya gives the team the full picture of the project’s issues and forces a weekly conversation about what to change. The visibility is half of it. The conversation in front of the visibility is the other half.\nOrigins: From Toyota to Tech In the 1990s, Toyota was building the Prius. Chief Engineer Takeshi Uchiyamada had three teams pulling in different directions: the engineers, the designers, and the production line. They had different priorities, different deadlines, and different definitions of “done.” His fix was almost embarrassingly simple. He locked the leads in one room, two or three afternoons a week, in front of the actual plans on the wall, and refused to let them leave until they had decided what to do next.\nThe Prius hit the market 10 years before its competitors.\nThe method spread from there. It now runs in software teams, hospitals, banks, and creative agencies, anywhere the people who decide need to see the same picture at the same time.\nKey Components of an Obeya Room These components show what a typical Obeya can include. The actual boards depend on the type, see “Three Types of Obeya” below.\nAn Obeya is where real-time project management and problem-solving happen in front of the team. The walls hold whatever the team needs to see: charts, sketches, timelines, the KPIs that matter that week, and the problems still being worked on. The point is not the artifacts. The point is that everyone is looking at the same picture at the same time.\nThe boards I see most often in an Obeya:\nVision and Objectives. The goals and mission of the project, in plain language. If the team cannot point to why the work matters, nothing else on the wall will save them. Client Feedback. User or customer insights, in the customer’s own words, when possible. Quotes beat summaries. Product Representation. Prototypes, diagrams, or product models. Whatever shows what is actually being built. Macro and Micro Plans. The roadmap on one wall, the detailed timeline on another. Most teams put the macro plan at eye level and the micro plan within arm’s reach. Key Performance Indicators (KPIs). A short list of measures the team reviews every week. Three to five, not twenty. Problem-Solving Boards. Open issues with names attached, usually structured as A3 Problem-Solving reports. Three Types of Obeya Not all obeya rooms serve the same purpose. The boards you put on the wall or create digitally, the people in the room, and the conversations that happen depend on one thing: what you are trying to manage. Across my engagements so far, I have built three types. Each starts from a different question.\nProject Obeya : “Are we delivering on time and within quality?”\nA project Obeya starts from a plan and tracks execution against it. The walls typically show milestones, timelines, defects, structured problem-solving, and delivery status. In tech organizations, this is typically led by an IT project manager who needs to see dependencies, milestone collisions, and quality gaps across concurrent projects or tasks in one view. The team meets weekly to review progress, surface risks, and solve blockers. The people in the room are project managers, tech leads, and delivery teams.\nThe wall reveals the gap between planned and actual. It prevents issues as a discovery tool. When a project slips or defects spike, everyone sees it at the same time. See the full case study: From 24% to 55% On-Time Delivery: A Project Obeya Room Case Study\nManagement Obeya : “Are we running this business in the right direction?”\nA management Obeya starts from the strategy and tracks business health. The walls typically show client satisfaction, revenue, margin, commercial pipeline, HR metrics, and structured problem-solving. The leadership team meets weekly to review performance, act on client feedback, and solve business-level problems. Use a management Obeya when you lead a department, division, or service line and need your leadership team to be aligned on the same facts every week. The people in the room are directors, managers, and functional leads.\nThe wall reveals performance gaps across the organization. The focus is on running the business.\nSee the full case study: Management Obeya: How an IT Services Team Built Their Own War Room\nProduct Obeya : “Are we building the right thing for the right people?”\nA product obeya starts from the customer and works backward through product definition, MVP scoping, and feature prioritization. The walls typically show the voice of the customer, the target product vision, feature mapping, the MVP perimeter, and delivery indicators (for example: quality, cost, timeline, and risks). In my experience, this is typically run by a product manager or, in larger organizations, by the team responsible for product creation and delivery: product managers, designers, engineers, and sometimes customer-facing roles.\nThe customer is not just a metric here. The customer is the reason the room exists. Every board traces back to what users need and whether the team’s builds meet that need. How to Choose. Ask one question: what are you trying to manage? If the answer is project delivery, build a project Obeya. If the answer is a business unit, build a management Obeya. If the answer is a product, build a product Obeya. Some organizations run two or three at different levels. A CTO might use a management Obeya for the department while each product team runs its own product Obeya. They connect through shared KPIs and escalation paths.\nIn practice, these types overlap. A product Obeya often includes a delivery planning wall. A project Obeya may start with strategic alignment. The labels describe the primary focus, not a rigid template. Start from your biggest problem and build the boards that make it visible.\nThe key point is to use Obeya as a discovery and learning tool about what you are managing.\nHow to Run an Obeya: The 6 Animation Practices The key to obeya is not the obeya. It’s you.\nA wall full of charts changes nothing on its own. What makes an Obeya work is the person who runs it: the animator. It is someone who walks into the room every week, points at the data, asks the hard questions, and refuses to let problems sit unresolved on a sticky note for three weeks in a row.\nWithout an animator, the room becomes wall decoration. With one, it becomes where the team thinks together.\nWho Animates the Obeya In a project obeya, the animator is usually the lead project manager. In a management Obeya, the business unit director is in charge. In a product obeya, the product manager or whoever owns end-to-end delivery.\nThe animator is the integrator, connecting what the customer wants, what the strategy demands, what the team can build, and what the data shows. When those four things stop aligning, the animator surfaces the gap and drives the fix.\nFrom my experience, a good animator is customer-obsessed, comfortable on both technical and functional grounds, and visionary without losing pragmatism. Most people are strong on two of those three dimensions. The role forces you to develop the third.\nThe 6 Practices The weekly Obeya meeting is the most visible practice. It is not the only one. Across my engagements, the teams that get real results run six practices:\n1. Run the weekly Obeya meeting. Sixty to ninety minutes, at the same time every week, in the room (physical or virtual). The team walks the boards, reviews indicators, surfaces problems, and sets the focus for the week ahead.\n2. Coach team members through PDCA. When a problem lands on the wall, someone owns it. The animator coaches the owner by clarifying the problem, identifying root causes, and testing countermeasures.\n3. Steer the work daily. A 10-minute check-in around the task board catches blockers that would otherwise wait a full week. I see most Obeyas die because the team meets weekly and lets issues fester between sessions.\n4. Replay the plan every week. The animator walks the macro plan end to end and asks: what changed, what’s at risk, which milestone slips if we don’t act now? This is what turns the Obeya from a status board into a forecasting tool.\n5. Animate design problem-solving. When the wall reveals a hard design problem (architecture, performance, user experience), the animator runs parallel exploration. Two small sub-teams build two prototypes, and the team converges on the better one, supported by evidence.\n6. Go to the gemba. The animator leaves the room to sit with a developer, watch a user test the product, or observe a handoff between two teams. The wall shows symptoms. The gemba shows causes.\nThe first practice is easy to start. The other five are what separate teams that treat the Obeya as a status report from those that use it to run the work.\nCase Study: BI Projects Transformation A global enterprise IT department ran 18 Business Intelligence projects across four continents. Only 24% of projects shipped on time. Releases averaged 38 defects. Customer satisfaction sat at 5.5 out of 10. Two senior project managers tracked their own work separately in spreadsheets and email threads, with no shared view of the full portfolio.\nI designed a “project Obeya” with the team, built around three zones: a strategy wall connecting every project to the CIO’s goals, a performance dashboard with six handwritten charts updated weekly, and a macro planning wall showing all 18 projects on one timeline. The team ran daily 15-minute reviews in the room and weekly Obeya sessions. Three structured PDCAs solved the most critical problems. After three months: on-time delivery increased from 24% to 55%, defects decreased from 38 to 19, and customer satisfaction increased from 5.5 to 9.4.\nSee the full case study: From 24% to 55% On-Time Delivery: A Project Obeya Room Case Study\nCase Study: Management Obeya for an IT Services Team An IT services agency director ran his team through weekly meetings and slide decks. Strategy was set in January and rarely revisited. Client issues surfaced only when they escalated. The commercial pipeline lived in spreadsheets that nobody reviewed together.\nI designed a “management Obeya” with his leadership team. Unlike a “project Obeya” that tracks deliveries, this one tracked the health of the entire business: client voice, vision and objectives, commercial development, performance indicators, and structured problem-solving. Seven modules on the walls of one room, reviewed weekly in 90-minute sessions. The agency director used it to replace opinion-based discussions with data-driven decisions.\nSee the full case study: Management Obeya: How an IT Services Team Built Their Own War Room\nBenefits of an Obeya Room An Obeya changes how teams work.\nDiscovery before delivery. Problems appear on the wall weeks before they appear in a status report. That’s the whole game. Fix it cheap, fix it early, or pay ten times more later. Teams also stop guessing what users want, because the customer’s voice is right there on the wall, in the customer’s own words.\nProblems on walls get solved. When an issue sits on a dashboard nobody opens, it can live there for months. Stick the same issue on a wall in a room where six people meet every Tuesday, and by the third Tuesday, someone will be annoyed enough to fix it. The room generates social pressure that no Jira board ever has.\nDecisions get faster because nobody has to chase the data. The leader walks in, looks at the wall, asks why a number moved, and makes a call before the meeting ends. There’s no “let me check with the team and get back to you.” Architecture trade-offs get sharper for the same reason. Anyone making a hard technical call can see the customer constraint, the current build, and what’s already broken, all in one glance.\nNothing hides in an Obeya. You can see where each project stands. You can see who owns the next move. If something is slipping, it’s slipping in public, and a leader will spot it in week two instead of finding out in week ten when the deadline is gone.\nEveryone is looking at the same picture. The executive sees what the team sees. When the customer walks in, they see what the executive sees. That removes the most expensive thing in any organization: the gap between what leadership thinks is happening and what is actually happening.\nConclusion The numbers in the BI case study are real successes: 24% to 55% improvement in on-time delivery, defects cut in half, and customer satisfaction from 5.5 to 9.4. All that happened in three months.\nThe point is what happens when a team stops reporting status and starts thinking together in front of the work. The leaders see what is actually happening. The problems get owned by name and resolved, with the team learning as they go. The customer’s voice sits on the wall next to the plan it is supposed to inform.\nYou may have a project, management, or product Obeya. It could be physical or virtual. Whichever Obeya you build, the rule is the same: show up every week, look at the wall, decide what to change, and learn. The discipline is what makes the Obeya room work. The room itself is just paint and paper until someone runs it.\nFrequently Asked Questions About Obeya Rooms What exactly is an Obeya Room? An Obeya is a place where the work lives on the walls. There are charts, plans, customer feedback, and problems being solved. All of it is visible at once. The term means “large room” in Japanese. Toyota built the first one during the Prius program in the 1990s, and the idea spread from there into software, hospitals, banks, and design agencies.\nAn Obeya does not work on its own. To start being useful, it requires facilitation skills and Lean techniques. The minimum is weekly reviews, root cause analysis, and structured problem-solving.\nI have coached a project leader to create an Obeya to pilot the delivery of a payment product on time and to the required quality. He created a beautiful, up-to-date Obeya for the project sponsor’s visit. After that milestone, he abandoned the Obeya. He was not using that on a weekly basis to pilot the project. Eventually, the planning drifted, and nobody knew where the project stood.\nDo Obeya Rooms work for remote teams? Yes, they do, but the discipline matters more than the tool. You can use Miro, Mural, Google Slides, or a Notion page. Any of them works if the team actually shows up every week and looks at the wall together. None of them works if the meeting becomes optional.\nFrom my experience, virtual Obeyas outperform physical ones. In virtual mode, the animator can set screen dynamics that force everyone to focus on the same artifact simultaneously.\nI have also seen virtual Obeyas die in three weeks. The team treated the dashboard as something to scroll past.\nI’ve coached a tech team organized over 4 time zones. The virtual Obeya was well-crafted Jira boards. We managed to create the habit of using it during daily meetings. That habit-building was all about managing the focus on the board. What makes Obeya different from traditional project management tools? First, you have the codified visual boards and the performance gap they surface. In addition, all that triggers a structured problem-solving that changes the way people manage problems.\nI used to say that it is not about the data, but the conversation that happens in front of them. Traditional tools are built for tracking. An Obeya enables discovery but is built for thinking. You walk into the room, you see the project, and you talk about what to change. That last part is the whole point. Without the weekly conversation, an Obeya is just a more expensive dashboard.\nWhat’s the biggest mistake companies make with Obeya Rooms? It is treating the Obeya as a status report instead of a working space. I’ve seen this many times.\nCompanies set up the walls (physical or virtual), take the photos for the internal newsletter, and then nothing changes. The meetings become update sessions. Nobody asks why a number moved, and consequently, nobody owns a problem long enough to solve it. The wall becomes wallpaper.\nThe Obeyas that work are those in which a team member, usually backed by the animator, refuses to let a problem sit on the wall without progress.\nWhich industries gain the most from Obeya Rooms? From what I know, manufacturing and software get the most press, but the method has already spread everywhere. There are Obeyas in hospitals, financial services, creative agencies, and more. The pattern is consistent: any team where multiple specialists need to coordinate under time pressure benefits from putting the work on a wall, physical or virtual.\nA team managing 18 Business Intelligence projects across four continents successfully improved on-time delivery from 24% to 55%, thanks to the Obeya practice they developed. That included managing all the external sponsors they had.\n","permalink":"https://leantechpro.com/what-is-an-obeya-room-a-complete-guide-with-examples/","summary":"\u003cdiv class=\"key-takeaways\"\u003e\n\u003ch2 id=\"key-takeaways\"\u003eKEY TAKEAWAYS\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eAn Obeya is a physical or virtual space where the project lives on the walls, and the team meets weekly to decide what to change.\u003c/li\u003e\n\u003cli\u003eToyota built the first one during the Prius program in the 1990s. The method now runs in software, hospitals, banks, and creative agencies.\u003c/li\u003e\n\u003cli\u003eA BI team I coached went from 24% to 55% on-time delivery in three months, cut defects in half, and raised customer satisfaction from 5.5 to 9.4.\u003c/li\u003e\n\u003cli\u003eAcross my engagements, I’ve used three types: project Obeya for delivery, management Obeya for business health, and product Obeya for customer fit. Pick by what you are trying to manage.\u003c/li\u003e\n\u003cli\u003eThe wall is not the point. The weekly conversation in front of the wall is. Without an animator running it, the room becomes wall decoration.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003cp\u003eA BI (Business Intelligence) team went from 24% on-time delivery to 55% in three months, using one room and six visual boards.\u003c/p\u003e","title":"What Is an Obeya Room? A Complete Guide With Examples"},{"content":" KEY TAKEAWAYS Stop Building “Agile Silos”: Rushing to form ARTs around technical specialties reinforces old bottlenecks. Value Stream Mapping re-centers everyone on real customer value. Start with Data-Driven Fixes: Use Value Stream Mapping to quickly pinpoint dependencies and inefficiencies—no major restructures needed. Focus on high-impact workflows for faster, visible wins. Accelerate and Scale: In one claims process, lead time halved from 94 to 45 days and customer satisfaction rose 15%. Quick wins build momentum for lasting change. The Rush to Structure: A Common Transformation Pitfall Organizations embracing Agile at scale often stumble at the first hurdle: setting up their Agile Release Trains (ARTs). The pressure to show quick progress pushes leaders toward the familiar – organizing teams around technical specialties rather than customer value.\nThis rush to action creates a facade of agility while reinforcing old silos. Take this mid-sized insurance company transforming its digital presence. At the beginning of their transformation, their IT leadership proudly announced three new ARTs: App Development, Quality \u0026amp; Operations, and User Engagement. Every technical function and every leader had its place on paper. The reality? A web of dependencies that would strangle their ability to deliver.\nThree months later, I heard from the Digital Transformation Lead, ‘Our teams were busy, but customers weren’t seeing results.’ A straightforward feature for the claims app, which required coordination across all three ARTs, took months instead of the weeks it should have.\nHere’s how this tech team got the organization wrong and fixed it with value stream mapping.\nTechnical Silos in Agile Clothing: The Initial ART Setup Under pressure to modernize their digital services, the leadership mapped the organizational chart onto ARTs.\nEach technical function found its home: App Development for software creation, Quality \u0026amp; Operations for testing and infrastructure, and User Engagement for customer insights.\nINitial ART structure ART 1 housed the development muscle. Team A crafted sleek user interfaces for mobile and web applications. Team B built the backbone – APIs, business logic, and databases. On paper, this split promised efficiency through specialization.\nART 2 took charge of quality and infrastructure. Team C ensured that the software met standards through rigorous testing. Team D managed the cloud infrastructure and deployment pipelines, promising smooth operations.\nART 3 focused on the customer angle. Team E analyzed user data and gathered feedback, while Team F handled support tickets and maintenance. They positioned themselves as the voice of the customer.\nBut this tidy arrangement masked a critical flaw. Every feature required an intricate dance of handoffs between ARTs. A customer filing a claim triggered a cascade of dependencies: front-end changes from Team A, API updates from Team B, testing cycles with Team C, deployment coordination with Team D, and feedback loops through Teams E and F.\n“We created a system where everyone had a role, but nobody owned the customer experience,” reflects the Lead Architect. “Our organization chart had become our enemy.”\nWhen Structure Meets Reality: Problems Surface The first signs of trouble appeared during the launch of the mobile claims feature. What should have been a four-week delivery stretched into a three-month ordeal.\n“Our customer needed to photograph damage to their car and submit a claim,” explains the Dev Lead. “Simple, right? Wrong.”\nThe feature’s journey exposed every flaw in their ART structure. Team A built a sleek photo capture interface but waited two weeks for Team B’s API. Team C discovered security issues during testing, bouncing the code back. Team D’s deployment window didn’t align with the fixes. Meanwhile, Team E reported rising customer frustration with the old process.\nThe dependencies created a cascade of delays. Each handoff required meetings, documentation, and priority negotiations between ARTs. A bug fix that took minutes to code needed days to reach production.\nWe tracked 47 separate handoffs for one feature. Each ART had different priorities. While teams spent weeks debating API specifications in meetings, customers remained stuck with the slow, outdated system.\nHere’s what the data showed:\nFeature lead time: 94 days (target: 30 days) Handoffs per feature: 47 Coordination meetings: 26 hours per week Customer satisfaction: dropped 22% But the real wake-up call came from customer feedback. “I switched to another insurer,” one review stated. “Three months to add photo uploads? My teenager could build this in a weekend.”\nkey problems with the initial ART structure Course Correction: Embracing Value Stream Mapping ARTs are structured to realize identified Value Streams. However, the transformation** **team missed the required Value Stream identification when defining the ARTs.\nIdentifying value streams and reshaping the ARTs again would lead to three key issues:\nTiming: it would require months, delay the benefits, and strongly impact the transformation momentum. Resources: leadership and teams would need a firm commitment, and that would impact the current work. Change management: it would lead to structural changes with resistance and coordination challenges. They needed to focus on what matters the most: improving the work that gets done. They had to shift their focus to optimizing flow within the defined structure. Hence, they agreed to conduct value stream mapping successively in well-defined areas.\nVSM in Action: A Practical Implementation In this context, there were three reasons to use it:\nDeliver immediate process visibility without structural reorganization. Create tangible team-level improvements with measurable results. Build lasting capabilities while maintaining transformation momentum. The organization needed quick wins while maintaining our delivery momentum.\nWith the help of a Lean expert, they moved ahead with a vision of an iterative approach rather than a complete organizational redesign.\nThey identified and selected high-impact areas facing delivery challenges, such as teams or interconnected teams where clients, lead time delays, or quality issues were noted. They conducted value stream mapping. They bootstrap continuous improvement to sustain the changes and then move to improve another area in the organization. iterative VSM approach Value Stream Mapping success builds on foundational Lean knowledge. Teams must understand key concepts before they start mapping. It begins with Problem-Solving and the Plan-Do-Check-Act (PDCA) approach. These provide the framework for systematic improvement. Then, teams need to grasp the Voice of the Customer deeply. It ensures all improvements create real customer value. They must also learn to spot different types of Waste. The 4M methodology (Man, Machine, Method, Material) helps them address root causes of variability. These analytical tools prepare teams for effective mapping.\nThe mapping process becomes more powerful with this foundation. Teams start by tracking several recent deliveries through the system. They create an “as-is” map based on reality, not assumptions. Their knowledge of Waste and variability sharpens their analysis. They spot issues along the value stream clearly. Each issue becomes a potential PDCA cycle. It generates concrete opportunities for improvement. Teams then develop specific solutions for each step. They also identify system-wide changes.\nFinally, they create the “to-be” value stream map. This optimized future state targets shorter lead times while maintaining quality. The “to-be” map becomes their north star for improvement.\nThis method turns Value Stream Mapping from documentation into a driver for real improvement. It grounds the work in Lean principles and keeps teams focused on continuous improvement.\nSuccess Story: The Claims Process Transformation They started with value stream mapping of their most painful customer journey: claims submission. A three-day workshop revealed:\n47 handoffs between teams, including back and forth, quality issues, and waiting Six approval gates leading to waiting times Unaligned sprint schedules generate waiting times Duplicate testing cycles The improvements focused on optimizing flow within the existing structure:\nVirtual claims team across ARTs with daily standups and visual management to see the flow in real-time. Synchronized two-week sprints for claims-related work Direct communication channels between front-end and API teams Shared testing environments reduce QA cycles Single product owner for claims features Early results validated the approach:\nLead time: 45 days (down from 94) Handoffs: reduced by 40% Customer satisfaction: up 15% Release frequency: doubled claim process transformation They started where they were. Perfect value streams can wait. It is better to focus on making the workflow better today.\nKey Takeaways: Lessons from the Transformation Journey Value Stream Mapping as a diagnostic tool. VSM gave the team visibility into process inefficiencies without forcing structural changes. The mapping exercise surfaced specific problems: 47 handoffs, 6 approval gates, unaligned sprints. None of this was visible in the org chart. With real data, improvements became targeted rather than guesswork.\nPragmatic transformation strategy. Instead of reorganizing all ARTs, they used VSM to fix high-impact areas one at a time. This kept delivery moving while building team capabilities. Virtual teams and synchronized sprints proved that process improvements can work inside existing structures.\nMeasurable business outcomes. Lead time dropped from 94 to 45 days. Handoffs fell 40%. Customer satisfaction rose 15%. Release frequency doubled. These results validated the approach and built momentum for the next round of improvements.\nCultural shift toward flow. VSM moved the conversation from org charts to value delivery. Teams learned to spot and eliminate bottlenecks across ART boundaries. That capability stuck.\n","permalink":"https://leantechpro.com/value-stream-mapping-the-missing-piece-in-your-arts/","summary":"\u003cdiv class=\"key-takeaways\"\u003e\n\u003ch2 id=\"key-takeaways\"\u003eKEY TAKEAWAYS\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eStop Building “Agile Silos”:\u003c/strong\u003e Rushing to form ARTs around technical specialties reinforces old bottlenecks. Value Stream Mapping re-centers everyone on real customer value.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eStart with Data-Driven Fixes:\u003c/strong\u003e Use Value Stream Mapping to quickly pinpoint dependencies and inefficiencies—no major restructures needed. Focus on high-impact workflows for faster, visible wins.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAccelerate and Scale:\u003c/strong\u003e In one claims process, lead time halved from 94 to 45 days and customer satisfaction rose 15%. Quick wins build momentum for lasting change.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003ch2 id=\"the-rush-to-structure-a-common-transformation-pitfall\"\u003e\u003cstrong\u003eThe Rush to Structure: A Common Transformation Pitfall\u003c/strong\u003e\u003c/h2\u003e\n\u003cp\u003eOrganizations embracing Agile at scale often stumble at the first hurdle: setting up their Agile Release Trains (ARTs). The pressure to show quick progress pushes leaders toward the familiar – organizing teams around technical specialties rather than customer value.\u003c/p\u003e","title":"Value Stream Mapping: The Missing Piece in Your ARTs"},{"content":" KEY TAKEAWAYS A value stream is the end-to-end flow of activities required to deliver software from idea to production, mapping it reveals bottlenecks, handoffs, and waste Value Stream Mapping (VSM) in tech focuses — amongst others — on lead time, process time, and percent complete/accurate (%C/A) at each step Example: A 30-person engineering team reduced delivery lead time by 45% and cut process steps from 14 to 6 using VSM and 7 PDCA initiatives The 5-step approach: Learn Lean techniques → Map “As Is” → Formulate improvements → Create “To Be” → Align on action plan VSM builds lasting capability; teams equipped with Lean techniques proactively surface and resolve delivery issues What is a Value Stream? Traditional Lean Management Definition A value stream encompasses the complete sequence of activities, both value-adding and non-value-adding, required to bring a product or service from its initial conception to the final delivery to the customer.\nIt represents the holistic journey of materials and information flowing through various processes, transformations, and waiting periods.\nThe concept, originating from Toyota’s manufacturing philosophy, emphasizes identifying and eliminating waste while maximizing activities that directly contribute to customer value.\nValue streams – high level perspective Technology-Specific Definition In the technology sector, a value stream represents the end-to-end flow of value creation from initial ideas or customer needs to the delivery of digital products or services. It includes all stages of software development, deployment, and maintenance, spanning across different teams, tools, and infrastructure components. This modern interpretation emphasizes:\nThe continuous flow of work items through development stages (planning, coding, testing, deployment) The integration of feedback loops from users and monitoring systems The orchestration of automated processes and human activities The measurement of lead time, cycle time, and value stream efficiency The optimization of cognitive work rather than physical materials Unlike traditional manufacturing, technology value streams often involve intangible assets, concurrent development cycles, and rapid iteration based on real-time data. They focus on optimizing both the delivery pipeline and the learning process that drives innovation in software development.\nIn Tech, think of value stream as a journey. It starts with an idea. It ends with working software in your users’ hands. Every step between these points matters.\nThe concept came from Lean Manufacturing, which always focuses on the production flow from customer demand back through raw material.\nIn software development, we no longer move physical items. We handle digital assets. These flow through various stages, such as planning sprints, writing code, testing features, and deploying updates.\nWhat is Value Stream Mapping? Value Stream Mapping (VSM) is a lean management technique that visually represents the flow of materials, information, and activities involved in delivering a product or service. Unlike broader definitions of a value stream, VSM specifically focuses on mapping each step to identify inefficiencies and opportunities for continuous improvement.\nExample: software testing value stream Purpose of VSM Visual Clarity: It transforms complex workflows into a clear diagram, making understanding how work flows from start to finish easier.\nTargeted Improvement: By highlighting every step—including waiting periods and handoffs—the map points directly to bottlenecks and waste to eliminate.\nEnhanced Communication: A shared visual language aligns team members from different functions, facilitating collaborative problem-solving.\nHow to Create a Value Stream Map Select the product or Service: Identify the specific product family or service process you want to analyze. Define the Scope and Boundaries: Decide where the process begins and ends. Clearly define the start (e.g., customer request, idea generation) and the finish (e.g., product delivery, service completion). Collect Data and Observe the Process: For the latest items that went through, gather quantitative and qualitative data at each step, such as lead and cycle times, waiting periods, and inventory levels. Use direct observation or process tracking tools to capture real-time information. Map the Current State: Draw the process flow diagram, documenting every step, handoff, and delay. Include key metrics such as lead time, processing time, and quality checkpoints. This current state map serves as a baseline for improvement. Identify Waste and Opportunities: Analyze the map to pinpoint non-value-adding activities, bottlenecks, and redundant steps. Look for delays, excessive handoffs, and any gaps between process stages that may benefit from streamlining. Design the Future State: Develop a revised map that eliminates identified waste and reimagines a more efficient process. Incorporate strategies for reducing wait times, automating manual steps, or reorganizing workflow to optimize performance. Implement and Monitor Changes: Put the new processes into practice and continuously measure performance against the future state design. Use feedback loops to refine the process over time further. Mapping Internal Value Stream in Technology In the technology sector, improvement initiatives often extend to internal value streams—not just the end-to-end flow from idea to customer delivery. For example, mapping internal processes such as development pipelines, release processes, testing workflows, API development and integration, feature implementation, security validation, incident management, bug fix processes, and technical debt resolution can yield valuable insights.\nThe key to selecting these internal streams is threefold:\nMeasurable Impact: Ensure the process has clear, quantifiable metrics that allow you to track improvements and demonstrate progress. Customer Relevance: Choose streams where enhancements can directly affect customer expectations and overall value delivery. Team Ownership: Focus on areas where teams are intimately involved and empowered to drive change, fostering a sense of accountability and continuous improvement. By mapping these internal streams, technology organizations can pinpoint bottlenecks, streamline workflows, and foster proactive collaboration, ultimately accelerating innovation while directly enhancing customer satisfaction.\nWhy Value Stream Mapping Matters for Tech Teams The key to value streams is to focus on flow. Every delay between idea and deployment costs you money. It is all about seeing and measuring the flow improvement.\nHere are key reasons why developing an understanding of the technology Value Stream matters:\nEliminate inefficiencies A value stream perspective reveals waiting, bottlenecks, unnecessary handoffs, and non-value-adding tasks. By focusing on value streams, your teams can reduce waste – activities that don’t directly contribute to value delivery – and accelerate delivery – through streamlined workflow and improved resource allocation.\nDrive customer satisfaction The value stream aims to deliver a tangible value to a client. Adopting the technique leads to the key questions regarding the customers: are we providing all the value the customers are expecting, when they want it, where they want it, and with the quality they want?\nIt is a unique opportunity to align people and value stream components to the client’s expectations.\nBridge strategy and execution As a leader, observing the value streams and people working alongside them leads you to the reality of your strategy. You have the unique opportunity to align teams around shared objectives. You can ensure everyone works around the common purpose. Your organization links work to value, clarifying how each task contributes to customer satisfaction and business success.\nKey Challenges in Tech Value Streams While optimizing value streams, many tech organizations face significant hurdles. Below are the key challenges that can hinder the efficiency and effectiveness of technology value streams:\nSilos between teams Some tech teams work in isolation, with limited communication or shared goals. This situation generates misalignment, duplicated effort, and a lack of end-to-end accountability.\nExample: Development teams might focus on building features, while operations teams may prioritize stability, resulting in conflicting priorities.\nBottlenecks in workflow Bottlenecks arise when work piles up at specific stages due to resource constraints, inefficient processes, or misaligned priorities. Delays in one area can disrupt the entire flow, leading to missed deadlines and higher costs.\nExample: A testing phase that cannot keep up with the rate of development creates delays in deploying features.\nInefficient Handoffs Frequent handoffs between teams or tools can slow progress and introduce errors. Each handoff increases the risk of miscommunication, delays, and rework. Example: A manual process for transferring work from development to quality assurance (QA) adds unnecessary time and effort.\nDifficulty in measuring and tracking performance Many organizations lack the tools and habits needed to measure the lead time for different activities throughout the production activities. Without precise data, it’s challenging to identify areas for improvement or demonstrate progress.\nExample: In a development team, nobody uses the development management tool (Jira, Azure DevOps) to track activities’ start and end times.\nOveremphasis on local optimization Teams often focus on improving their individual performance rather than the overall value stream. Optimizing one part of the process may have unintended adverse effects on others. Example: Speeding up development without addressing bottlenecks in deployment can lead to work piling up in later stages. Resistance to change Cultural inertia and fear of disruption often hinder the adoption of value stream optimization practices. Resistance to new workflows, tools, or metrics can slow progress and undermine improvement efforts. Example: Teams may resist automating processes due to concerns about job security or lack of familiarity with new tools.\nLack of real-time feedback Teams struggle to adjust and improve their processes without timely feedback from users or monitoring systems. This situation can lead to delivering features or fixes that don’t meet customer needs. Example: A feature deployed without proper user testing and involvement might result in low adoption and negative reviews.\nHow to Map a Tech Value Stream: 5 Steps Before mapping a value stream, developing a Lean mindset and practicing key Lean techniques is essential. Value stream mapping is not just about visualization for you. It’s about understanding the flow of work and identifying areas for improvement to reduce lead time.\nActionable steps to map a tech value stream Step 1: Learn Lean techniques To effectively analyze and improve a value stream, teams must first learn and apply fundamental Lean techniques, including:\nProblem-Solving: identify root causes of inefficiencies and implement structured solutions using the PDCA approach. Voice of Clients (VoC): use a framework to decipher customer needs and lead to improvement actions. Waste Identification: understanding and recognizing the seven waste in a Tech context. Quality Management: spot quality issues and their root causes throughout the delivery process, use red bins, learn the basics about quality management, and use Pareto analysis. Variability: learn the meaning and the consequences of variability in a delivery process; use the 4M Framework. By practicing these Lean techniques, teams build the capability to map, analyze, and optimize value streams effectively. Once this foundation is in place, the following steps guide the process of mapping and improving a tech value stream.\nStep 2: Create the VSM “AS IS” Teams observe the latest items that went through the process. The objective is to collect the lead time and processing time at each working step. Teams also collect all the issues and bottlenecks they spot along the process and their root causes. They rely on the knowledge of recent Lean techniques they acquired earlier.\nThe result is the VSM “AS IS,” which shows the flow and the improvement areas.\nStep 3: Formulate concrete improvements Teams formulate improvements for each working step – including the issues – previously observed. It could be a local improvement to a working step or something global impacting several steps, even the whole process. While doing this exercise, the north star is the client’s satisfaction. You also need to consider the well-being of the people working along the process. How are we going to provide better value to our clients?\nDo not forget that you are doing value stream mapping to reduce the lead time.\nStep 4: Create the VSM “TO BE” Using their new perspectives using Lean techniques, teams foresee the problems they will resolve along the earlier value stream “as is” they mapped. They create the ideal process for the sake of the clients. They have to commit to it. As in any learning and growing exercise, it makes sense to try things.\nStep 5: Create and align everyone on an action plan While mapping the value stream “as is,” teams spotted problems. It is time to hierarchies them, define owners, and recall the PDCA approach to use. Implementing the VSM “To Be” requires several changes within the process and the organization. The action plan’s goal as a step is to organize them and ensure a coordinated transition to the new state.\nCase Study: 45% Lead Time Reduction A tech team of roughly 30 engineers creates different software products for institutional clients. Their leader wanted to reduce the delivery lead time by 30%. He was facing less and less interest from clients and their tendency to shift to other providers. The lead time here is from inception until the software is live in production.\nFirst, I spent a few days understanding the organization, the delivery issues, and the leverages for improvement. Then, I planned two workshops: a VSM “As Is” and a VMS “To Be.”\nAt the beginning of the VSM “As Is” workshop, the team learned the PDCA, the Voice of Clients, and the concepts of Waste and Variability in Lean Management. For each of those, I let them practice on a real-life case. Especially for the VoC, I led them to an empathy exercise regarding their clients and then revealed the real VoC I collected independently.\nThen, we spent hours recreating the real-life of the two latest products they delivered. The huge end-to-end lead time, the waiting, and the quality issues we uncovered shocked everyone. It was the first time everyone, out of their silos, was facing the whole delivery lead time.\nWe methodically went through each issue along the value stream and dived into root causes, which led us to sustainable actions.\nEngineers quickly proposed improvement ideas and changes, which we organized into an action plan.\nWe ended up with 7 PDCA opened. From a VSM “As Is” including 14 working steps, the team agreed on a new value stream with 6 steps. After four months of implementation, the team reduced the delivery lead time by 45%.\nThe key benefit of that experience was for the organization. We have engineers equipped with Lean techniques. They proactively surface delivery issues and sustainably resolve them.\nTools and Best Practices For a successful Value Stream Mapping (VSM) initiative, your organization must apply the right tools and best practices. Below are key experience-based elements for a successful VSM in tech. Thoe elements maximize the impacts and drive meaningful improvements.\nEnsure and prepare data collection prior to the VSM “As Is” workshop : Before mapping the current state, gather quantitative and qualitative data to ensure and facilitate informed discussions. Without reliable data, the VSM session will be based on assumptions rather than actual performance.\nDefinition of the Customer End Point: Clearly establish what constitutes value delivery from the customer’s perspective. Considering the scope of your VSM, identify the final output that meets customers need. Focusing on what truly matters to customers prevents optimizing for internal efficiency at the expense of end-user satisfaction.\nForesee the Issues and their Root Causes: Prior to the workshop and for better facilitation and progression, anticipate potential roadblocks and conduct root cause analysis. It supports better understanding while discussing the issues during the workshop. Solving symptoms instead of root causes leads to temporary fixes rather than sustainable improvements.\nEnsure Knowledge of Lean Techniques: Teams should have a foundational understanding of Lean techniques to effectively analyze and improve the value stream. Without Lean knowledge, teams may struggle to distinguish value-adding activities from waste, limiting the effectiveness of VSM. So prior to the workshop identify the relevant Lean techniques for your context and be prepared to teach them.\nCreate an action plan before closing the workshops: A VSM workshop without execution leads to insights that never translate into actual business improvements. Ensure that every VSM session concludes with concrete next steps to drive change.\nConclusion Developing people so they can perform such an approach is a competitive advantage. When teams deeply understand value stream mapping and Lean techniques, they build a culture of continuous problem-solving.\nThis adaptability ensures that in changing market conditions, your business will thrive instead of struggle. A continuously optimized value stream enables faster decision-making, smoother execution, and a stronger alignment with customer needs, leading to sustained growth and resilience.\nFurthermore, organizations that embrace such an ability gain a learning advantage. Teams become more proactive, experiment with new ideas, and respond to disruptions faster than competitors. This approach isn’t just operational efficiency; it’s a long-term strategy for market leadership and innovation.\nFrequently Asked Questions What is the difference between a value stream and value stream mapping? A value stream is the complete sequence of activities, both value-adding and non-value-adding, required to deliver a product or service from idea to customer. Value stream mapping (VSM) is the technique used to visualize that flow, measure performance at each step, and identify opportunities for improvement. The stream is what exists; the map is how you see it.\nHow is value stream mapping different in software vs manufacturing? In manufacturing, VSM tracks physical materials moving through production stages. In software, you’re tracking digital work items — features, bugs, deployments — flowing through planning, coding, testing, and release. The principles are identical (reduce lead time, eliminate waste, improve flow), but the “inventory” is invisible: code waiting in queues, pull requests awaiting review, features blocked by dependencies.\nWhat metrics should I track in a software value stream map? Focus, at least, on three metrics at each process step: lead time (total elapsed time including waiting), process time (actual hands-on work time), and percent complete/accurate (%C/A) — the percentage of work that arrives at each step ready to process without rework. The gap between lead time and process time reveals waiting waste.\nHow long does value stream mapping take? A full VSM engagement typically runs 4 days split into two phases. The first phase (2 days) covers Lean technique training and “As Is” mapping. After a gap of a few days for additional assessment and data collection, the second phase (2 days) focuses on “To Be” design and action planning. Implementation of improvements runs 2-4 months depending on scope. The real value comes from making VSM a continuous practice, not a one-time event.\nCan value stream mapping work within existing team structures? Yes. VSM optimizes flow within your current structure rather than requiring reorganization. This is especially valuable in SAFe environments where ARTs are already defined — you can improve how work flows across teams without disrupting the organizational design.\nWhat Lean techniques should teams learn before mapping? Before effective mapping, teams need foundational knowledge of: PDCA (Plan-Do-Check-Act) for structured problem-solving, Voice of Customer to align improvements with real needs, waste identification (the seven wastes adapted for tech), and variability analysis using the 4M framework (Man, Machine, Method, Material). This foundation turns mapping from documentation into actionable improvement.\nWhat’s the relationship between value stream mapping and DevOps? Both are rooted in Lean principles and focus on flow optimization. DevOps provides the practices and automation (CI/CD, infrastructure as code, monitoring) that enable faster flow. VSM provides the visibility to see where bottlenecks exist and measure whether DevOps investments are actually improving delivery. They’re complementary — VSM shows you where to focus; DevOps gives you tools to fix it.\nHow do I choose which value stream to map first? Select based on three criteria: business impact (revenue, cost, customer satisfaction), team readiness (data availability, management support), and process health (known pain points, long lead times, quality issues). Start with a high-impact area where you can demonstrate quick wins — success builds momentum for broader adoption.\n","permalink":"https://leantechpro.com/value-stream-mapping-for-software-teams-a-complete-guide-with-examples/","summary":"\u003cdiv class=\"key-takeaways\"\u003e\n\u003ch2 id=\"key-takeaways\"\u003eKEY TAKEAWAYS\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eA value stream is the end-to-end flow of activities required to deliver software from idea to production, mapping it reveals bottlenecks, handoffs, and waste\u003c/li\u003e\n\u003cli\u003eValue Stream Mapping (VSM) in tech focuses — amongst others — on lead time, process time, and percent complete/accurate (%C/A) at each step\u003c/li\u003e\n\u003cli\u003eExample: A 30-person engineering team reduced delivery lead time by 45% and cut process steps from 14 to 6 using VSM and 7 PDCA initiatives\u003c/li\u003e\n\u003cli\u003eThe 5-step approach: Learn Lean techniques → Map “As Is” → Formulate improvements → Create “To Be” → Align on action plan\u003c/li\u003e\n\u003cli\u003eVSM builds lasting capability; teams equipped with Lean techniques proactively surface and resolve delivery issues\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003ch2 id=\"what-is-a-value-stream\"\u003e\u003cstrong\u003eWhat is a Value Stream?\u003c/strong\u003e\u003c/h2\u003e\n\u003ch3 id=\"traditional-lean-management-definition\"\u003e\u003cstrong\u003eTraditional Lean Management Definition\u003c/strong\u003e\u003c/h3\u003e\n\u003cp\u003eA value stream encompasses the complete sequence of activities, both value-adding and non-value-adding, required to bring a product or service from its initial conception to the final delivery to the customer.\u003c/p\u003e","title":"Value Stream Mapping for Software Teams: A Complete Guide With Examples"},{"content":" KEY TAKEAWAYS The PDCA Cycle (Plan-Do-Check-Act) applies the scientific method to problem-solving: form a hypothesis, test it, measure results, standardize or adjust PDCA and the Deming Cycle are used interchangeably, though Deming himself preferred PDSA (Plan-Do-Study-Act) and called it the “Shewhart Cycle” Example: A 31-person development team at a bank reduced defects from 93 to 8 (-91%) using better unit-testing, visual management, daily flash meetings, and a developer checklist Example: A QA team reduced false bug reports from 24% to 4% (-83%) using an Andon help signal system and targeted Dojo training Put PDCA into practice → The A3 report is PDCA on a single page. Download the free A3 Problem-Solving Template and start your first cycle.\nDownload the Free Template →\nThe PDCA Cycle (Plan-Do-Check-Act) is a four-step iterative method for continuous improvement, rooted in the scientific method. Originally developed by Walter Shewhart and popularized by W. Edwards Deming, PDCA provides a structured approach to problem-solving that generates organizational knowledge while driving measurable results.\nWhat is the PDCA Cycle? The PDCA cycle follows the steps of the scientific method. Starting with a problem formulated as a performance gap: “Plan” develops a causal hypothesis and an experimental resolution approach; “Do” conducts the experiment; “Check” collects the measurements; “Act” interprets the results and perpetuates the now-appropriate actions.\nHere’s how each step works:\nPlan In the “Plan” step, the owner studies a problem or opportunity in depth to understand it from as many points of view as possible. He analyzes it (quantitatively, if possible) to find the root causes, develop one or more ideas to resolve the problem or seize the opportunity, and draw up an implementation plan. The latter implies a prediction as an outcome of the resolution.\nDo In the “Do” step, the stakeholders implement the plan as quickly and carefully as possible. This is the experimental phase where the proposed countermeasures are tested on a small scale before broader rollout.\nCheck During the “Check” phase, the effects of the previous implementation are measured and compared with the initial target or prediction. This step validates whether the hypothesis was correct and the countermeasures were effective.\nAct The “Act” step refers to establishing the new process, solution, or system as standard if the results are acceptable, or taking corrective action if they are not. If successful, the improvement becomes the new baseline for future cycles.\nOrigin of PDCA PDCA is a reformulation by Japanese managers of the cycle devised by mathematician W. Edwards Deming. This cycle is known as PDSA (Plan – Do – Study – Act). There is a significant difference between the PDCA and Deming’s PDSA: Deming emphasized “Study” over “Check” because he wanted practitioners to deeply analyze results and learn from them, not merely verify whether targets were met.\nPracticing a systematic problem-solving approach generates knowledge for continuously improving a product or service. It’s also what makes it a tool for personal development.\nShewhart developed the original cycle at Bell Labs (1920s-30s) Deming refined it and brought it to Japan (1950s) The naming nuance: Deming actually preferred PDSA (Plan-Do-Study-Act) and called it the “Shewhart Cycle.” The Japanese adapted it to PDCA, and others started calling it the “Deming Cycle” in his honor. Today, PDCA Cycle and Deming Cycle are used interchangeably, though purists note the distinction. Example 1: Reducing Software Defects by 91% This example demonstrates how a software development team at a major bank used PDCA to dramatically improve software quality.\nContext A team of 31 developers and their managers at a large banking group faced a quality crisis. The CIO’s ambition was clear: deliver defect-free software, on time, every time. But the team was shipping code with 93 defects per release cycle, and only 9% of project milestones were delivered on schedule.\nPlan Problem Statement: 93 defects per release cycle, far exceeding the target of near-zero defects for banking software where reliability is critical.\nRoot Cause Analysis: By observing the development workflow and analyzing defect patterns, the manager identified several root causes:\nLack of visibility: Ongoing developments and incidents weren’t visible to the team or management. Problems festered until they became critical. No daily planning discipline: Without a daily production plan, developers worked reactively rather than proactively, missing deadlines and introducing rushed code. Delayed problem resolution: Issues discovered during development weren’t addressed immediately; they accumulated and compounded. Poor unit test quality: Developers submitted code with inadequate test coverage, allowing defects to escape into later stages. Countermeasures:\nMake all developments and incidents visible through visual management boards Implement a daily production plan to meet deadlines Identify and resolve problems throughout the day using PDCA thinking Hold daily flash meetings to surface blockers Run a team PDCA specifically to improve unit test quality Create and distribute a developer checklist for IT projects Do The team implemented a multi-pronged approach over three months:\nVisual management boards were installed showing all active developments, their status, and any blocking incidents making problems impossible to ignore. Daily flash meetings (brief stand-ups) were introduced so the team could surface and assign blockers before they escalated. A dedicated PDCA cycle on unit testing was run as a team exercise, analyzing why tests were inadequate and implementing improvements to test practices. A developer checklist was created and distributed, standardizing quality gates that every piece of code had to pass before submission. Check After three months, the results were dramatic:\nDefects dropped from 93 to 8: a 91% reduction On-time milestone delivery improved from 9% to 100% Customer satisfaction rose from 7/10 to 8/10 The defect reduction validated that the root causes had been correctly identified: visibility, daily discipline, and unit test quality were indeed the drivers of poor quality.\nAct Based on the results, the team standardized:\nPermanent visual management: The boards became a fixture, continuously updated and reviewed Daily flash meetings: The brief daily sync became non-negotiable team practice Developer checklist: Incorporated into the team’s Definition of Done for all projects Ongoing PDCA practice: The team adopted PDCA as their standard approach to addressing new problems as they emerged Want to run a PDCA like this with your team? The A3 template gives you the structure — problem, root causes, countermeasures, results, all on one page.\nGet the Free A3 Template →\nExample 2: Reducing False Anomalies by 83% This case study shows how a web application testing team used PDCA to dramatically reduce wasted effort caused by false bug reports.\nContext A team of dedicated manual testers was validating a web application, receiving new builds after each development sprint. After implementing visual management boards and performance indicators, the manager discovered a troubling metric: 24% of reported anomalies were false positives, meaning bugs that weren’t actually bugs. This wasted developer time investigating non-issues and damaged the testing team’s credibility.\nPlan Problem Statement: 24% of declared anomalies are not real defects.\nRoot Cause Analysis: The team observed false anomalies one by one, going down to the actual gesture of each tester, and categorized them by frequency:\nFunctional misunderstanding (40%): Testers lacked sufficient knowledge of business rules → Root cause: knowledge gaps in functional training Wrong software version (30%): Testers worked on outdated builds → Root cause: no notification protocol when new versions were deployed Already known anomaly (20%): Testers reported bugs that were already logged → Root cause: siloed work organization Browser not reset (10%): Cached data caused unexpected behavior → Root cause: no standard browser configuration Countermeasures:\nImplement an Andon system for testers Establish a protocol with the deployment team for version updates Standardize browser configuration across all testers Do The Andon System: Borrowed from Toyota’s manufacturing system, the team implemented a “help signal” process. Whenever a tester had functional or technical doubt, they would signal for help. A subject matter expert would immediately come to their workstation to unblock the situation before a false bug could be logged.\nAdditional implementations:\nCreated a communication protocol with the deployment team to notify testers of new version availability Validated a standard browser configuration and updated all testing prerequisites documentation Check After three months, the false anomaly rate dropped from 24% to 4%: a 83% reduction. The Andon system proved particularly effective: it not only resolved blockers dynamically but also revealed functional knowledge gaps in specific testers that could be addressed through targeted training.\nAct The team standardized two practices:\nPermanent Andon: The help signal system became a standard team practice Dojo Training: Each time a tester filed a false anomaly, they spent 20 minutes with a functional expert learning the correct business rules. This “learning from mistakes” approach turned errors into structured coaching opportunities. PDCA vs DMAIC: What’s the Difference? Both PDCA and DMAIC (Define-Measure-Analyze-Improve-Control) are structured problem-solving methodologies, but they differ in scope and application:\nPDCA is simpler (4 steps), more flexible, and designed for iterative, continuous improvement. It works well for smaller problems and fostering a culture of daily problem-solving. DMAIC is more rigorous (5 steps), data-intensive, and suited for complex, large-scale projects. It’s the core methodology of Six Sigma and requires statistical analysis expertise. Think of PDCA as a lightweight, daily tool that anyone can use, while DMAIC is a heavyweight methodology for projects requiring deep statistical analysis. Many organizations use PDCA for rapid improvement cycles and escalate to DMAIC when problems are complex or high-stakes.\nStart Your First PDCA Cycle Today. The A3 report puts the entire PDCA cycle on a single page: problem definition, root cause analysis, countermeasures, and results. It’s the same method behind the case studies above.\nDownload the Free A3 Template →\nConclusion PDCA is simple: four steps that anyone can understand, yet remarkably powerful when practiced rigorously. The strength is discipline: the discipline to define problems with data, test hypotheses before full implementation, measure results objectively, and standardize what works.\nAs both examples demonstrate, PDCA delivers measurable results (91% defect reduction, 83% reduction in false anomalies) while building organizational capability. Each cycle generates knowledge that makes the next cycle more effective. Teams that master PDCA solve problems faster and learn from every cycle.\nFrequently Asked Questions What does PDCA stand for? PDCA stands for Plan-Do-Check-Act. It’s also known as the Deming Cycle, Deming Wheel, or Shewhart Cycle, named after the statisticians who developed and popularized it.\nWhat is the difference between PDCA and PDSA? PDSA (Plan-Do-Study-Act) was Deming’s preferred terminology. He emphasized “Study” over “Check” because he wanted practitioners to deeply analyze and learn from results, not just verify whether targets were met. PDCA, popularized by Japanese managers, uses “Check” but the intent is similar. In practice, both cycles follow the same scientific method approach.\nHow long should a PDCA cycle take? PDCA cycles should be as short as possible while still being meaningful. Simple problems might cycle in days or weeks; complex problems might require months. The key is rapid iteration—it’s better to run multiple short cycles, learning and adjusting each time, than to spend months planning a “perfect” solution.\nCan PDCA be used for software development? Yes. PDCA aligns naturally with agile methodologies. Sprint retrospectives are essentially “Check” and “Act” phases. Teams can use PDCA to improve development processes, reduce defects, optimize CI/CD pipelines, and enhance developer experience. The examples in this article demonstrate PDCA applied to software testing teams.\nWhat’s the relationship between PDCA and A3 Problem-Solving? A3 is essentially a structured PDCA documented on a single A3-sized sheet of paper. It provides a visual template that guides teams through the PDCA steps while creating a communication artifact. A3 forces disciplined thinking by limiting space and requiring clear, concise documentation of each phase.\nWhat if the Check phase shows the solution didn’t work? That’s expected and valuable. PDCA treats experiments as hypothesis tests, some will fail. If results don’t meet expectations, return to Plan with the new knowledge gained. Ask: Was the root cause analysis correct? Were countermeasures appropriate? What did we learn? Failed cycles still generate organizational learning, which is a core purpose of PDCA.\nHow does PDCA relate to Kaizen? Kaizen is the philosophy of continuous improvement; PDCA is the method for achieving it. Kaizen establishes the mindset that everything can be improved incrementally, while PDCA provides the structured approach for actually making those improvements happen systematically.\nIs the PDCA Cycle the same as the Deming Cycle? Yes, the terms are used interchangeably today. However, there’s a subtle historical distinction: Deming himself preferred PDSA (Plan-Do-Study-Act) and called it the “Shewhart Cycle” to credit his mentor Walter Shewhart. The Japanese adapted it to PDCA in 1951, and others began calling it the “Deming Cycle” in his honor. The key difference is that “Study” emphasizes understanding why something worked, while “Check” focuses on whether it worked. In practice, both versions follow the same iterative improvement logic.\n","permalink":"https://leantechpro.com/the-pdca-cycle-deming-cycle-a-complete-guide-with-examples/","summary":"\u003cdiv class=\"key-takeaways\"\u003e\n\u003ch2 id=\"key-takeaways\"\u003eKEY TAKEAWAYS\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eThe PDCA Cycle (Plan-Do-Check-Act) applies the scientific method to problem-solving: form a hypothesis, test it, measure results, standardize or adjust\u003c/li\u003e\n\u003cli\u003ePDCA and the Deming Cycle are used interchangeably, though Deming himself preferred PDSA (Plan-Do-Study-Act) and called it the “Shewhart Cycle”\u003c/li\u003e\n\u003cli\u003eExample: A 31-person development team at a bank reduced defects from 93 to 8 (-91%) using better unit-testing, visual management, daily flash meetings, and a developer checklist\u003c/li\u003e\n\u003cli\u003eExample: A QA team reduced false bug reports from 24% to 4% (-83%) using an Andon help signal system and targeted Dojo training\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003cdiv class=\"key-takeaways\"\u003e\n\u003cp\u003e\u003cstrong\u003ePut PDCA into practice →\u003c/strong\u003e The A3 report is PDCA on a single page. Download the free A3 Problem-Solving Template and start your first cycle.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://jlcossi.activehosted.com/f/49\" class=\"button primary\" target=\"_blank\"\u003eDownload the Free Template →\u003c/a\u003e\u003c/p\u003e\n\u003c/div\u003e","title":"The PDCA Cycle (Deming Cycle): A Complete Guide With Examples"},{"content":" KEY TAKEAWAYS A3 Problem Solving is a structured one-page method that forces clarity: define the problem, find root causes, implement countermeasures, and confirm results. Successful A3 implementation requires pilot projects, leadership buy-in, and integration into existing team rituals — not a top-down rollout. A tech support team used A3 to eliminate a 145-ticket backlog in 2 months, boosting productivity 72% and customer satisfaction 35%. A tech support team cleared a 145-ticket backlog in 2 months. Here’s the one-page method that made it happen.\nDownload Your FREE A3 Problem-Solving Template\nDownload →\nWhat Is A3 Thinking? A3 Thinking is a mindset and methodology rooted in Lean principles, developed by Toyota. It emphasizes structured problem-solving and continuous improvement through visualization on a single page.\nKey aspects of A3 Thinking:\nScientific approach: Hypothesize, experiment, and adjust based on outcomes. Visualization: Capture problems, analysis, and solutions on one A3-sized sheet. Collaboration: Engage everyone close to the problem in finding solutions. Continuous learning: Reflect and learn from both successes and failures. A3 Thinking goes beyond analysis. It transitions problem-solving into concrete actions on the ground, striving for deep understanding and sustainable solutions.\nWhat Is A3 Problem Solving? A3 Problem Solving is the practical application of A3 Thinking. It follows a structured process documented on an A3-sized report (11 x 17 inches) to systematically address specific issues.\nThe method gets its name from Toyota’s belief: if you can’t explain a problem on a single sheet of paper, you don’t understand it well enough.\nThe A3 report leverages the Plan-Do-Check-Act (PDCA) cycle at its core.\nA3 problem-solving Structure A3 Problem Solving follows seven sections:\nBackground: here, the author documents any contextual information relevant to understanding the extent and the importance of solving the problem. For a business context, it is essential to clearly explain how the problem to solve relates to the company’s goals. It is also crucial to adapt the information there to the expected audience. Current Situation (or Current Condition): I recommend showing quantitative data about the current performance, such as process maps or metrics. Visual representations like charts or tables are instrumental. Sharing the “Current Situation” is about conveying an understanding grounded in facts regarding the business problem. Goal (or Target): it means a measurable objective, starting from the current performance. Setting a goal here is about acknowledging the success at the end of the problem-solving. The gap between the current situation (section 2) and the goal (section 3) is your problem statement. The next section shows you how to write one. Root Cause Analysis: it is about investigating until explicitly revealing the source of the problem. To find the root causes without ambiguity, the author may use different approaches like the 5 Whys. Countermeasures (or Recommendations): they are an outline of straightforward actions to address all the previously identified root causes. Here, we need each action’s owner, target date, and local result. Results (or Effect Confirmation): this section is related to the “check” we have in the PDCA. Here, we see the extent of any remaining part of the problem compared to the Current Situation. It is the answer to the question: did we eliminate the problem? Follow-up actions: this part reflects our “Act” step in a PDCA. The author has to be clear on any additional modifications to implement. It is also about expliciting any actions to sustain the achieved results. A3 problem-solving example How to Write a Data-Driven Problem Statement A mid-sized tech company had a pattern: deadlines kept slipping. The CTO called an all-hands to “reduce time-to-market.” The team spent two hours brainstorming solutions: new tools, fewer meetings, more developers. Nobody had measured where the delays actually came from.\nWeeks later, the initiative lost steam. Deadlines kept slipping.\nA problem statement is not a description of a problem. It is a measured gap between the current state and the target state. Current minus target. That is the problem.\nIf you cannot state that gap in numbers, you do not have a problem yet. You have a feeling.\nObserve Before You Write Most teams skip this step. They sit in a room and write a problem statement from memory, from assumptions, from what they think is happening.\nGo to the work. Watch it. Count it. Time it. A problem statement built from observation will survive root cause analysis. One built from assumptions will not.\nI recommend writing the problem statement at the end of the Current Situation section of your A3, after you have gathered the data, not before.\nThree Examples That Work Example 1: Sales revenue\nBackground: Current quarter revenue is $2M. Target is $2.5M. Problem statement: Revenue for the quarter is $2M, down from the expected $2.5M. A3 title: Increase sales revenue from $2M to $2.5M next quarter. Example 2: Time-to-market\nBackground: The team builds personal finance apps. The 2023 time-to-market stretched to four months. The standard is three. Problem statement: In 2023, time-to-market was four months instead of three. A3 title: Reduce time-to-market to three months by the end of 2024. Example 3: Infrastructure incidents\nBackground: The IT team has logged one infrastructure incident per month for six months. Problem statement: We have had one infrastructure incident per month for the last six months. A3 title: Eliminate all infrastructure incidents by year-end. Notice the pattern. No adjectives. No “significant delays” or “poor quality.” Just numbers.\nProblem Statement vs A3 Title The two are often confused. The problem statement measures the gap. The A3 title states the commitment to close it. One describes the current failure. The other declares the target, which is the ambition.\nHow to implement A3 I witnessed an A3 implementation in a large IT department a few years ago. Initially, it seemed promising. The company faced increasing quality issues – incidents – over all the business software applications.\nAfter unsuccessful approaches, the CIO decided to roll out A3 problem-solving to address this quality issue. Each of his direct reports will conduct an A3 problem-solving and then gradually scale it across his department.\nHowever, things didn’t go as planned. Despite the enthusiasm from the CIO, the managers he had as direct reports were skeptical and overwhelmed. The A3 reports, meant to drive explicit action, became more of a box-ticking exercise than a true problem-solving tool. Without sufficient training or support, operational teams struggled to understand the methodology, leading to confusion rather than clarity.\nMoreover, the CIO failed to align A3 practices with their employee development goals properly. People saw the initiative as an extra task rather than an opportunity to improve skills or advance their careers. As a result, the effort lost momentum, and A3 was eventually abandoned after only a few months.\nBased on my experience, I can tell you that this failure didn’t come from a lack of potential but from missteps in execution. The outcome could have been very different if these foundational elements had been in place.\nKey Lessons Learned Clear communication is essential for successful implementation. Adequate training and support prevent the process from becoming a box-ticking exercise. Aligning A3 practices with employee development goals can transform challenges into opportunities. Armed with these insights, here are several strategies that can help you secure stakeholder buy-in and drive meaningful results with A3 Problem-Solving.\nA3 Implementation – Key points Properly introduce the approach As for any new way of doing things for any organization, you must explain A3 Problem-Solving and why it is crucial for your organization. I also recommend sharing examples of A3 success stories from other companies. Their experience should include the specific benefits observed, such as cost reduction, better collaboration, faster problem-solving, and the challenges people face.\nAlign A3 practice with people development goals Every company has clear objectives for developing its workforce. The methodology builds capabilities for people development. So, the point for you as a leader is to be explicit about how your colleagues will grow while driving organizational improvements. It is essential to position A3 practice as both a performance improvement and professional development tool. More specifically, you can connect the problem-solving methodology to the company’s strategy for preparing employees for current and future roles.\nShow a real business impact First, you need to identify one or more problems to solve as a bootstrap to introduce A3 Problem-Solving. This point is about connecting the problem to solve to key existing company metrics related to safety, people’s well-being at work, delivery quality, cost, and customer satisfaction. This point is also about aligning the problem – to solve – with the company goals.\nConduct a pilot first Test the approach with a small team or a project before a full rollout. You create the opportunity for everyone to learn and adapt. The pioneers might become ambassadors by sharing their experiences and results within the organization.\nInclude A3s into existing processes To help establish the practice, I recommend including it in the current meetings or rituals such as project debriefs, weekly team meetings, and performance reviews. A team member could share his ongoing A3 Problem-Solving during project debriefs or team meetings. A performance review offers the opportunity to identify new problem-solving or act on the results of previous ones.\nA new practice requires change management. Anchoring it into well-known rituals is a good way of starting.\nAdjust along the way Using the approach in an organization requires rituals like sharing the progress, involving stakeholders in observations, and implementing sustainable changes as an outcome. But every organization is different. You must be ready to tweak the approach based on feedback or observations. Do you have daily, weekly, or monthly rituals? Who should attend? It all depends on your ambition and the specificities of your organization.\nIn addition, ensure opportunities for all stakeholders to reflect on what is working and what is not and adapt the implementation accordingly.\nEnsure ongoing support The experience shows that consistent coaching and support are essential to implementing A3 problem-solving in organizations. As for any new practices, it is crucial to make subject matter experts available to answer people’s questions. Monitor your organization’s problem-solving maturity and adjust support as needed.\nIn addition to those strategies, I would recommend additional vital points, significantly when you are scaling the approach throughout the organization:\nTrain facilitators: they should coach your colleagues or employees throughout the process. Set implementation goals: in a number A3 report completed in a timeframe or the money gained for the company, you must track progress and adoption meaningfully. Incentivize the usage: tying the usage and results to performance reviews and awards. Be realistic on timelines: the adoption of new practices used to take time. You have to be realistic about the expectations and pacing. Engage middle management: develop and understand their priorities to get their buying and input. It would be best if you had their support to drive engagement throughout the organization. Looking back at my opening story of that failed A3 implementation, success was within reach. The CIO had the right goal but missed crucial steps.\nTo properly introduce A3 Problem-Solving, take the required time upfront to educate, generate buy-in, learn from a pilot, and build enthusiasm before the rollout begins.\nThat IT department could have solved their quality issues by demonstrating clear business impact. They needed to embrace these strategies systematically.\nWhen done right, A3 changes how teams solve problems. The method sticks because it works.\nExample: Tech Support Case Study A tech support center with 12 Level 1 technicians was drowning in complaints. For six months, users had been demanding more reactivity and consistency. “Sometimes our issues are resolved fast, but generally, it’s taking too long!” was the common cry.\nDetermined to turn things around, we embarked on an A3 problem-solving journey. Our first shock came when we uncovered a staggering backlog of 145 tickets. The team failed to meet their 5-day Service Level Agreement (SLA).\nDuring the observation of the team at work, several causes became apparent:\nTechnicians cherry-picked tickets without any systematic distribution. Assignments did not consider the complexity of the tickets and the required technical competencies. Each tech maintained its local ticket backlog. No one monitored the overall backlog. Only four techs understood the service contract and level agreement. The variability in performance was striking. Some techs bounced between tickets, completing none by day’s end. The team leader lacked visibility into current performance, while techs wasted time gathering irrelevant ticket information.\nArmed with these facts from observation, I helped the team roll out targeted actions:\nConduct workshops on Voice of Customer, PDCA, standards, and visual management. Implement real-time ticket flow visualization. Create and display daily performance indicators. Establish a “dispatcher” role to process incoming tickets. Set daily productivity targets. Define a balanced mix of incoming and backlog tickets to resolve daily. Institute twice-daily check-ins with all techs. Within two months, the backlog vanished. This transformation boosted efficiency and reignited the team’s passion for their work.\nGet the same A3 template we used with this team → Download Free\nProductivity improvement Backlog elimination We saw a significant positive impact on client experience. As the team’s efficiency increased, so did customer satisfaction, demonstrating the far-reaching benefits of this systematic approach to problem-solving.\nCustomer satisfaction improvement Unveiling the Power of A3 In addition, my journey with this tech support team resonated with key benefits. Each played a crucial role in this team’s remarkable turnaround. These benefits form the basis for integrating the A3 Problem-Solving Method into business practices. I’ll draw from our tech support team’s success story to show their real-world impact.\nBenefits of A3 Data-driven problem identification. A3 revealed the true scope: 145-ticket backlog, five specific root causes. No guessing.\nRoot cause analysis that sticks. By fixing underlying issues like unsystematic assignments and lack of visibility, improvements lasted beyond the initial fix.\nTeam skill development. Workshops and new roles like “dispatcher” built capabilities while solving the immediate problem.\nProcess standardization. Only 4 of 12 techs knew the SLA. After A3, everyone understood expectations and procedures.\nSustainable results. The backlog vanished in two months. Productivity rose 72%. Customer satisfaction jumped 35%. The changes held.\nReady to try A3 with your team? Download The Free Template\nWhat’s Next for A3 A3 problem-solving stands on the cusp of a digital revolution. AI and machine learning will supercharge data analysis, uncovering hidden patterns and predicting outcomes with unprecedented accuracy. Tools will transform how teams visualize complex problems, making abstract concepts tangible. Cloud-based A3 platforms will enable real-time collaboration across global teams, breaking down geographical barriers. As sustainability takes center stage, A3 will increasingly incorporate environmental impact assessments into problem-solving frameworks. The rise of sensors across business processes will feed A3 processes with real-time data, allowing for more dynamic and responsive problem-solving.\nThese tools won’t replace human insight. They’ll make problem-solving faster and more precise.\nWhat A3 Delivered This tech support team’s transformation proves A3’s power: a 72% productivity boost, complete backlog elimination, and 35% higher customer satisfaction in just two months. Their success shows that with proper A3 implementation, any team can achieve similar breakthrough results.\nFrequently Asked Questions About A3 Problem-Solving What is an A3 report, and why is it called that? An A3 report is a one-page problem-solving document that follows the Plan-Do-Check-Act (PDCA) cycle. The name ‘A3’ comes from the international A3 paper size (11×17 inches). Toyota developed this method to fit on a single sheet of this size, which forces clarity and conciseness.\nHow is an A3 report different from other problem-solving methods? The A3 methodology differs from lengthy reports emphasizing direct observation and root cause analysis. It presents all information visually on a single page. It combines disciplined thinking with collaborative problem-solving in a structured format that promotes action.\nWho should own the A3 process in an organization? Anyone can initiate an A3 report. However, the most effective owner is someone directly connected to the problem who has the authority to implement changes. A team lead, supervisor, or manager could be responsible for the area experiencing issues.\nHow long should it take to complete an A3 report? The time varies based on the problem’s complexity. Simple A3 reports take a few days, while complex issues require several weeks of investigation and analysis. The focus should be on thoroughness rather than speed.\nCan A3 reports be used for all types of problems? A3 reports work best for concrete, measurable problems with clear metrics. They’re ideal for operational issues, quality concerns, and process inefficiencies. Abstract or highly subjective problems may require different approaches.\n","permalink":"https://leantechpro.com/a3-problem-solving-a-complete-guide-with-template-examples/","summary":"\u003cdiv class=\"key-takeaways\"\u003e\n\u003ch2 id=\"key-takeaways\"\u003eKEY TAKEAWAYS\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eA3 Problem Solving is a structured one-page method that forces clarity: define the problem, find root causes, implement countermeasures, and confirm results.\u003c/li\u003e\n\u003cli\u003eSuccessful A3 implementation requires pilot projects, leadership buy-in, and integration into existing team rituals — not a top-down rollout.\u003c/li\u003e\n\u003cli\u003eA tech support team used A3 to eliminate a 145-ticket backlog in 2 months, boosting productivity 72% and customer satisfaction 35%.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003cp\u003eA tech support team cleared a 145-ticket backlog in 2 months. Here’s the one-page method that made it happen.\u003c/p\u003e","title":"A3 Problem Solving: A Complete Guide (With Template \u0026 Examples)"},{"content":" KEY TAKEAWAYS Root Cause Analysis goes beyond symptoms to identify core issues – essential for preventing recurring problems and developing sustainable solutions. The RCA process requires methodical validation through observation and data, not assumptions or quick conclusions. A true root cause must meet specific criteria: prevent recurrence, drive systemic change, show clear evidence, and have broader organizational impact. Every morning, from 8 a.m. until noon, a Tech Leader and his team gather around the main accounting screen only to find that the transaction data was outdated. Although the system was designed to refresh the transaction list every hours, it only does so once every morning. This situation is causing a critical delay in decision-making and costing the company valuable time.\nRoot Cause Analysis in Action Frustrated and determined, Marc, experienced in Lean Tech, initiated a Root Cause Analysis session with his team. Together, they began peeling back the layers of the “why” using the 5 Whys method. They discovered that the middleware was only receiving data once a day because their external data provider, after a recent system upgrade, had switched to a daily schedule. Yet, the root of the issue wasn’t just about data timing. It was about the weak technical partnership with the external provider.\nRealizing that a stronger collaboration was needed, Marc reached out to the provider’s technical team. Through open discussions and joint troubleshooting, both sides agreed to implement a more robust integration strategy. This new partnership paved the way for hourly data updates, ensuring that Marc’s team had access to real-time financial insights. The change restored efficiency and reinforced the importance of continuous improvement and proactive problem-solving.\nThis story illustrates how a systematic approach to Root Cause Analysis can transform a frustrating daily challenge into a catalyst for strategic partnership and lasting improvement.\nUnderstanding Root Cause Analysis Root Cause Analysis (RCA) is a structured approach that goes beyond the symptoms of a problem. It leads to the source and core fact or event generating that problem.\nWe apply root cause analysis while solving problems. Indeed, effectively solving problems requires identifying and addressing their root causes. It is the only way of preventing the same problems from recurring and leading to long-lasting solutions.\nThe 5 Whys: A Deductive Root Cause Analysis Technique The 5 Whys method is one of the most effective RCA techniques. It consists of asking “why” at least five times until you reach the root cause of a problem. From experience, stopping at two or three “whys” does not lead to the actual root cause.\nKey points for using the 5 Whys:\nBe grounded in reality: At each level, go and see facts to verify it is a real cause — not an assumption. Trace back the causality chain: Work backwards to confirm that each cause directly generates the next. Adjust the depth: You may need more or fewer than five “whys” depending on the problem. Identifying root causes is not purely mental reasoning. Each hypothesis requires validation through observation or experimentation where the work happens.\nBelow is a process designed to help you effectively identify root causes.\nRoot Cause Analysis Process Prerequisites The problem has to be a performance gap and formulated accordingly. It requires a current and a target values or a prediction. It is also essential to differentiate the problem, its symptoms, and its impacts. Ensure the collection of all the relevant data about the problem. It may include performance metrics, process documentation, reports, or audit results. They help as sources of information while looking for the root causes. In Marc’s case, clearly identifying the performance gap—where the accounting system failed to update data hourly—and gathering relevant data (like middleware logs and update timestamps) were crucial steps in pinpointing the root cause.\nStep by step Formulate one or several causes hypothesis. It starts with formulating one or several answers to why we are having the problem. It is essential to look at the process. Indeed, the problem is happening at a working step. You may spot potential causes along the previous steps and as far as possible: input documents, materials, equipment, people know-how, and more. At this stage, you have to resist jumping to conclusions. We have one or more causes hypotheses because there is no tangible evidence of the actual causes. Use a root cause analysis framework. I recommend using the 5 Why’s, a deductive root cause analysis technique. It is an effective way to reach the root causes using a proven and structured approach. Check the causality chain created so far. In reverse order, analyze each root cause and evaluate how it can lead to the problem under resolution. Ensure the potential root causes are grounded in reality. You must accurately observe where things are happening or conduct experiments to check their relevancy. You may ensure that along the way, at steps 1 or 2. Root Cause Identification Checklist Identifying the root cause clearly is challenging, even with a simple process. Once you find a potential cause, use the checklist below for a detailed assessment.\nLead to prevent recurrence: addressing this cause will stop the problem recurrence in a sustainable way, for your organization – specifically. Should require systemic change: like a new way of doing things, value stream changes or adaptation, new rules and policies. Is fundamental to the problem: it means that without it, the problem would not exist. Have evidence – or fact – support: we see evidence showing that it is the primary factor leading to the problem. It is about leaning on facts. Lead to actions with broader impact: addressing this cause should cover all the multiple symptoms – or causes – we see so far. Example 1: Marc’s Case Study The initial situation: Every day from eight o’clock in the morning till noon, the main screen of our accounting software does not show up-to-date transactions. **The problem, as a performance gap: **The software is refreshing the transactions’ list once a day instead of every hour.\nWhy? – level 1: The database does not update with new data hourly.\nWhy? – level 2: The middleware only receives new data daily instead of hourly.\nWhy? – level 3: The external data provider now sends data once daily.\nWhy? – level 4: We have received no updates since our external partner upgraded their system.\nWhy? – level 5: We lack a method to develop and sustain a strong technical partnership with our external partner.\nSpecifically, our failure to establish and maintain a robust technical partnership with our external partner was a critical oversight that led to this problem. This scenario ultimately reveals a significant lack of know-how, which we consider as the root cause. Moreover, it touches upon every aspect of our root cause checklist.\nExample 2: E-Commerce Data Architecture A large e-commerce company notices a significant drop in website traffic and sales. The simple cause appears to be slow page load times. Let’s apply the 5 Whys.\nProblem: Website traffic and sales have dropped 30% over the past quarter.\nWhy? #1: Pages load too slowly, causing users to leave. Why? #2: Database queries take too long to execute. Why? #3: The database structure cannot handle current traffic volume. Why? #4: The data architecture was designed five years ago for 10x less traffic. Why? #5: No process exists to regularly review and update technical architecture. Root Cause: Lack of architectural review process.\nAddressing this root cause (implementing regular architecture reviews) solves multiple symptoms at once:\nInefficient database queries Overloaded servers during peak times Difficulty implementing new features Inconsistent user experience across devices This example demonstrates how a fundamental architectural issue can be the root cause of various performance problems. Fixing the root cause provides a lasting solution rather than treating each symptom individually.\nConclusion Marc’s experience demonstrates that when you combine a structured RCA process with continuous improvement, you can turn daily challenges into strategic opportunities.\nBy properly identifying performance gaps—like the outdated data issue—and methodically uncovering their root causes using the 5 Why’s, his team resolved the immediate problem. They also forged a stronger technical partnership that brought lasting solution.\nEmbracing Root Cause Analysis (RCA) as a habit empowers your organization to move beyond temporary fixes and drive enduring improvements.\n","permalink":"https://leantechpro.com/5-whys-root-cause-analysis-guide/","summary":"\u003cdiv class=\"key-takeaways\"\u003e\n\u003ch2 id=\"key-takeaways\"\u003eKEY TAKEAWAYS\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eRoot Cause Analysis goes beyond symptoms to identify core issues – essential for preventing recurring problems and developing sustainable solutions.\u003c/li\u003e\n\u003cli\u003eThe RCA process requires methodical validation through observation and data, not assumptions or quick conclusions.\u003c/li\u003e\n\u003cli\u003eA true root cause must meet specific criteria: prevent recurrence, drive systemic change, show clear evidence, and have broader organizational impact.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003cp\u003eEvery morning, from 8 a.m. until noon, a Tech Leader and his team gather around the main accounting screen only to find that the transaction data was outdated. Although the system was designed to refresh the transaction list every hours, it only does so once every morning. This situation is causing a critical delay in decision-making and costing the company valuable time.\u003c/p\u003e","title":"The 5 Whys: A Root Cause Analysis Guide (With Examples)"},{"content":" KEY TAKEAWAYS 88% of AI pilots fail to reach production. The problem is that teams lack the capability to see problems clearly and solve them systematically. Consultants deliver solutions, not capability. When they leave, the improvements fade. Teams need to own the method, not just the fix. Capability transfers through structured fade. Coaches must progressively withdraw from heavy guidance to not in the room, so teams build independence. Get the full framework →“The 12% Framework” explains what teams who ship AI to production do differently. Free PDF, 19 pages.\nDownload the 12% Framework →\nImagine a consultant helps a team reduce defects by 30%. He runs the problem-solving. He identifies root causes. He implements fixes. The team watches. Three months after he leaves, defect rates return to baseline. He never taught them how to conduct problem-solving. They had the solution but not the capability.\nThis pattern is the one killing your AI pilots. The technology works, leadership loves the demo, but six months later, it’s still a pilot.\nIDC research shows 88% of AI pilots never reach production. Teams lack the capability to see problems for what they are and tackle them systematically.\nThis framework solves that.\nWhy Pilots Stay Stuck McDonald’s partnered with IBM to deploy AI-powered voice ordering at over 100 drive-thrus. The demo worked. Three years later, they pulled the plug. The AI misheard orders, confused cars, added unwanted items. Accuracy hovered around 85%—but to save money over human workers, they needed 95%. The gap between demo success and operational success was never clearly defined.\nDuring a recent diagnostic, I observed a tech team deploying cloud infrastructure. I counted 14 handoffs, none documented. I saw permission bottlenecks, unclear ownership, siloed expertise, and manual copy-paste steps begging to be automated. These gaps don’t show up in deployment guides.\nMeasurement gaps. Process gaps. Knowledge gaps. Different symptoms, same disease.\nBanking software, government digital projects, energy operations—different domains, identical failures.\nNow I am seeing it with AI pilots.\nAs a Lean practitioner, I look past surface patterns to find root causes. Regarding AI pilots’ failure, nine common failure patterns emerge: data quality issues, integration problems, unclear objectives, organizational readiness gaps, hidden maintenance costs, implementation speed mismatches, technology-first thinking, failed internal builds, and adoption resistance. They collapse into two root causes:\n1. Teams lack scientific problem-solving capability They don’t establish baselines before optimizing. They can’t identify operational gaps through systematic observation. They end up chasing technology solutions without first understanding the underlying business problem. They deploy fixes without measuring impact. In short, the whole issue is a methodology gap.\n2. No capability transfer Consultants often deliver fixes without teaching the underlying problem-solving methodology. As a result, teams can watch experts pinpoint root causes and apply patches. Still, they never acquire the skills to replicate the process. When the consultants leave, the improvements fade because teams lack the capability to sustain or extend them.\nThese root causes feed each other. Teams lack problem-solving skills because nobody teaches them. Companies hire consultants to deliver solutions, not to build capability.\n**We turned this diagnosis into a framework.**Three components. Four case studies. A self-assessment to score your team.\nDownload The 12% Framework (Free PDF) →\nFrom Stuck to Production: A Lean Coaching Framework This framework comes from 13 years of operational transformation. It delivered 91% defect reduction in banking, 50% productivity gains in government, 68% on-time improvement in energy. Same methodology.\nNow applied to AI.\nThe framework has three components, each building a specific capability. The timeline depends on your team and your problem. What matters is the method, not the schedule. As a leader who commits to guiding rather than solving, you can run this framework with your own team.\nRunning a stuck AI pilot? [Book a 30-minute diagnostic call]. I’ll help you identify the first problem to tackle.\n1. See the Problem Before solving anything, your team must see what’s actually happening.\nMcDonald’s couldn’t see that 85% accuracy wasn’t enough. The cloud infrastructure team couldn’t see the 14 handoffs causing their bottlenecks. Both teams lacked the same skill: systematic observation.\nWhat the team does:\nGo where the work happens. Observe the AI system in use—not the architecture diagram, not the documentation, but what people actually do. Document every friction point, workaround, and handoff. Measure current state: latency, cost per query, error rates, adoption, business impact. With no number, you have no baseline. No baseline means no improvement. Distinguish symptoms from root causes. “Deployments are slow” is a symptom. Why are they slow? That’s the cause you need to tackle. Coach’s role: Ask questions. “What do you see? How do you know it is not ok? Who owns this?” Don’t diagnose for them. The moment you provide the answer, you’ve stolen the learning.\nWhat the team learns: How to see operational reality. The discipline of measuring before any change. The reflex to ask “what’s actually happening?” before “what should we build?”\n2. Solve with Rigor Address one problem at a time. Go through a complete cycle of reasoning. Avoid shortcuts to ensure rigorous problem-solving closes that gap.\nMcDonald’s implemented AI ordering without defining what success actually meant. 85% accuracy looked good—until they realized 95% was the threshold to beat human workers on cost. Rigorous problem-solving closes that gap.\nWhat the team does:\nSelect the single highest-impact problem from their observation. Justify with data, not intuition. Define the hypothesis before acting. What do we expect to happen? Why? How will we measure it? Build measurement before building the fix. If you can’t measure the impact, you’re not ready to implement. Implement the solution. Measure results against baseline. Did it work? By how much? Why or why not? Standardize what works. Document so anyone can repeat it. Coach’s role: Challenge the thinking at each step. “How do you know this is the biggest problem? What’s your evidence? What result do you expect? How will you verify?” Let them struggle. Intervene with questions, not answers.\nWhat the team learns: The complete improvement cycle: observe, hypothesize, implement, measure, standardize. Team members experience the discomfort of rigor. They know that measurement isn’t optional.\n3. Own the Method The consultant who reduced defects by 30% failed because the team watched instead of learned. When he left, the capability left with him.\nCapability transfer requires deliberate fade. This pattern comes from Training Within Industry (TWI), a methodology Toyota still uses today. It’s how capability actually transfers.\nWhat the team does:\nRepeat the cycle on the next problem. And the next. Each cycle, rely less on the coach, who is fading strategically. Reflect after each cycle: What’s becoming automatic? Where do we still struggle? Eventually, run the full cycle without methodology support. Coach’s role: Fade. First problem: heavy guidance and coaching. Second problem: answer questions only. Third problem: observe silently and debrief at the end. Fourth problem: not in the room.\nThe test: When the next AI initiative arrives, or the current one breaks, does the team reach out for the method?\nWhat the team learns: They own this. The methodology lives in them, not in documentation, not in the coach.\nWhat This Method Delivers A production-ready AI system with measured performance A team that sees problems through observation, not assumption A team that solves problems with rigor, not guesswork A team that sustains improvements because they own the method A repeatable capability your organization keeps, even when people leave The Real Shift Most advice tells you to align stakeholders, build infrastructure, and get executive buy-in. That’s not wrong. But it doesn’t address why pilots actually fail.\nPilots fail when teams can’t clearly see the problems, and therefore can’t solve them systematically. And when outside help walks away, the capability walks away with it.\nThis framework builds what’s missing: the skill to see, the rigor to solve, and the ownership to sustain.\nThat’s the difference between a pilot that stays stuck and a system that reaches production.\nNext Step Pick one stuck pilot and go to your teams to watch the actual work in action. Document what you see: the handoffs, the workarounds, the things nobody’s measuring.\nThen pick one problem. The biggest gap you observed. Define what success looks like. Measure before you fix. Measure after.\nOne full cycle teaches more than months of optimization theater.\nNeed help running your first cycle? I work with teams to move AI pilots from stuck to production. [Book a 30-minute diagnostic call] and we’ll identify what’s blocking yours.\n","permalink":"https://leantechpro.com/the-capability-gap-killing-your-ai-pilot/","summary":"\u003cdiv class=\"key-takeaways\"\u003e\n\u003ch2 id=\"key-takeaways\"\u003eKEY TAKEAWAYS\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e88% of AI pilots fail to reach production.\u003c/strong\u003e The problem is that teams lack the capability to see problems clearly and solve them systematically.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eConsultants deliver solutions, not capability.\u003c/strong\u003e When they leave, the improvements fade. Teams need to own the method, not just the fix.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCapability transfers through structured fade.\u003c/strong\u003e Coaches must progressively withdraw from heavy guidance to not in the room, so teams build independence.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003cdiv class=\"key-takeaways\"\u003e\n\u003cp\u003e\u003cstrong\u003eGet the full framework →\u003c/strong\u003e“The 12% Framework” explains what teams who ship AI to production do differently. Free PDF, 19 pages.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://jlcossi.activehosted.com/f/61\" class=\"button primary\" target=\"_blank\"\u003eDownload the 12% Framework →\u003c/a\u003e\u003c/p\u003e\n\u003c/div\u003e","title":"Why 88% of AI Pilots Fail to Reach Production"},{"content":" KEY TAKEAWAYS When everything is marked urgent, delivery stalls. Without real prioritization based on capacity, teams drown in work and nothing flows. Good tools and talent can’t fix broken systems. AI and fast coding mean little if reviews, testing, and handoffs stay overloaded or unmanaged. Leaders must design for flow, not push for speed. The real shift comes from limiting WIP, creating pull, and making the delivery system visible and stable. Does Your Team Have the Same Problem? Take the 3-minute Delivery Flow Scorecard to find out:\nYour team’s flow score (0-100) Whether you’re pushing or pulling work Your #1 hidden bottleneck Find Your Team’s #1 Bottleneck (Free) →\nWhen Everything’s Urgent, Nothing Flows Your team works hard. You’ve hired good engineers. You’ve got clear goals and a growing list of important initiatives. So why does delivery still feel like a struggle?\nYou look at the backlog. Dozens of items marked as “top priority.” Pressure comes from all sides: product, sales, leadership. Everyone agrees: this needs to ship now.\nPriority pile-Up problem The team does what they can. They split their time, juggle requests, and try to move everything forward at once. But progress stays slow. Features take weeks. Reviews pile up. Bugs resurface, and the morale dips.\nAt first, you assume it’s a focus issue. Or people aren’t working fast enough. But that’s not it.\nThe real problem is deeper: you’re pushing more work into the system than it can handle. And when that happens, even your most essential priorities get stuck.\nWhen everything is urgent, nothing flows.\nYou do not have a team problem. It’s a system design problem. And until you fix the flow, no level of prioritization will save you.\nThe Problem With “Top Priority” Thinking Most leaders assume prioritization means ranking what matters most. So they ask:\n“What’s our top priority this quarter?”\nThen they align the teams, assign owners, and expect results to follow.\nBut here’s what happens next.\nA new opportunity pops up, and now it’s a new top priority.\nAn executive changes their mind, and now this item needs to ship first.\nA customer escalates, and suddenly everything moves to urgent.\nThe backlog stops being a plan. It becomes a pile of number-one priorities, none of which can move.\nThis situation creates chaos. Teams lose focus. Context switches multiply. Reviews slow down. And delivery grinds. In Lean, we call this push: shoving work into the system based on wishful thinking, not capacity. It’s like pouring more water into a blocked pipe. You don’t get flow. You get overflow.\nTrue prioritization isn’t a ranking exercise. It’s instead about choosing what to say yes to based on how much your system can actually handle. And that’s the part most teams miss.\nPush vs PULL system comparison What Happens When You Ignore Capacity When leaders ignore capacity, everything looks like a prioritization issue until the system breaks.\nWork stacks up. Teams say yes to more than they can handle. Urgent items jump the line. Progress slows because teams start too much, finish too little, and keep pushing without clearing space.\nThis overload hides in plain sight:\nTasks get started but never finish. Reviews pile up because no one has time to do them well. Testers fall behind as the dev team keeps pushing more code. Every group operates at full speed, but nothing flows. People feel stretched. Yet delivery doesn’t improve.\nIgnoring capacity leads to unmanaged work-in-progress. It breaks flow, creates invisible bottlenecks, and makes every delay harder to track. Teams feel reactive, jumping from task to task without finishing anything properly.\nThe damage grows silently. Instead of finishing what matters, the system collapses under the weight of too much started work.\nThe Illusion of Progress Teams often point to activity as proof of progress. Backlogs move. Sprints fill. New features roll out. But when you zoom out, the real value still lags behind. It looks like things are moving. But delivery doesn’t improve. Just more effort, less progress.\nManagers see teams using new tools. AI writes code faster. Developers push more commits. On paper, everything moves. But users still wait. Bugs still come back. Releases still slip.\nThis is the illusion.\nActivity increases. But flow doesn’t. Because the bottlenecks never changed.\nCode now moves faster into a jammed review queue. Or waits for unclear decisions. Or gets rewritten because the original scope shifted midstream. In Lean, we’d say the local efficiency improved while global performance stayed stuck.\nThe more tools we add, the more this illusion spreads. Speed at one step hides the friction across the whole path.\nGetting more done isn’t the goal. Getting value through the system is. Until that happens, the system hasn’t improved. It’s just working harder to stay in place.\nA Real-World Example: Too Much Priority, Not Enough Flow One product team I worked with had strong engineers and experienced Scrum Masters. They followed Agile ceremonies by the book. The team packed each sprint with user stories, often 15 to 20 per two-week cycle.\nThe backlog was always full. Stakeholders pushed for new features. Everything was urgent. Everything was top priority. So the team tried to deliver more.\nBy mid-sprint, you’d see 12 stories “in progress.” Developers jumped from one to another. Reviews piled up. Testers received five stories at once on the last day. Bugs crept in. Nothing got finished early or properly.\nAt the end of the sprint, they often carried over 40% of their stories. And the ones marked “done” came with rework a week later. But nobody had time to stop. Everyone was busy. They thought: “We just need to try harder.”\nThe problem wasn’t effort. It wasn’t skills. It was a system running without limits.\nNo WIP limits. No pull from testers. No sequencing based on capacity. Just story after story pushed through the pipe like pouring concrete into a blocked drain.\nVelocity charts showed activity. But the release board showed chaos. Code sat idle, waiting for tests. QA scrambled, then missed bugs. Reviewers were overloaded. The cycle time kept growing.\nThey were building faster, but delivering slower.\nFrom Chaos to Flow: The Impact of WIP Limits Only when they introduced strict WIP limits (no more than 2 stories in progress per dev) and testers pulled stories only when ready, did things change. Stories got smaller. Reviews happened earlier. Feedback came faster. Delivery stabilized.\nThey shipped less, but delivered more.\nDoes Your Team Have the Same Problem? This team didn’t know their system was broken until they measured it.\nTake the 3-minute Delivery Flow Scorecard to find out:\nYour team’s flow score (0-100) Whether you’re pushing or pulling work Your #1 hidden bottleneck Find Your Team’s #1 Bottleneck (Free) →\nThat’s the shift. Not from slow to fast. But from chaotic to flowing.\nHow to Fix It: From Push to Pull The problem isn’t too many priorities. It’s that everything gets pushed at once.\nInstead of reacting to the latest fire or request, teams need a system that lets them pull work at the right pace and based on their real capacity.\nHere’s how to do that in practice:\n1. Make capacity visible Track how many items your team can handle at once without overload. Velocity charts don’t show how work flows. What matters is seeing how many items move from start to finish without stalling.\n2. Set WIP limits This part is not optional. It’s the only way to create space for focus. When too much is in progress, nothing gets done. Limit the number of active stories or tickets. Finish one task, then pull the next.\n3. Create real pull signals Instead of planning every sprint upfront with 20 items, allow the team to pull the next piece of work only when they’re ready. A Kanban system works well here, but the principle matters more than the tool.\n4. Prioritize based on constraints Don’t just stack up what’s “important.” Look at where your system is constrained. Is QA the bottleneck? Focus there. Is review time killing flow? Solve that before adding new features.\n5. Review flow, not effort Ask, “Where does work sit idle?” more often than “How hard are people working?” Shift the conversation from effort to throughput. From speed to stability.\nThis shift from push to pull isn’t about working less. It’s about working smarter. It aligns delivery with capacity, prevents chaos, and creates real progress, not just motion.\nLeadership Means Seeing the System When delivery stalls, it’s tempting to blame execution. The team may not be fast enough. They may need better tools. But more often, the issue runs deeper.\nTeams don’t fail because they lack skills or effort. They fail because the system they work in breaks flow.\nAs a leader, your job is not to push harder. It’s to see the system. To understand where the real constraints live: overload, hidden queues, shifting priorities, unclear ownership.\nGreat teams thrive when flow is clear, when they know what to do, when to do it, and how to work together without friction. That’s not a matter of motivation. It’s a matter of design.\nSo if everything is a top priority but nothing moves, step back. Don’t ask how to go faster. Ask what’s blocking flow. Then fix that first.\nBecause leadership in tech isn’t about more speed, it’s about building systems where good people can succeed.\nSelf-Check: Is Your Team Aligned With Capacity and Flow? If you’re unsure where the real issues lie, start here.\nUse this quick diagnostic to step back from daily operations and see whether your delivery system is helping or silently hurting your team’s performance.\n✅ Can your team see all the work in progress?\n✅ Are you limiting WIP or just piling on more tasks?\n✅ Do priorities shift frequently, breaking flow?\n✅ Are code reviews and feedback loops fast and predictable?\n✅ Does work get stuck between handoffs or stages?\n✅ Are delivery bottlenecks discussed and addressed regularly?\nSuppose you can’t check most of these. In that case, your delivery problems likely aren’t about individual performance. They’re rooted in how work flows.\nFrequently Asked Questions About Prioritization, Capacity, and Delivery Flow Q: We already prioritize work. Why does delivery still lag? A: Because prioritization without flow control is just wishful thinking. If you overload the system, even top-priority items get stuck. Flow always wins over wish lists.\nQ: What does ‘push’ vs. ‘pull’ mean in practice? A: “Push” means starting work because someone said it’s urgent, regardless of capacity. “Pull” means starting work only when there’s room, so nothing piles up. Pull creates flow. Push creates chaos.\nQ: Aren’t WIP limits slowing us down? A: No. WIP limits feel slower at first, but lead to faster delivery. They reduce context switching, improve focus, and prevent work from idling in queues.\nQ: We use Scrum. Does this still apply? A: Yes. Even within Scrum, you can overload sprints and break flow. WIP limits, visible queues, and real pull signals work across all frameworks. Scrum is not immune to push thinking.\nQ: What’s the first thing I should do as a leader? A: Step back. Look at where work gets stuck. Make flow visible. Don’t start by pushing for speed. Start by seeing the system that shapes how your team works.\n","permalink":"https://leantechpro.com/the-top-priority-problem-why-engineering-teams-struggle-with-delivery/","summary":"\u003cdiv class=\"key-takeaways\"\u003e\n\u003ch2 id=\"key-takeaways\"\u003eKEY TAKEAWAYS\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eWhen everything is marked urgent, delivery stalls.\u003c/strong\u003e Without real prioritization based on capacity, teams drown in work and nothing flows.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eGood tools and talent can’t fix broken systems.\u003c/strong\u003e AI and fast coding mean little if reviews, testing, and handoffs stay overloaded or unmanaged.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLeaders must design for flow, not push for speed.\u003c/strong\u003e The real shift comes from limiting WIP, creating pull, and making the delivery system visible and stable.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003cdiv class=\"key-takeaways\"\u003e\n\u003ch3 id=\"does-your-team-have-the-same-problem\"\u003e\u003cstrong\u003eDoes Your Team Have the Same Problem?\u003c/strong\u003e\u003c/h3\u003e\n\u003cp\u003eTake the 3-minute Delivery Flow Scorecard to find out:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eYour team’s flow score (0-100)\u003c/li\u003e\n\u003cli\u003eWhether you’re pushing or pulling work\u003c/li\u003e\n\u003cli\u003eYour #1 hidden bottleneck\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://jlcossi.activehosted.com/f/59\" class=\"button primary\"\u003eFind Your Team’s #1 Bottleneck (Free) →\u003c/a\u003e\u003c/strong\u003e\u003c/p\u003e\n\u003c/div\u003e","title":"The ‘Top Priority’ Problem: Why Engineering Teams Struggle With Delivery"},{"content":" KEY TAKEAWAYS Better tools and smarter engineers won’t fix delivery if the system around them is broken. Most bottlenecks come from invisible delays, unclear ownership, and overloaded workflows—not from poor coding. AI accelerates output, but it also amplifies dysfunction. Without flow visibility, fast code creation leads to more rework, review delays, and misaligned priorities. Improving delivery doesn’t require a massive transformation. Start small: make work visible, limit WIP, and fix the handoffs. These simple changes create real, lasting impact. The Pain That Won’t Go Away You’ve hired competent developers. You’ve added AI tools to speed things up. You’ve upgraded your stack, improved your CI/CD, and given teams more autonomy.\nStill, something’s off.\nDelivery feels slow. Work piles up for review. Priorities shift mid-sprint. Bugs resurface. Even with all the improvements, the output doesn’t match expectations.\nYou start wondering:\n“Is it the team? The tools? Did we make the wrong calls?”\nThe truth is more complex to see.\nBecause what’s broken might not be in the code, or the people writing it.\nIt’s the system around them. The flow of work. The hidden rules. The gaps between decision and delivery.\nThis article isn’t about blaming developers. It’s about understanding why strong teams underperform when the system stays invisible, and how to fix that.\nThe Illusion of Progress: Why AI and Tools Aren’t Enough AI makes it easier to write code. Copilots suggest entire blocks. Tools automate repetitive tasks. At first, this feels like progress.\nBut look closer.\nThe team ships faster until the code hits review. Bugs still slip through, features stall. The backlog grows. Meetings multiply. Everyone’s busy, but nothing flows.\nThat’s the illusion.\nWe’ve sped up one part of the process, coding, without fixing the rest.\nPlanning remains unclear. Work bounces between people. Reviews drag on. Testing stays manual. Releases get delayed.\nSpeed at one step doesn’t fix a broken system. If anything, it makes the cracks show faster.\nTools and AI don’t solve delivery problems. They highlight them.\nAI Bottleneck – visualization The Real Bottlenecks in Delivery Systems When teams struggle to deliver, most people look at the surface: slow coding, poor estimates, missed deadlines. But the real problems sit deeper. They live in the system.\nHere’s what I keep seeing:\nWork isn’t visible. Teams don’t know what’s in progress, what’s stuck, or why. Too much in progress. Everyone is working on something, but nothing gets done. Handoffs create delays. Tasks bounce between people who lack shared context. Reviews and testing are bottlenecks. Code waits. Bugs reappear. Feedback comes too late. Priorities shift too often. Focus breaks. Delivery resets. None of this is about the quality of your engineers. It’s about how work moves, or does not, through your system.\nUntil you fix that, better tools won’t help. And AI will only create more output that can’t go anywhere.\nReal Story: Great People, Broken Flow invisible wait times – Feature delivery One team I worked with had brilliant developers, cloud engineers, and network engineers, in addition to top-tier tools. But every feature still took weeks to ship. Nothing was visible. Work sat idle between handoffs, reviews dragged on, and handovers stripped away context.\nEach group was efficient on its own, but no one saw the whole picture. Tickets moved, but value didn’t flow. A feature could sit three days waiting for a review, then another two waiting for deployment. No one tracked the idle time. No one owned the gaps.\nThe team wasn’t slow. The system was blind.\nIs Your System Blind Too? This team had great engineers and great tools. The problem was invisible until they measured it.\nTake the 3-minute Delivery Flow Scorecard to find out:\nYour team’s flow score (0-100) Where work gets stuck without you knowing Your #1 hidden bottleneck Get Your Free Delivery Flow Score →\nThe Misused Rewrite: Why Teams Default to the Wrong Fix When delivery slows down, teams often reach the same conclusion: “Let’s rewrite it.” The thinking sounds reasonable. The codebase is old. The architecture feels clunky. New tools look faster, cleaner, and smarter.\nBut most rewrites fail because the system behind them remains unchanged. You rebuild with the same unclear priorities. The same overload. The same fragile review process. So the same problems return, just written in a different language.\nRewriting code doesn’t fix rework, delays, or team misalignment.\nIt just resets the clock.\nA rewrite only creates value if it removes a real constraint. For example, splitting a giant, tightly-coupled codebase into smaller parts so teams can deploy changes independently without waiting on each other. Or replacing legacy code that makes automated testing impossible and slows every release.\nBut if the rewrite only makes the code “nicer” without changing how work flows, it doesn’t solve the problem. It hides it. It’s an expensive distraction.\nThe Cost of Not Seeing the System Most teams don’t work in isolation. They work in a system. I mean a set of habits, rules, and invisible constraints that shape how work moves from idea to delivery.\nBut here’s the problem: The system is rarely visible.\nPeople see tasks, sprints, backlogs, and commits. They don’t see the delays between steps. They don’t see the overload. They don’t see how work sits idle, waiting for review or decisions.\nSo they blame the wrong things. They think developers are too slow. They think tools aren’t advanced enough.\nBut the real issue is that no one is looking at how work flows, or why it stops.\nAt this point, we see good teams break down. It is not because they lack talent. It is just because they operate in a system that hides its own problems.\nThe reality: if you can’t see the system, you can’t improve it. You’ll keep adding tools. You’ll keep rewriting code. You’ll keep hiring. And the same struggles will keep showing up.\nWhat to Do Instead: Small Changes That Transform Flow You don’t need a significant transformation to fix this. You need to see the system and make small, targeted changes that remove friction.\nHere’s where to start:\nMake work visible. Utilize visual management boards and display queues. If you can’t see the work, you can’t improve it. Limit what’s in progress. When everything moves at once, nothing finishes. Set clear limits. Focus. Finish. Then pull the next task. Fix the handoffs. Don’t let work bounce between people with no ownership. Define clear responsibilities. Build shared understanding early. Speed up feedback. Don’t wait days for reviews or bug reports. Tighten the loop. Small, fast feedback prevents big, slow problems. Review flow, not just code. Don’t just ask “Is this code clean?” Ask, “Where did this work get stuck?”. Trigger continuous improvement: “How can we prevent that next time?” These actions aren’t complex. But they are powerful. Because once teams can see how work moves, they can start improving how they deliver value. And that’s the fundamental unlock: not faster tools, but smoother flow.\nDelivery Flow Self-Check: [ ] Can you see all the work currently in progress? [ ] Do you know where work gets stuck most often? [ ] Are your reviews fast and consistent? [ ] Does your team limit WIP or pull everything at once? [ ] Are system-wide improvements part of your regular retros or problem-solving sessions? Your Engineers Aren’t Broken. Your System Might Be. If your team still struggles, even with great tools and competent engineers, the problem isn’t your people. It’s the system around them.\nTools can make code easier to write. AI can help move faster. But if the work still gets stuck, delayed, or reworked, then the real problem is how work flows, not how code looks.\nYou don’t need to push harder. Instead, you need to see the system. Then change the parts that break flow, slow feedback, or overload your team.\nStart small. Make work visible. Fix one bottleneck. Then keep going. Because the teams that win aren’t just faster, they’re the ones who can learn, adapt, and deliver without burning out.\nFrequently Asked Questions About Fixing Software Delivery Flow Q: Can AI help improve delivery flow? A: Yes, but only if the system is healthy. AI can accelerate code writing, but it won’t fix unclear priorities, poor feedback loops, or overloaded teams.\nQ: What’s the difference between a team problem and a system problem? A: A team problem is about individual behavior. A system problem is about how work is structured, handed off, and reviewed. Most delivery issues are system problems in disguise.\nQ: What does “visual management” mean? A: It means making work, flow, and blockers visible. It could be a kanban board showing work items moving through each working step. You can also perform a value stream mapping to see and understand the workflow, hence see the blockers.\nIf you can’t see where work is stuck, you can’t improve it.\nQ: What do you mean by “problem-solving”? A: I don’t mean just fixing bugs. I suggest identifying the root causes of flow breakdowns, such as unclear ownership, unstable priorities, or poor handoffs, and addressing them with the team. It requires a structured approach like the PDCA.\nQ: Can we apply Lean thinking without a big change program? A: Yes. Start small. Make work visible. Limit what’s in progress. Run problem-solving focused on flow, not just code. Lean isn’t about big frameworks; it’s about identifying and fixing what’s slowing you down and learning from it.\n","permalink":"https://leantechpro.com/why-your-dev-team-still-struggles-with-delivery-even-with-ai-better-tools-and-great-engineers/","summary":"\u003cdiv class=\"key-takeaways\"\u003e\n\u003ch2 id=\"key-takeaways\"\u003eKEY TAKEAWAYS\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eBetter tools and smarter engineers won’t fix delivery if the system around them is broken.\u003c/strong\u003e Most bottlenecks come from invisible delays, unclear ownership, and overloaded workflows—not from poor coding.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAI accelerates output, but it also amplifies dysfunction.\u003c/strong\u003e Without flow visibility, fast code creation leads to more rework, review delays, and misaligned priorities.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eImproving delivery doesn’t require a massive transformation.\u003c/strong\u003e Start small: make work visible, limit WIP, and fix the handoffs. These simple changes create real, lasting impact.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003ch2 id=\"the-pain-that-wont-go-away\"\u003e\u003cstrong\u003eThe Pain That Won’t Go Away\u003c/strong\u003e\u003c/h2\u003e\n\u003cp\u003eYou’ve hired competent developers. You’ve added AI tools to speed things up. You’ve upgraded your stack, improved your CI/CD, and given teams more autonomy.\u003c/p\u003e","title":"Why Your Dev Team Still Struggles With Delivery – Even With AI, Better Tools, and Great Engineers"},{"content":" KEY TAKEAWAYS AI-assisted “vibe coding” has increased code duplication 8x while decreasing refactoring by 40% in 2024, significantly accelerating technical debt (GitClear’s analysis of 211M code lines). Four technical debt accelerators: “Good Enough” solutions lacking architectural fit, AI’s limited context window creating architectural blindness, duplicated similar solutions, and code growing beyond developer comprehension. Lean Tech implementation strategies: Early validation against real use cases, shortened feedback loops, continuous improvement of AI tools/prompts, and active waste reduction through code simplification. “Vibe coding” burst onto the tech scene when Andrej Karpathy, former Tesla AI director and OpenAI co-founder, coined the term in February 2025. He described it as “fully giving in to the vibes, embracing exponentials, and forgetting that the code even exists.” This new coding approach leverages advanced AI assistants like Cursor Composer to generate code with minimal human oversight. Developers speak commands, accept AI suggestions without review, and troubleshoot by returning error messages to the AI. The code grows beyond the programmer’s comprehension yet somehow functions—at least for weekend projects.\nWhat started as Karpathy’s amusing observation quickly revealed a deeper industry-wide trend. Recent research from GitClear confirms this shift. Their analysis of 211 million lines of code shows alarming patterns: code duplication increased eightfold in 2024 while refactoring dropped by nearly 40%. We’re witnessing a fundamental transformation in how software gets built.\nThis transformation creates a troubling paradox. We write more code faster than ever, but that speed comes with hidden costs. When developers surrender understanding and oversight to AI tools, they’re not just coding differently but might accelerate technical debt. Each unexamined code suggestion, each duplicated block, and each skipped refactoring opportunity compounds silently over time.\nLean Tech principles offer a promising counterbalance to this troubling trend. By applying lean thinking to AI-assisted development, teams can harness AI’s productivity benefits without sacrificing code quality. This article explores how the “vibe coding” phenomenon creates technical debt and presents strategies to keep AI-driven development lean, sustainable, and built for long-term success.\nThe GitClear Research and What It Reveals The numbers tell a stark story. GitClear’s comprehensive study analyzed 211 million lines of code across both commercial and open-source projects during 2024, revealing three troubling trends:\nCode duplication exploded. Blocks with five or more duplicated lines increased 8 times compared to previous years. It means developers now paste the same code across multiple locations rather than creating reusable functions. Refactoring plummeted. The research documented a 39.9% decrease in moved lines of code, a key indicator of refactoring activity. For the first time in software development history, copy/pasted lines exceeded moved lines. Code volume surged. The total amount of new code added to repositories grew exponentially, suggesting quantity now trumps quality in many development environments. These findings contradict the rosy picture painted by Google’s 2024 DORA “State of DevOps” report, which claimed AI adoption improved code quality by 3.4%. However, even Google’s researchers acknowledged a critical caveat: delivery stability dropped by 7.2%. When we dig deeper, both reports highlight the same phenomenon from different angles.\nThe culprit? According to GitClear, AI coding assistants make inserting new code blocks effortlessly: press the tab key. These tools excel at generating fresh code but struggle to suggest reusing existing functions elsewhere in the codebase. This limitation stems partly from their restricted context window, preventing them from “seeing” the entire codebase as a cohesive system.\nThis situation creates a fundamental misalignment. Individual code blocks might look clean and efficient when viewed in isolation. But zoom out to the system level, and the picture changes dramatically. The codebase becomes bloated with redundancies, lacks consistent structure, and grows increasingly fragile.\nThe most concerning finding lies in what’s missing rather than what’s added. AI assistants rarely propose consolidating similar functions or restructuring code for maintainability. GitClear’s researchers emphasize that humans still hold a crucial advantage over AI: recognizing patterns across dispersed code and consolidating them into reusable modules.\nWithout this human oversight, we risk building software that functions today but becomes unmaintainable tomorrow.\nHow Vibe Coding Accelerates Technical Debt Vibe coding transforms how code gets written. Unlike traditional development, where programmers carefully craft solutions with a deep understanding of their systems, vibe coding encourages a detached, almost carefree approach. Developers speak commands, accept AI suggestions without scrutiny, and troubleshoot by feeding error messages back to the AI without genuinely understanding what went wrong.\nThis shift creates perfect conditions for technical debt to flourish in four specific ways:\nThe “Good Enough” Problem. AI tools excel at generating code that appears functional on the surface. The code runs, passes basic tests, and works. This situation creates a false sense of security. Developers accept solutions without questioning their architectural fit, long-term maintainability, or hidden edge cases. Technical debt accumulates beneath this veneer of functionality. Architectural Blindness. AI assistants lack system-wide understanding. They generate solutions within their limited context window, typically seeing only a few hundred lines of surrounding code, not the entire codebase. This myopia leads to solutions that solve immediate problems while ignoring broader architectural patterns. As a result, we see inconsistent approaches to similar issues scattered throughout the codebase. The Copy-Paste Cascade. When faced with similar problems, AI tools tend to generate similar but slightly different solutions rather than identifying opportunities for abstraction. This multiplication of nearly identical code makes future changes exponentially more difficult. Change one implementation, and you must hunt down and update all its duplicates, assuming you even remember they exist. The Comprehension Gap. Karpathy admits that vibe-coded projects quickly “grow beyond usual comprehension.” When developers don’t fully understand their code, they can’t effectively maintain it. It creates a dangerous cycle: less understanding leads to more reliance on AI for modifications, further reducing comprehension. These issues compound rapidly in team environments. Different developers using different AI assistants with varying styles of prompting produce wildly inconsistent code. Without strong standards and review processes, codebases become fragmented patchwork rather than cohesive systems.\nWe should not underestimate the psychological impact either. Vibe coding subtly shifts developer incentives from quality to speed. It rewards quick, flashy feature delivery while obscuring the long-term costs. Developers celebrate immediate productivity gains without seeing the maintenance nightmare they create for their future selves.\nI do not mean AI tools are inherently harmful. The problem lies in how we use them. When we surrender too much control and oversight to AI, meaning entirely “give in to the vibes” as Karpathy puts it, we amplify technical debt’s most dangerous aspects. We create invisible risks that compound quietly over time, eventually undermining the very speed advantages that made vibe coding appealing in the first place.\nThe Lean Tech Philosophy Lean Tech offers a powerful counterbalance to vibe coding’s shortcomings. This approach adapts traditional lean manufacturing principles to software development, focusing on sustainable value delivery. It’s not about rejecting AI tools. It’s about using them more intelligently.\nAt its core, Lean Tech embraces five fundamental principles:\nValue over volume. Lean focuses on delivering what customers truly need rather than maximizing lines of code. This direct challenge to vibe coding’s “more is better” mentality emphasizes that working software doesn’t automatically equal valuable software. Flow optimization. Lean teams create smooth, predictable delivery systems where work moves efficiently from concept to customer. They actively identify and eliminate bottlenecks caused by quality issues, knowledge gaps, or process waste. Continuous improvement. Unlike vibe coding’s “set it and forget it” approach, Lean Tech demands ongoing refinement. Teams regularly examine their processes, tools, and outputs to find opportunities for enhancement. Pull-based systems. Work starts only when there’s a genuine customer need, not simply because AI makes code generation easy. This approach prevents the creation of unnecessary features that bloat codebases. Quality built-in. Quality isn’t something added later through testing. We design it into the process from the beginning. This principle directly counters vibe coding’s tendency to defer quality concerns. Its focus on sustainability makes Lean Tech particularly effective against technical debt. While vibe coding optimizes for today’s productivity, Lean optimizes for long-term delivery capability. It recognizes that today’s shortcuts become tomorrow’s roadblocks.\nLean Tech also reframes how we measure success. Instead of tracking output metrics like lines of code or features delivered, it emphasizes outcome metrics like customer satisfaction, system stability, and team agility. These measures naturally discourage the accumulation of technical debt.\nThe philosophy reshapes team dynamics, too. Rather than isolating developers with their individual AI assistants, Lean promotes collaborative practices like pair programming, collective code ownership, and regular knowledge sharing. These practices create multiple layers of defense against the architectural blindness endemic to vibe coding.\nMost importantly, Lean Tech restores human judgment to its rightful place in software development. AI becomes a tool wielded with intention rather than a replacement for thoughtful decision-making. Developers maintain agency and understanding while still benefiting from AI’s capabilities.\nThis approach doesn’t mean sacrificing speed. It means redefining it. As the saying goes, “Speed without quality is just faster failure.” True speed isn’t about how quickly you can write code today but how quickly you can deliver value consistently over time. By addressing the root causes of technical debt, Lean Tech enables greater sustainable speed than vibe coding could ever achieve.\nStrategies for Lean AI-Driven Development Implementing Lean Tech principles with AI tools requires specific, actionable strategies. Here are four powerful approaches to harnessing AI’s benefits while preventing technical debt:\nEarly Validation Against Real Use Cases Move beyond simple, functional testing. AI excels at generating code that runs but struggles to evaluate how well it solves actual user problems.\nStart by clearly defining success criteria before asking AI to generate any code. Create scenarios that represent real user journeys, not just technical requirements. Then, validate AI-generated solutions against these scenarios immediately.\nImplement structured “AI output reviews” where team members evaluate generated code for functionality and alignment with system architecture, performance requirements, and maintainability standards.\nThis early validation catches misalignments before they become embedded in your codebase. It shifts focus from “Does it work?” to “Does it work right?”\nShorten Feedback Loops Traditional code reviews often come too late after developers have invested emotionally in their solutions. With AI-generated code, shorter feedback cycles become essential.\nImplement lightweight architectural reviews that happen before committing code. These quick sessions focus exclusively on design patterns, not implementation details.\nUse automated quality gates that flag potential issues like duplicated code, excessive complexity, or inconsistent patterns. These gates should trigger immediate conversations rather than just blocking progress.\nCreate visualization tools that show developers the broader impact of their changes. These tools help bridge the comprehension gap by making system-wide patterns visible.\nShortened feedback loops transform technical debt from an invisible accumulation into a visible concern that teams address continuously.\nEmbrace Kaizen for AI Usage AI tools themselves need continuous improvement to serve Lean goals.\nDocument effective prompting patterns that produce maintainable code. Create team-specific prompt libraries incorporating your architecture standards, naming conventions, and preferred patterns.\nTeams should track AI tool effectiveness metrics beyond simple productivity. Measure how often AI-generated code requires rework, creates duplication, or introduces unexpected side effects.\nDedicate time for “AI retrospectives,” where teams discuss their experiences with various tools and techniques. These sessions help teams learn collectively rather than struggling individually.\nBy applying Kaizen principles to AI usage, teams continuously refine their engagement with these tools to support long-term quality.\nChallenge Waste Actively Vibe coding normalizes waste in the form of duplicated code, unused features, and overly complex solutions. Lean Tech actively challenges this waste.\nSchedule regular “code simplification sprints” where teams focus exclusively on reducing complexity without changing functionality. These designated periods make refactoring a priority rather than an afterthought.\nImplement “code mapping” exercises where teams visualize duplicate functionality across the codebase. These sessions make invisible waste visible and create opportunities for consolidation.\nPractice “solution minimalism” by challenging every AI-generated solution: “Is this the simplest way to solve this problem?” This mindset counteracts AI’s tendency to generate unnecessarily complex solutions.\nCreate space for developers to understand code before modifying it. It might seem inefficient initially, but it prevents the compounding comprehension gap that accelerates technical debt.\nThese strategies don’t reject AI tools. They harness them more effectively. By integrating Lean principles into how teams use AI, organizations can maintain code quality and architectural integrity while benefiting from increased productivity.\nImplementing a Lean Tech Culture with AI Adopting Lean Tech principles requires more than individual strategies. It demands cultural transformation. This shift starts with leadership and extends through team structures, metrics, and skill development.\nStart by establishing clear leadership expectations:\nSet balanced priorities. Leaders must explicitly value sustainable delivery alongside speed. When executives celebrate only rapid feature delivery, teams inevitably cut corners. Instead, recognize and reward architectural improvements, refactoring efforts, and technical debt reduction. Model systems thinking. Leaders should regularly ask questions about long-term impacts, not just immediate outcomes. Simple inquiries like “How will this approach scale?” or “What happens when we need to modify this in six months?” reinforce the importance of sustainable solutions. Remove pressure to vibe code. Many teams turn to vibe coding because of unrealistic deadlines. Leaders must set achievable timelines that allow for quality practices and provide air cover when teams push back against unsustainable expectations. Next, implement team structures that counterbalance AI’s limitations:\nFormalize the architect’s role. Designate experienced developers to maintain architectural oversight across multiple teams. These architects should receive AI-specific training to spot patterns of AI-generated technical debt. Create balanced teams. Mix AI enthusiasts with architectural thinkers on each team. This diversity prevents echo chambers where vibe coding techniques go unchallenged. Establish code stewardship. Assign specific developers responsibility for maintaining quality in different parts of the codebase. This ownership creates accountability for long-term maintainability. Transform your metrics to promote sustainability:\nTrack technical debt indicators. Monitor duplication rates, code churn, and refactoring activity, the same metrics GitClear used in their research. Make these visible to all teams through dashboards. Measure mean time to change. How long does implementing a typical feature or fixing a bug take? This metric captures the real impact of technical debt on team agility. Implement architectural fitness functions. Create automated tests that verify adherence to architectural principles. These provide immediate feedback when AI-generated code violates system constraints. Finally, develop new skills that complement AI capabilities:\nTeach effective prompting. Help developers craft prompts that generate maintainable, aligned code. This skill becomes increasingly valuable as AI tools evolve. Build pattern recognition. Train developers to identify reuse opportunities across disparate parts of the codebase, a skill AI assistants still lack. Develop critical evaluation. Help teams assess AI output critically rather than accepting it unquestioningly. It includes questioning assumptions, spotting edge cases, and evaluating architectural fit. The most successful organizations will treat AI as a team member with specific strengths and weaknesses. They’ll delegate tasks that AI handles well, like generating initial implementations or boilerplate code while maintaining human oversight for architectural decisions and system-wide coherence.\nThis culture shift doesn’t happen overnight. Start with small experiments, celebrate early successes, and gradually expand practices that work. The goal isn’t perfection but continuous improvement, which is the essence of Lean thinking.\nConclusion The rise of vibe coding represents a pivotal moment in software development. AI-powered coding tools have unleashed unprecedented productivity, but as GitClear’s research clearly shows, this rapid pace comes with hidden costs. The explosion of duplicated code and dramatic decline in refactoring signal a troubling trend toward codebases that function today but become maintenance nightmares tomorrow.\nLean Tech principles offer a powerful way forward. By focusing on value over volume, building quality into our processes, and embracing continuous improvement, teams can harness AI’s benefits while avoiding pitfalls. The four key strategies – early validation, shortened feedback loops, continuous AI improvement, and active waste reduction – provide a practical framework for responsible AI adoption.\nThis approach doesn’t reject AI’s capabilities. Instead, it integrates these powerful tools into a more thoughtful development process. Developers maintain oversight and understanding while leveraging AI to handle repetitive tasks, generate initial implementations, and augment human creativity.\nThe teams that thrive in this new era won’t be those who code at maximum speed. Success will come to organizations that balance immediate productivity with long-term sustainability: teams that use AI as a powerful tool rather than surrendering control to it.\nOne truth remains constant as we navigate this transformation: great software ultimately comes from human insight, discipline, and care. AI can amplify these qualities, but it can’t replace them. By applying Lean Tech principles to AI-driven development, we can build systems that deliver value consistently over time, creating not just code that works but code worth working with.\nImplementing Lean Tech in the rising context of vibe coding isn’t just about software quality. It’s about whether we’ll control our tools or be controlled by them. By making this choice consciously, we shape our codebases and the future of our profession.\nFrequently Asked Questions What is the first practical step for implementing Lean Tech in AI-driven development? Start by implementing structured “AI output reviews” in your team. During these reviews, team members should evaluate generated code beyond basic functionality. They must check for architectural alignment, assess maintainability, and verify adherence to system patterns. This approach creates an immediate quality checkpoint before AI-generated code enters your codebase. It also helps teams develop a critical eye for evaluating AI outputs.\nHow can we measure improvements in technical debt reduction when using AI tools? Track specific metrics like duplication rates, refactoring activity, and mean time to implement changes. Additionally, monitor how frequently unexpected bugs appear in AI-generated code. Track how often teams need to rework AI solutions after implementation. These measurements provide tangible evidence of improvement. They also help make the invisible costs of technical debt visible to stakeholders.\nWhat are common challenges when implementing Lean Tech principles with AI assistants? The most common challenges include several key issues. Teams must balance speed expectations with quality requirements. They must overcome the initial productivity dip as members learn to use AI more deliberately. Organizations must shift mindsets from “AI as a replacement” to “AI as a tool.” Finally, developers must maintain system-wide understanding as codebases grow. Teams often struggle to resist accepting AI-generated solutions without proper evaluation.\nHow can smaller teams with limited resources apply Lean Tech strategies? Smaller teams can focus on lightweight implementations. Use simple visualization tools to map code relationships. Implement micro-reviews for AI-generated code. Create a shared prompt library of effective patterns. Dedicate even just 1-2 hours per week to code simplification. The advantage for smaller teams is greater visibility across the entire codebase, making it easier to spot duplication and inconsistency patterns.\nWhat’s the role of technical leadership in supporting Lean Tech practices? Technical leaders must model the behaviors they want to see. It includes questioning AI outputs, validating solutions against user needs, and valuing sustainability alongside speed. Leaders should create safe spaces for teams to push back against unrealistic timelines. They need to recognize and reward refactoring and technical debt reduction efforts. Leaders must also help establish clear architectural guidelines for AI tool usage. Most importantly, they must consistently demonstrate that quality matters, even when it’s temporarily slower.\nHow might a Lean Tech approach differ for front-end versus backend development with AI? For front-end development, Lean Tech emphasizes consistency in user experience, component reusability, and performance optimization. Teams should implement visual regression testing for AI-generated UI code. They must validate against accessibility standards. For backend development, the focus shifts to service boundaries, data consistency, and system scalability. The principles remain the same in both cases: early validation, shortened feedback loops, and active waste reduction. However, the implementation techniques and specific quality gates will differ.\nIs it possible to quantify the ROI of implementing Lean Tech principles with AI tools? Yes, though it requires tracking both short and long-term metrics. In the short term, you might see a slight decrease in raw productivity. It happens as teams implement more rigorous evaluation processes.\nHowever, long-term measurements typically will show significant improvements. Teams will experience reduced bug rates and faster onboarding of new team members.\nThe most compelling ROI will appear several months after implementation. At this point, teams can deliver new features more consistently. They also avoid unexpected delays from technical debt.\nHow do we balance leveraging AI’s capabilities while maintaining code quality? Create clear boundaries for AI usage. Designate areas where AI can operate with minimal oversight, such as generating boilerplate, test cases, or documentation. Identify areas requiring human review, including architectural decisions, security-critical code, or complex business logic.\nDevelop team-specific prompting guidelines. These should incorporate your architectural standards and quality expectations.\nFinally, implement automated quality gates. These should flag potential issues in AI-generated code for human review. At the same time, they should allow straightforward implementations to flow through.\n","permalink":"https://leantechpro.com/the-hidden-cost-of-vibe-coding-applying-lean-tech-to-reduce-technical-debt-in-ai-driven-teams/","summary":"\u003cdiv class=\"key-takeaways\"\u003e\n\u003ch2 id=\"key-takeaways\"\u003eKEY TAKEAWAYS\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eAI-assisted “\u003cstrong\u003evibe coding\u003c/strong\u003e” has increased code duplication 8x while decreasing refactoring by 40% in 2024, significantly accelerating technical debt (GitClear’s analysis of 211M code lines).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eFour technical debt accelerators:\u003c/strong\u003e “Good Enough” solutions lacking architectural fit, AI’s limited context window creating architectural blindness, duplicated similar solutions, and code growing beyond developer comprehension.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLean Tech implementation strategies:\u003c/strong\u003e Early validation against real use cases, shortened feedback loops, continuous improvement of AI tools/prompts, and active waste reduction through code simplification.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003cp\u003e“Vibe coding” burst onto the tech scene when Andrej Karpathy, former Tesla AI director and OpenAI co-founder, coined the term in February 2025. He described it as “fully giving in to the vibes, embracing exponentials, and forgetting that the code even exists.” This new coding approach leverages advanced AI assistants like Cursor Composer to generate code with minimal human oversight. Developers speak commands, accept AI suggestions without review, and troubleshoot by returning error messages to the AI. The code grows beyond the programmer’s comprehension yet somehow functions—at least for weekend projects.\u003c/p\u003e","title":"The Hidden Cost of Vibe Coding: Why AI-Generated Code Creates Technical Debt"},{"content":"These testimonials were given by professionals I’ve collaborated with through consulting engagements or subcontracting missions, and reflect their direct experience working with me on tech delivery improvement initiatives. – JL COSSI\nClient Testimonials Technology Leaders LinkedIn recommendation from February 2, 2024\nLinkedIn recommendation from October 5, 2018\nTech Engineers LinkedIn recommendation from December 14, 2022\nLinkedIn recommendation from March 1, 2023\nLinkedIn recommendation from March 22, 2023\nLean Practitioners LinkedIn recommendation from March 10, 2023\nLinkedIn recommendation from January 14, 2015\n","permalink":"https://leantechpro.com/testimonials/","summary":"\u003cp\u003e\u003cem\u003eThese testimonials were given by professionals I’ve collaborated with through consulting engagements or subcontracting missions, and reflect their direct experience working with me on tech delivery improvement initiatives.\u003c/em\u003e – JL COSSI\u003c/p\u003e\n\u003cdiv class=\"testimonials-container\"\u003e\n\u003ch1 id=\"client-testimonials\"\u003eClient Testimonials\u003c/h1\u003e\n\u003cdiv class=\"testimonial-group\"\u003e\n\u003ch2 id=\"technology-leaders\"\u003eTechnology Leaders\u003c/h2\u003e\n\u003cdiv class=\"linkedin-testimonial\"\u003e\n\u003cimg src=\"/images/2025/03/Leader_Testimonial_4.webp\" decoding=\"async\" alt=\"Testimonial from Mohand Ferhi, CTO / Responsable Département R\u0026amp;D\" /\u003e\n\u003cdiv class=\"testimonial-caption\"\u003e\n\u003cp\u003eLinkedIn recommendation from February 2, 2024\u003c/p\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003cdiv class=\"linkedin-testimonial\"\u003e\n\u003cimg src=\"/images/2025/03/Leader_Testimonial_1.webp\" decoding=\"async\" alt=\"Testimonial from Gabriel Le Van, CIO\" /\u003e\n\u003cdiv class=\"testimonial-caption\"\u003e\n\u003cp\u003eLinkedIn recommendation from October 5, 2018\u003c/p\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003cdiv class=\"testimonial-group\"\u003e\n\u003ch2 id=\"tech-engineers\"\u003eTech Engineers\u003c/h2\u003e\n\u003cdiv class=\"linkedin-testimonial\"\u003e\n\u003cimg src=\"/images/2025/03/Leader_Testimonial_6.webp\" decoding=\"async\" alt=\"Testimonial from Aarti Dey, Oracle DBA\" /\u003e\n\u003cdiv class=\"testimonial-caption\"\u003e\n\u003cp\u003eLinkedIn recommendation from December 14, 2022\u003c/p\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003cdiv class=\"linkedin-testimonial\"\u003e\n\u003cimg src=\"/images/2025/03/Leader_Testimonial_7.webp\" decoding=\"async\" alt=\"Testimonial from Hakan Elbasan, Oracle Apps DBA\" /\u003e\n\u003cdiv class=\"testimonial-caption\"\u003e\n\u003cp\u003eLinkedIn recommendation from March 1, 2023\u003c/p\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003cdiv class=\"linkedin-testimonial\"\u003e\n\u003cimg src=\"/images/2025/03/Leader_Testimonial_8.webp\" decoding=\"async\" alt=\"Testimonial from Praveen Binduaa, Senior Database Analyst\" /\u003e\n\u003cdiv class=\"testimonial-caption\"\u003e\n\u003cp\u003eLinkedIn recommendation from March 22, 2023\u003c/p\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003cdiv class=\"testimonial-group\"\u003e\n\u003ch2 id=\"lean-practitioners\"\u003eLean Practitioners\u003c/h2\u003e\n\u003cdiv class=\"linkedin-testimonial\"\u003e\n\u003cimg src=\"/images/2025/03/Leader_Testimonial_9.webp\" decoding=\"async\" alt=\"Testimonial from Pushpa Mishra Dwivedi, Lean-Agile Coach\" /\u003e\n\u003cdiv class=\"testimonial-caption\"\u003e\n\u003cp\u003eLinkedIn recommendation from March 10, 2023\u003c/p\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003cdiv class=\"linkedin-testimonial\"\u003e\n\u003cimg src=\"/images/2025/03/Leader_Testimonial_5.webp\" decoding=\"async\" alt=\"Testimonial from Ripsime Gabrielian, Lean IT Project Manager\" /\u003e\n\u003cdiv class=\"testimonial-caption\"\u003e\n\u003cp\u003eLinkedIn recommendation from January 14, 2015\u003c/p\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003c/div\u003e","title":"Testimonials"},{"content":" KEY TAKEAWAYS Prioritize Progress Over Perfection: Focus on incremental improvements—companies report up to 30% faster delivery and 20% better resource utilization. Value Stream Mapping Drives Results: Implementing value stream mapping can cut lead time by 25% and boost throughput by 15%, accelerating time-to-market. Action Over Theory: Continuous improvement can boost team performance by 50%, reducing waste and driving better results. Every enterprise transformation has its path while moving to SAFe. When steering a large enterprise toward agility, perfect framework adherence often clashes with business reality.\nThe SAFe framework requires organizations to identify value streams before defining Agile Release Trains (ARTs). Yet here’s a pattern I keep seeing: The pressure to move fast pushes leaders to jump straight into forming ARTs. Teams get mapped to trains based on existing structures and dependencies. The promise of faster delivery wins over methodological purity. Value stream identification workshops get pushed to ‘later.’ The thinking goes: We’ll figure out the value streams once we’re up and running. But ‘later’ rarely comes. The trains keep moving. And that theoretical foundation stays theoretical.\nIn this story, the organization had already mapped teams to ARTs. This left us with two choices: conduct value stream identification workshops now, potentially disrupting the existing structure, or find a way to honor both SAFe principles and maintain our transformation momentum.\nFinding Another Way Value stream identification workshops bring significant challenges. They demand 3-5 months of effort and precious leadership time. Teams must participate while keeping their current work going. Any resulting organizational changes would disrupt our existing ARTs.\nThis reality pushed me to explore alternatives. Value stream mapping emerged as a compelling option, requiring only 1-2 months for initial foundation building. Instead of reorganizing from the top, we could focus on improving how work actually flows. Teams would develop concrete problem-solving skills while delivering faster, measurable results.\nThe shift in focus became clear: optimize flow within the existing structure rather than design an ideal one. Help teams improve rather than disrupt them. Build on the transformation momentum rather than risk it.\nTurning Theory into Practice The path forward took shape in my mind. We’d maintain the current transformation momentum while letting teams stabilize in their structure. Value stream mapping would become our tactical tool. Each selected area would undergo a 5-15 process block mapping exercise, measuring three critical metrics at each step: lead time, process time, and percent complete/accurate (%C/A).\nWe’d select high-impact areas first, looking for immediate improvement opportunities. But mapping alone wouldn’t suffice. We needed to coach problem-solving capabilities, help teams develop their own solutions, and build a continuous improvement culture.\nChoosing where to start mattered deeply. Business impact drove our decisions – revenue, costs, customer satisfaction. We considered team readiness, data availability, and management support. We looked at process health – known pain points, lead times, and quality issues. Everything aligned with business priorities and transformation goals.\nWhere Real Change Happens This approach transformed the conversation. Real value streams started emerging through action. Teams began mapping their actual workflows, discovering bottlenecks, and improving processes they touch daily. Through systematic measurement of lead times, process times, and percent complete/accurate rates, teams could now quantify their improvements. Each process block’s metrics revealed opportunities for concrete gains, transforming gut feelings about problems into data-driven decisions.\nLeaders saw something powerful unfold. The initial anxiety about ‘doing SAFe wrong’ led to excitement about tangible improvements. Teams didn’t just follow a framework – they solved real problems, building capabilities that would last beyond any transformation initiative.\nThe ARTs kept delivering while teams got better at what they do. Each improvement added to our understanding of how value really flows through the organization. We built the foundational knowledge SAFe recommended through practice rather than theory.\nLearning to See The story continues to unfold but has already taught us something crucial about enterprise transformations. Sometimes, the best way to understand value streams isn’t to define them from above. They reveal themselves through the work of improvement.\nIt isn’t about bypassing SAFe principles. If anything, it deepens their intent. Value stream identification aims to help organizations understand and improve their value delivery. We achieve this goal through value stream mapping – just from a different starting point.\nFor transformation leaders facing similar challenges, this offers a practical path forward. You don’t always have to choose between framework purity and business reality. Sometimes, you can find a third way that serves both.\nYes, we took the road less traveled in our SAFe journey. But that’s precisely what agile and Lean thinking means: adapting to reality, learning through doing and finding pragmatic ways to achieve meaningful outcomes.\n","permalink":"https://leantechpro.com/beyond-the-safe-blueprint-a-pragmatists-guide-to-value-streams/","summary":"\u003cdiv class=\"key-takeaways\"\u003e\n\u003ch2 id=\"key-takeaways\"\u003eKEY TAKEAWAYS\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003ePrioritize Progress Over Perfection:\u003c/strong\u003e Focus on incremental improvements—companies report up to 30% faster delivery and 20% better resource utilization.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eValue Stream Mapping Drives Results:\u003c/strong\u003e Implementing value stream mapping can cut lead time by 25% and boost throughput by 15%, accelerating time-to-market.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAction Over Theory:\u003c/strong\u003e Continuous improvement can boost team performance by 50%, reducing waste and driving better results.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003cp\u003eEvery enterprise transformation has its path while moving to SAFe. When steering a large enterprise toward agility, perfect framework adherence often clashes with business reality.\u003c/p\u003e","title":"Beyond the SAFe Blueprint: A Pragmatist’s Guide to Value Streams"},{"content":" KEY TAKEAWAYS 37% Increase in Customer Satisfaction: Achieved through systematic lead time reduction in just 3 months. 94% Reduction in Support Backlog: Accomplished without additional headcount or resources. Sustainable Performance Improvement: through measurable KPIs and executive-driven accountability. Context: E-Government Services Support Challenge A government agency is transforming the way it serves its citizens. They’ve launched several online services – what we call “e-services” – that revolutionize how people interact with the government. Citizens can, for example, now request criminal records, obtain national certificates, and register their businesses, all through their screens.\nBehind the scenes, a small but dedicated technical support team of six people keeps everything running smoothly. Citizens reach out to them through WhatsApp, phone, or email whenever they need help. The team’s mission is simple: solve problems and keep citizens happy, all within a 24-hour window. But their role goes beyond just helping users – they’re also the vital link between citizens and the development team, flagging bugs and suggesting improvements to improve the services.\nTech Support Team: Communication Flow Current State: Measuring Support Response Time “We need to improve our service,” the management tells me. I nod. Together, we agree to focus on the lead time – how long citizens wait for their requests to be resolved. It is the key metric we’ll tackle first.\nSo I dive into a five-day investigation, calling the last ten citizens whose requests were closed by the tech support team. I want honest, concrete feedback about completed support requests.\nThe citizens’ message comes through loud and clear. Whether they contact us via WhatsApp or email, their main complaint is response time. “Too slow,” they say. Most wait over two days. Some even wait a whole week. Worse yet, half of them have yet to receive a response.\nNext, I shadow the technicians during their daily work. The numbers tell a stark story. With the team leader, we uncover 320 pending email requests. The WhatsApp account? Another 95 requests are waiting for attention. Remember – these teams should respond within a day. Any request older than that becomes what we call a ‘backlog’ – overdue work missed its deadline and is still pending.”\nUnderstanding Lead Time in Tech Support Let me explain what lead time means in our tech support context. It’s the total time a citizen waits – from the moment they send their request until they receive a working solution. Simple, right?\nBut here’s where it gets interesting. Every new request joins a queue behind older, unfinished ones when we have a backlog. Think of it like a busy coffee shop – if there are fifteen orders ahead of yours, you’ll wait longer for your coffee. Each request spends time “waiting in line” before a technician can even look at it. This waiting time is a massive part of our lead time. And our citizens feel every minute of this wait.\nHere’s the critical relationship: more backlog means longer wait times, which leads to increased lead time. But there’s good news, too. If we clear the backlog, we can immediately start processing new requests. When that happens, lead time drops and citizens notice the improvement immediately.\nObjectives: Setting Realistic Improvement Targets With the tech support team, we set our first milestone. The backlog problem is clear, but tackling it needs a measured approach. Instead of aiming for an immediate complete elimination, we opt for continuous improvement. Our first target: reduce the backlog by 20%. Once we hit this mark, we’ll set the next goal.\nThis measured approach directly aims to improve how citizens perceive our response time. When citizens reach out to us, they should feel confident they’ll get a timely response. No more week-long waits. No more silence.\nRoot Cause Analysis: Finding the Source of Delays While investigating the emails with the team leader, we uncover several root causes of our backlog problem:\nTechnical Setup Issues: The email system is a maze of folders, each with complex routing rules. Many of these rules are broken. As a result, incoming emails randomly land in different folders. When new technicians join the team, no one can explain this folder structure to them.\nInconsistent Process: There’s no standard way to handle incoming requests. Each technician picks requests from whichever folder they know about whenever they think it’s right. It creates considerable variations in response times.\nMissing SLA Knowledge: The team has no clear visibility of their response time targets. We can’t find these service-level agreements in any document or visual reminder. Without this knowledge, no one feels the urgency to speed up request processing.\nTeam Coordination Gaps: The team works in isolation. No one knows who’s handling what or when. We find year-old email requests that nobody ever opened. Some requests sit forgotten in both WhatsApp and email queues.\nAction Plan: Five Key Improvement Levers 1 – Ensure to see the entire incoming flow\nThe backlog made our incoming request flow invisible. We need visual management to spot bottlenecks quickly. These bottlenecks could be a technician overwhelmed with too many requests or incoming requests piling up due to unclear priorities. Considering our volume – about 450 requests daily – we opt for a simple table showing the number of tickets at different stages: incoming, waiting, and processed.\n2 – Implement a better flow management\nWe tackle this with two approaches. First, the team leader becomes a dispatcher. As a senior member, she assigns requests to her colleagues based on their expertise levels. She also handles simple cases directly, helping her understand the types of requests they receive. Second, we set up a basic pull flow. We know our daily incoming volume and the backlog reduction target. It gives us precise numbers: requests to process daily and even per hour.\n3 – Create knowledge about the SLA\nThe team leader goes beyond one-time SLA communication. During daily meetings, she consistently reinforces the 24-hour completion target. It has become part of her daily language. She also creates a visual reminder on the wall displaying these service levels.\n4 – Learn and implement Problem-Solving\nWhen the team misses their daily targets, they don’t just move on. Each morning, they reflect on the previous day’s performance. What happened? Why? What should we try today? This habit builds systematic problem-solving through PDCA. For instance, when they notice an unusual spike in complex requests, one team member leads a PDCA cycle with the development team to understand and address the root cause.\n5 – Develop and reinforce a client-oriented perspective\nWe start with the initial citizen feedback I collected but need ongoing insights. At day’s end, one team member calls five citizens whose requests were just completed. Using a structured questionnaire we created, he gathered facts about areas needing improvement.\nResults: Three-Month Progress We started our Lean coaching project in “Month 1”. Let’s look at how our key metrics evolved over three months:\nMonth 1 (Starting Point):\nEmail backlog: 320 requests (baseline) Client satisfaction: 6.2/10 Month 2 (Progress):\nEmail backlog: 92 requests (71% reduction) WhatsApp backlog: 95 requests (baseline) Client satisfaction: 7.4/10 (19% improvement) Month 3 (Latest Results):\nEmail backlog: 20 requests (94% reduction from baseline) WhatsApp backlog: 23 requests (76% reduction from baseline) Client satisfaction: 8.5/10 (37% improvement) The email backlog reduction shows the power of making work visible and establishing clear targets. The team moved from firefighting mode (320 pending requests) to a controlled situation where they could handle daily volume efficiently. This transformation enabled them to focus on request quality rather than just quantity.\nThe WhatsApp channel, added to measurement in Month 2, showed the same improvement pattern as email. From 95 pending requests, the team reduced the backlog to 23, demonstrating that the visual management and pull system worked effectively across different communication channels.\nThe rise in citizen satisfaction, from 6.2 to 8.5, demonstrates that lead time was a critical factor in citizens’ experience. As response times shortened, satisfaction scores steadily increased, confirming that citizens value quick responses to their e-services requests. This direct correlation between reduced lead time and improved satisfaction validated our focus on response time reduction.\nSustainability: Maintaining the Improvements This story exemplifies Lean Management in action. But achieving results is one thing – sustaining them is another. My approach to sustainability revolves around management engagement. Throughout the project, we had regular management visits. They didn’t just observe – they actively participated in our journey. They acknowledged progress. They celebrated successes. Most importantly, they set the following milestones during each visit, challenging the team to reach new heights. This cycle of visit-celebrate-challenge helped maintain our continuous improvement momentum.\nThis story focused on how we reduced lead time for e-services support requests. With this same team, we had the opportunity to work on other aspects, such as service quality, which I will cover in another article.\nDisclaimer: This story is based on a real Lean coaching project. Some elements have been modified to ensure confidentiality.\n","permalink":"https://leantechpro.com/support-backlog-reduction-case-study/","summary":"\u003cdiv class=\"key-takeaways\"\u003e\n\u003ch2 id=\"key-takeaways\"\u003eKEY TAKEAWAYS\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e37% Increase in Customer Satisfaction\u003c/strong\u003e: Achieved through systematic lead time reduction in just 3 months.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e94% Reduction in Support Backlog\u003c/strong\u003e: Accomplished without additional headcount or resources.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSustainable Performance Improvement\u003c/strong\u003e: through measurable KPIs and executive-driven accountability.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/div\u003e\n\u003ch2 id=\"context-e-government-services-support-challenge\"\u003e\u003cstrong\u003eContext: E-Government Services Support Challenge\u003c/strong\u003e\u003c/h2\u003e\n\u003cp\u003eA government agency is transforming the way it serves its citizens. They’ve launched several online services – what we call “e-services” – that revolutionize how people interact with the government. Citizens can, for example, now request criminal records, obtain national certificates, and register their businesses, all through their screens.\u003c/p\u003e","title":"How We Cut a Support Backlog by 94% in 3 Months"},{"content":"Who we are KERYON, a French société par actions simplifiée (SAS), registered under SIREN 820 001 790 — RCS Paris, with its registered office at 58 rue de Monceau, 75008 Paris, France, provides management consulting services, including coaching and training. LeanTechPro is a brand of KERYON. Publication director: Jean-Luc Cossi. Our website address is: https://leantechpro.com.\nLeanTechPro®, the LeanTechPro logo® and the LT square logo® are registered trademarks (INPI No. 24 5094049, 24 5095571 and 25 5109951), owned by Jean-Luc Cossi and used by KERYON with his authorization.\nThis privacy statement outlines our commitment to safeguarding your personal information and your rights regarding it. For any questions please contact-us.\nWhat personal data we collect and why we collect it Comments When visitors leave comments on the site we collect the data shown in the comments form, and also the visitor’s IP address and browser user agent string to help spam detection.\nAn anonymized string created from your email address (also called a hash) may be provided to the Gravatar service to see if you are using it. The Gravatar service privacy policy is available here: https://automattic.com/privacy/. After approval of your comment, your profile picture is visible to the public in the context of your comment.\nMedia If you upload images to the website, you should avoid uploading images with embedded location data (EXIF GPS) included. Visitors to the website can download and extract any location data from images on the website.\nContact forms We collect name, email address, phone number and message from contact forms in order to respond to queries.\nThe resulting submission of contact forms are not shared.\nProduct reviews and testimonials We may collect name, email address, phone numbers, and a product review or testimonial.\nYour name, photograph, and review or testimonial may be shared on this website.\nIf your review or testimonial is posted on the website, you can request that it be removed at any time.\nCookies If you leave a comment on our site you may opt-in to saving your name, email address and website in cookies. These are for your convenience so that you do not have to fill in your details again when you leave another comment. These cookies will last for one year.\nIf you visit our login page, we will set a temporary cookie to determine if your browser accepts cookies. This cookie contains no personal data and is discarded when you close your browser.\nWhen you log in, we will also set up several cookies to save your login information and your screen display choices. Login cookies last for two days, and screen options cookies last for a year. If you select “Remember Me”, your login will persist for two weeks. If you log out of your account, the login cookies will be removed.\nIf you edit or publish an article, an additional cookie will be saved in your browser. This cookie includes no personal data and simply indicates the post ID of the article you just edited. It expires after 1 day.\nEmbedded content from other websites Articles on this site may include embedded content (e.g. videos, images, articles, etc.). Embedded content from other websites behaves in the exact same way as if the visitor has visited the other website.\nThese websites may collect data about you, use cookies, embed additional third-party tracking, and monitor your interaction with that embedded content, including tracking your interaction with the embedded content if you have an account and are logged in to that website.\nHosting This website is hosted with siteground.com.\nAs part of hosting, some information such as IP address may be logged when visiting this website. This may be used to detect errors or attacks against the website or hosting platform.\nYou can learn more about SiteGround’s privacy policy here: https://www.siteground.com/viewtos/privacy_policy\nEmail Marketing Automation The ActiveCampaign email automation software services are used.\nWe collect your email address if you opt-in to email marketing automation.\nThis email address will be used to send you educational information as well as special offers and promotions related to your interests.\nYou can learn more about ActiveCampaign’s privacy policy here: https://www.activecampaign.com/legal/privacy-policy\nProduct Purchases The Stripe and Paypal payment processors services are used.\nWhen you purchase a product we will collect your name, payment information and related personal information required to complete the purchase. Payment information is verified with payment processors and some meta data from the transaction is stored by the payment processor.\nYou can learn more about Stripe’s privacy policy here: https://stripe.com/privacy\nYou can learn more about PayPal’s privacy policy here: https://www.paypal.com/privacy\nAnalytics Google Analytics is used to record website visitor statistics.\nThis may be used in aggregate to learn more about what content is interesting or useful to visitors.\nYou can learn more about Google’s privacy policy here: https://policies.google.com/privacy\nWho we share your data with A list prepared in good faith of companies/services that data is indirectly or automatically shared with includes:\nSiteGround for website hosting. Hosted WordPress software for content management. Google Analytics for website statistics. ActiveCampaign for email marketing automation. Stripe for payment processing. PayPal for payment processing. Some personal information may be shared with employees or contractors of KERYON towards meeting legal, financial or related obligations, not limited to accountants and lawyers.\nHow long we retain your data We retain personal data only for as long as necessary for the purposes for which it was collected, in accordance with Article 5(1)(e) of the GDPR and the retention periods recommended by the CNIL (the French data protection authority).\nIf you leave a comment, the comment and its metadata are retained for as long as the related article remains published on this website. This is so we can recognize and approve any follow-up comments automatically instead of holding them in a moderation queue, and preserve the integrity of public discussions. You can request the removal of your comments at any time.\nFor users that register on our website (if any), we store the personal information they provide in their user profile for as long as the account remains active, and delete it no later than 3 years after the last activity on the account. All users can see, edit, or delete their personal information at any time (except they cannot change their username). Website administrators can also see and edit that information.\nIf you subscribe to an email marketing campaign, your personal information is retained for as long as you remain subscribed. If you unsubscribe, or if you show no interaction with our emails (such as opens or clicks) for 3 years, your data is deleted or anonymized, in line with CNIL guidelines on commercial prospection.\nIf you make a product purchase, data relating to the contractual relationship is retained for 5 years after the end of that relationship (French statute of limitations, Article 2224 of the Civil Code), and invoicing and accounting records are retained for 10 years as required by Article L123-22 of the French Commercial Code.\nWhat rights you have over your data You may opt-out of receiving most e-mails from us by following the “unsubscribe” instructions provided in the e-mails. Alternatively, you may contact us as described herein. If you are our customer, you may not be able to opt out of all emails, including certain administrative or billing communications which are important to the ongoing maintenance of your account.\nIf you have an account on this site, or have left comments, you can request to receive an exported file of the personal data we hold about you, including any data you have provided to us. You can also request that we erase any personal data we hold about you. This does not include any data we are obliged to keep for administrative, legal, or security purposes.\nWhere we send your data Visitor comments may be checked through an automated spam detection service.\nWe use Google reCaptcha. Here is Google’s Privacy Policy and Terms of Service regarding this software for spam management.\nSales of business We reserve the right to transfer information (including your personal information) to a third party in the event of a sale of our business provided that the third party only uses such information for the purposes that you provided it to us. You will be notified in the event of any such transfer and afforded the opportunity to opt-out.\nAdditional information How we protect your data We do not sell, rent or lease personal data.\nWe strictly limit the collection and processing of your personal data, and to the best of our abilities we will work only with other organizations who do the same.\nWe use reasonable and appropriate physical, electronic, and administrative safeguards to protect personal data from loss, misuse and unauthorized access, disclosure, alteration and destruction, taking into account the nature of the Personal Data and risks involved in processing that information.\nPlease note that we do not guarantee the security of information, as no method of internet transmission or storage is completely secure. Also note that we may retain and store your information in our databases and systems even after your KERYON or LeanTechPro account is deactivated, for as long as we have a legitimate purpose and legal basis to do so, within the retention periods described in the section “How long we retain your data” above and in accordance with applicable law.\nWhat data breach procedures we have in place We act according to the GDPR in the European Union, taking effect on May 25, 2018.\nArt. 33: Notification of a personal data breach to the supervisory authority\nArt. 34: Communication of a personal data breach to the data subject\nArt. 35: Data protection impact assessment\nWhat third parties we receive data from None.\nWhat automated decision making and/or profiling we do with user data None.\nContact information If you have any questions, comments or complaints about this Privacy Policy, please contact us.\n","permalink":"https://leantechpro.com/privacy-policy/","summary":"\u003ch1 id=\"who-we-are\"\u003eWho we are\u003c/h1\u003e\n\u003cp\u003eKERYON, a French société par actions simplifiée (SAS), registered under SIREN 820 001 790 — RCS Paris, with its registered office at 58 rue de Monceau, 75008 Paris, France, provides management consulting services, including coaching and training. \u003cstrong\u003eLeanTechPro is a brand of KERYON.\u003c/strong\u003e Publication director: Jean-Luc Cossi. Our website address is: \u003ca href=\"https://leantechpro.com\"\u003ehttps://leantechpro.com\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eLeanTechPro®, the LeanTechPro logo® and the LT square logo® are registered trademarks (INPI No. 24 5094049, 24 5095571 and 25 5109951), owned by Jean-Luc Cossi and used by KERYON with his authorization.\u003c/p\u003e","title":"Privacy Policy"},{"content":" Jean-Luc Cossi\nFounder, LeanTechPro\nAbout Jean-Luc Cossi 15+ years fixing delivery problems inside tech teams at Michelin, BNP Paribas, Sodexo, and government agencies. Not from the sidelines. On the ground, with the team, until the numbers move.\nBefore founding LeanTechPro, I led operational transformations in insurance, telecom, and digital services across Europe. I’ve worked with 5-person support teams and 400-person operations. The method is the same. The results are measurable.\nConnect on LinkedIn →\nHiring for an interim or transformation leadership role? Detailed track record and references at jlcossi.com →\nHow I Work I don’t just fix problems. I teach your team to fix their own. My approach combines hands-on problem-solving with capability building, so improvements stick after I leave.\nThe method is Lean management, applied to tech delivery rather than a factory floor. I don’t sell methodology. I sell results.\nI work alongside your team to diagnose root causes through direct observation, implement solutions together, and build systematic problem-solving capability. When the next problem appears, your team reaches for the method, not for the phone.\nTrack Record\nMeasured results. Real teams. Every number below was measured on the ground, with the team, within 3 months of engagement.\nBanking Software\n91% ↓\nDefect reduction. 15-person dev team. Client satisfaction improved after years of complaints.\nSoftware Testing\n160% ↑\nProductivity increase. False defects dropped from 44% to 4%. 15-person team.\nE-Services Support\n94% ↓\nBacklog cleared. Customer satisfaction up 37%. 6-person team, 3 months.\nEnergy Sector Support\n70% ↑\nOn-time resolution improvement. Escalation rate cut 45%. 9-person team.\nWhat Clients Say\nIn their words “\nI had the pleasure of working with Jean-Luc. He guided me through implementing the PDCA cycle to reduce the volume of incidents in our department. It was a transformative experience. I appreciate his collaborative approach, which is thoughtful and tailored to our specific challenges. Overall, we saw an effective decrease in downtime.\nMF\nMohand Ferhi\nCTO / Responsable Département R\u0026amp;D\n“\nJean-Luc led the team I am part of to adopt the Lean Management approach and mindset. With his support, I understood how incoming client requests were piling up. Therefore, I contributed to the new way of managing the incoming requests’ flow. As a result, the team successfully reduced the awaiting demands. I highly recommend him for your tech team to learn improving performance.\nHE\nHakan Elbasan\nOracle Apps DBA at Michelin\nRead all testimonials →\nReady to Fix Delivery? Delivery problems don’t fix themselves. Let’s talk about what’s broken and whether I can help.\nBook a Discovery Call →\n30 minutes · Free · No strings attached\n","permalink":"https://leantechpro.com/about/","summary":"\u003cdiv style=\"max-width: 800px; margin: 0 auto; padding: 60px 24px 20px;\"\u003e\n\u003cdiv style=\"display: flex; gap: 40px; align-items: flex-start;\"\u003e\n\u003cdiv style=\"flex-shrink: 0;\"\u003e\n\u003cimg src=\"/images/2018/07/Jean-Luc_Cossi_Keryon_Consulting_Digital_Lean_Innovation_.jpg\" style=\"width: 180px; height: 220px; object-fit: cover; border-radius: 6px;\" decoding=\"async\" alt=\"Jean-Luc Cossi\" /\u003e\n\u003cdiv style=\"font-size: 12px; font-weight: 600; color: var(--ltp-text-secondary); text-transform: uppercase; letter-spacing: 0.06em; margin-top: 10px; text-align: center;\"\u003e\n\u003cp\u003eJean-Luc Cossi\u003c/p\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003cdiv\u003e\n\u003cdiv class=\"hp-section-label\"\u003e\n\u003cp\u003eFounder, LeanTechPro\u003c/p\u003e\n\u003c/div\u003e\n\u003ch2 id=\"about-jean-luc-cossi\"\u003eAbout \u003ca href=\"https://linkedin.com/in/jlcossi\" style=\"color: var(--ltp-orange); text-decoration: none;\"\u003eJean-Luc Cossi\u003c/a\u003e\u003c/h2\u003e\n\u003cp\u003e15+ years fixing delivery problems inside tech teams at Michelin, BNP Paribas, Sodexo, and government agencies. Not from the sidelines. On the ground, with the team, until the numbers move.\u003c/p\u003e\n\u003cp\u003eBefore founding LeanTechPro, I led operational transformations in insurance, telecom, and digital services across Europe. I’ve worked with 5-person support teams and 400-person operations. The method is the same. The results are measurable.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://linkedin.com/in/jlcossi\" style=\"color: var(--ltp-orange); font-weight: 600; font-size: 15px; text-decoration: none;\"\u003eConnect on LinkedIn →\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eHiring for an interim or transformation leadership role? Detailed track record and references at \u003ca href=\"https://jlcossi.com\" style=\"color: var(--ltp-orange); font-weight: 600; text-decoration: none;\"\u003ejlcossi.com →\u003c/a\u003e\u003c/p\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003c/div\u003e","title":"About"},{"content":"Questions, feedback, or a delivery problem you want to talk through? Send a note — I read everything.\nName\nEmail\nMessage\nSend ","permalink":"https://leantechpro.com/contact/","summary":"\u003cp\u003eQuestions, feedback, or a delivery problem you want to talk through? Send a note — I read everything.\u003c/p\u003e\n\u003cform action=\"https://api.web3forms.com/submit\" method=\"POST\" class=\"contact-page-form\"\u003e\n  \u003cinput type=\"hidden\" name=\"access_key\" value=\"5c2e34a7-dc3f-4b7c-ac87-343f1ee9c1b6\"\u003e\n  \u003cinput type=\"hidden\" name=\"subject\" value=\"[LeanTechPro] Contact form message\"\u003e\n  \u003cp\u003e\n    \u003clabel for=\"cf-name\"\u003eName\u003c/label\u003e\u003cbr\u003e\n    \u003cinput id=\"cf-name\" type=\"text\" name=\"name\" required\u003e\n  \u003c/p\u003e\n  \u003cp\u003e\n    \u003clabel for=\"cf-email\"\u003eEmail\u003c/label\u003e\u003cbr\u003e\n    \u003cinput id=\"cf-email\" type=\"email\" name=\"email\" required\u003e\n  \u003c/p\u003e\n  \u003cp\u003e\n    \u003clabel for=\"cf-message\"\u003eMessage\u003c/label\u003e\u003cbr\u003e\n    \u003ctextarea id=\"cf-message\" name=\"message\" rows=\"6\" required\u003e\u003c/textarea\u003e\n  \u003c/p\u003e\n  \u003cbutton type=\"submit\"\u003eSend\u003c/button\u003e\n\u003c/form\u003e\n\u003c!-- Messages go to jlco@leantechpro.com via Web3Forms (same account as the\n     scorecard). Manage/spam settings at https://web3forms.com --\u003e","title":"Contact"}]