amer.catic@projectvisit.org dagb@projectvisit.org +46 31 322 7207
PV Project Visit

Applying Lean Principles to Software Development

Software teams often adopt Lean language before changing the way work is selected, designed and delivered. They introduce a Kanban board, limit work in progress and hold retrospectives, yet still find that releases are late, priorities change daily and specialists remain overloaded. The difficulty is rarely a lack of effort. It is usually a failure to connect Lean thinking with the actual constraints of software work. Learn more about Contacts.

This case study describes a composite engagement involving a product team, an enterprise customer and an industry-facing research group similar to Chalmers Electronic Lean Research Team, or Celean. The team used digital visual planning, flow metrics and structured learning cycles to improve software delivery. The example is relevant to Australian organisations, where distributed teams, lengthy procurement processes, security reviews and partnerships across Sydney, Melbourne, Brisbane and regional locations shape how digital products reach users.

Why Lean Needs Translation

Lean software development is often reduced to a collection of techniques: Kanban cards, daily stand-ups, small batches and continuous delivery. These practices can be useful, but they are not the principle itself. Lean asks the organisation to understand customer value, remove avoidable delay, build quality into the process and learn from evidence. The operating model must make those ideas visible in everyday decisions.

Software work has a distinctive form of waste. A developer may wait for an architecture decision, a tester may be blocked by an unstable environment, or a feature may sit completed while legal, security or commercial approval is pending. Partially finished work can create the same economic burden as excess inventory in manufacturing. It consumes attention, hides risk and increases the cost of change.

The case therefore treated the workflow as a system rather than judging individual productivity. The research team mapped how an idea travelled from customer request to released capability. It identified queues, hand-offs, rework and approval points before proposing new ceremonies. This approach helped the organisation avoid a common mistake: adding more meetings to compensate for a process that remained opaque.

The Case Setting

The organisation in the case was a medium-sized industrial technology supplier with offices in Melbourne and Gothenburg, a development partner in Brisbane and several customer sites across Australia. Its software connected operational data with equipment maintenance and production planning. Customers valued the product, but implementations varied widely, and urgent requests frequently displaced planned work.

The team included product management, software engineering, user experience, testing, operations, customer support and a security specialist. Work arrived through several channels: sales commitments, service incidents, regulatory requirements and internal improvement ideas. Each group used its own spreadsheet or ticket queue, so the apparent priority depended on where a request was recorded rather than on its value or urgency.

The Australian market added practical constraints. Large customers commonly required procurement stages, data-hosting reviews and formal vendor assurance before a release could be adopted. A Brisbane engineer might finish a task late in the afternoon while a Scandinavian stakeholder was beginning the day, creating a long feedback gap. Teams also had to account for public holidays across states and for customer operations that continued through the summer shutdown period. “No worries” could signal goodwill, but it could not substitute for an explicit risk decision.

The research engagement began with observation rather than software installation. Researchers interviewed participants, followed representative work items and compared planned dates with actual movement. They found that the board showed activity but not flow: cards were moved when people started tasks, while waiting, rework and external approvals remained largely invisible.

Making Work Visible

The first intervention was a shared digital board with columns based on the real delivery process: opportunity, discovery, ready, development, verification, customer validation, release and outcome review. The wording mattered. “Testing” described an activity, while “verification” captured the purpose of the stage and included automated checks, exploratory testing and operational review.

Each item carried a clear customer outcome, an owner for the next decision and an indication of blocked time. The team also introduced explicit policies. For example, no more than three items could be in development at once, and a new feature could not enter development until its acceptance conditions and operational impact had been reviewed. These policies turned assumptions into visible working agreements.

A board is valuable because it supports shared understanding, not because cards are inherently Lean. Teams wanting a practical explanation of the relationship between visual control and flow can review how Kanban boards show flow. In this case, the board became a conversation tool for product, engineering and customer-facing staff, rather than a reporting screen used only by managers.

The visual system also exposed hidden queues. A feature waiting for a customer decision remained in the workflow with a waiting reason and an agreed review date. A blocked item was not quietly pushed to the side. This prevented the team from confusing motion with progress and made it easier to escalate a dependency before it became a missed release.

Designing Flow Around Risk

The team began with a lightweight pull system. When capacity became available, members selected the highest-value item that met the entry policy. This was different from assigning a full schedule several weeks ahead. It reduced the number of commitments that could become obsolete and gave specialists room to respond to urgent operational problems without bringing the entire plan to a halt.

