How a 15-Person COBOL Team Cut Defects 91% in 60 Days

A financial software case study. How visual management, daily flash meetings, and team-led PDCAs replaced rework with ownership.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I wrote about this pattern in detail: When Agile Coaching Doesn’t Deliver.

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

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

I wrote about this trap here: Your AI Tools Aren’t Delivering. The Problem Isn’t the Tools.

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

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

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

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

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

Learn more about visual management in the full Obeya guide I wrote: What Is an Obeya Room?

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

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

Full guide here: The PDCA Cycle: A Complete Guide With Examples

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

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

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

Results From Real Teams

I coached each of these teams. The numbers were measured on the ground within three months.

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

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

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

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

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

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

Diagnose: 5 days, on-site, with the team.

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

Workshop: the team designs the fix.

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

Coach: Stay until results hold.

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

Frequently Asked Questions

What ROI can I expect?

Here are results from teams I coached. Every number was measured on the ground within three months.

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

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

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

Organizations already practicing Agile often hit a plateau. Lean breaks through it by addressing system-level problems that no ceremony can fix on its own.

Where do these transformations fail?

Three patterns kill most transformations before they start.

First, 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?

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

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

How do I get started?

Two paths.

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

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

---

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