Work was sliced vertically wherever possible. Instead of building a large reporting module across several technical layers, the team delivered a narrow report for one user group, connected to a limited data set, and tested it in a customer workflow. This produced usable feedback earlier. It also revealed that some requested configuration options were unnecessary, while a small permissions issue mattered greatly to administrators.

Quality was treated as a flow condition. Automated tests, code review, security checks and deployment preparation were brought closer to development rather than left until the end of a release cycle. A “done” policy included monitoring, support notes and a rollback approach. This was particularly important for Australian customers operating critical assets, where a technically successful deployment could still fail if support coverage or local escalation arrangements were unclear.

The team also changed its approach to urgent work. Incidents were classified by customer impact, and a small expedite capacity was reserved rather than allowing every request to interrupt active work. Product leaders could still authorise an exception, but the cost was recorded on the board. Over time, this made the trade-off visible: a rushed feature might delay a committed improvement, create test debt or require an after-hours deployment.

Learning Through Delivery Data

After six weeks, the team had enough evidence to establish a baseline. The average lead time from approved request to production was 42 days. The median was lower, but a small number of long-running items created substantial uncertainty. Work in progress averaged 18 items, and 31 per cent of completed items had returned to an earlier stage for clarification, defect correction or rework.

The researchers selected a small group of measures rather than creating a performance scorecard. Lead time showed how long customers waited. Cycle time indicated how long active work took. Throughput showed delivery volume over time. The ageing of work in progress helped identify items that were becoming risky before they were formally late. Rework and blocked time provided context for the other measures.

After three months, average work in progress had fallen to 11 items, and lead time for standard changes fell to 27 days. Rework declined to 18 per cent after acceptance conditions were clarified earlier. The figures were useful, but the more important result was improved discussion. Instead of asking why a person was slow, leaders asked why work was waiting, why a policy was unclear or why a dependency had not been discovered during discovery.

Metrics were reviewed in fortnightly service delivery reviews and monthly product reviews. The team avoided using throughput as an individual target, because that would encourage smaller tickets or premature closure. It also separated normal delivery from expedited work. This prevented an apparent improvement in speed from being created by shifting difficult work into an unmeasured queue.

For Australian organisations, the same discipline can support decisions about offshore coordination, customer support rosters and release timing. A team may discover that a one-hour approval causes a two-day delay because it crosses time zones, or that a local customer validation step is the true constraint. Data makes those conditions discussable without blaming a particular office or supplier.

Operating Model And Practical Recommendations

The case succeeded because visual management was connected to decision rights. Product management owned priority, technical specialists shaped implementation options, and customer-facing staff represented operational consequences. A weekly replenishment session considered new work, while short flow reviews focused on movement and blockers. The organisation did not attempt to redesign every process at once.

Recommendations for teams applying a similar model include:

Digital visual planning made the system easier to coordinate across locations, but it did not remove the need for human judgement. A board cannot resolve conflicting commercial promises, unclear ownership or an executive preference for starting more work. Those issues require governance. The board simply makes their effects harder to conceal.

The organisation also linked improvement experiments to observable outcomes. One experiment reduced the size of the initial release; another moved security review into discovery; a third introduced a regular customer validation slot. Each change had a hypothesis, a review date and a measure. Experiments that failed were retained as learning rather than treated as personal mistakes.

What The Case Shows

Applying Lean principles to software development is less about copying a manufacturing layout than about managing the economics of delayed knowledge. Software becomes expensive when assumptions remain untested, work waits invisibly and feedback arrives after too much has been built. Visualising the system helps the team see those conditions while they can still be changed.

The case also demonstrates why Kanban, agile delivery and Lean process improvement work best as complementary ideas. Kanban provides a way to visualise and control flow. Agile practices support short feedback cycles and adaptable planning. Lean thinking provides the broader test: does the system deliver meaningful value with less delay, rework and avoidable effort?

For teams working across Australia’s major cities, regional sites and international partners, the practical lesson is straightforward. Start with the real path of work, expose queues and policies, limit competing commitments, and use delivery data to learn rather than punish. The result is a calmer and more predictable system in which a team can explain where work is, why it is waiting and what decision will move it forward. What readers should remember is that Lean improvement begins when the whole workflow becomes visible and teams are empowered to improve the system, not when a new board is installed.