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

The Intersection of Lean and Agile: Insights from Celean

Lean and Agile are often presented as separate management systems, with lean associated with operational efficiency and Agile associated with software delivery. In practice, organisations frequently combine their ideas. They use visual workflows, short planning cycles, customer feedback, pull-based prioritisation and continuous improvement across both physical and digital work.

The Chalmers Electronic Lean Research Team, known as Celean, offers a valuable perspective on this overlap. Its work connects digital visual planning, Kanban, visual project management, enterprise systems and lean processes with the realities of industrial collaboration. The emphasis is less on adopting a fashionable label and more on understanding how work becomes visible, coordinated and adaptable.

That distinction matters for Australian organisations. A manufacturer in Melbourne, a mining supplier in Perth and a public-sector technology team in Canberra may all use Agile boards, yet face very different constraints. Distance, regulation, labour arrangements, legacy systems and uneven digital capability shape whether a method improves flow or simply adds another layer of administration.

Why the boundary matters

Lean and Agile share several operating principles. Both encourage teams to make work visible, limit unnecessary activity, shorten feedback loops and improve processes through repeated learning. Lean often starts with customer value, flow and the removal of waste. Agile places greater emphasis on responding to change, delivering in increments and keeping teams close to users.

The difference is usually one of emphasis rather than opposition. Lean has deep roots in production systems and examines how an entire value stream performs. Agile emerged strongly from software development, where requirements can evolve rapidly and finished work is often delivered in small releases. Modern organisations bring these traditions together because their work crosses physical production, engineering, procurement, service and digital platforms.

Celean’s research context is useful because it treats this connection as a socio-technical issue. A digital board is not automatically a lean system, and a Kanban column does not guarantee effective flow. The tool must reflect how decisions are made, how dependencies are managed and how people interpret information during daily work.

That is especially relevant where a business has several locations. An Australian engineering firm may coordinate a design office in Sydney with production in Adelaide and suppliers in regional New South Wales. A shared visual system can expose delays across those boundaries, but only when the information is current, trusted and connected to actual decisions.

What Celean brings to the conversation

Celean brings together university research and industry collaboration through Chalmers University. Its focus includes digital visual planning, Kanban, visual project management, enterprise systems and lean processes. These areas sit at the point where management theory meets operational detail: what appears on a screen, who updates it, how priorities change and what teams do when the plan no longer matches reality.

The team’s connection with industry partners, including organisations such as Volvo, gives this work a practical setting. Large industrial businesses rarely operate through one neat workflow. Product development, production planning, quality assurance, purchasing and maintenance all have different tempos. Research into visual coordination must therefore address interfaces between functions rather than treating a team as an isolated unit.

A central insight is that visibility is a form of organisational capability. When work is visible, teams can identify queues, blocked tasks, overloaded specialists and competing priorities. When work remains hidden in email, spreadsheets or individual knowledge, managers may respond to symptoms instead of causes. Digital visual management can help, but it needs rules about ownership, timing and escalation.

This also explains why prototypes and research tools matter. A prototype can make an abstract process easier to test with practitioners. Teams can examine whether a planning view supports a real meeting, whether a Kanban policy changes behaviour and whether enterprise data is sufficiently reliable for operational use. The value lies in learning from that interaction, not in treating software as the final answer.

Pull, flow and visual control

Pull systems are central to the shared ground between lean and Agile. In a pull system, new work enters a process because capacity is available or a downstream need has been signalled. This contrasts with pushing tasks into a queue simply because someone has decided they should begin. The principle applies to manufacturing, software, engineering changes and administrative work.

Knowledge work makes pull more complicated. A developer, analyst or engineer may be handling several items that require specialist input, approval or customer clarification. A board can show that a task is in progress, yet it may not show that the task is waiting for a decision outside the team. Research into pull systems in knowledge work helps frame this problem as a question of workflow design rather than personal productivity.

Visual control works best when it makes constraints discussable. Useful signals can include work-in-progress limits, ageing items, blocked tasks, cycle time and the number of handovers. These measures should support conversation about the system. They should not become targets that encourage people to split work artificially or move cards without improving delivery.

Teams also need to distinguish between activity and progress. A crowded board may indicate energetic work, but it can equally indicate too many simultaneous commitments. Lean and Agile thinking both encourage a shift towards completed value, shorter feedback and fewer unfinished items. That shift can be uncomfortable in organisations where starting work is rewarded more visibly than finishing it.

Useful signals for a visual workflow

Digital tools need human capability

Digital transformation often exposes a skills problem before it solves an operational one. A team may receive a new planning platform, connected equipment or data dashboard without gaining the ability to configure, interpret and improve it. This is relevant to edge computing, industrial IoT and enterprise integration, where engineers need both domain knowledge and digital fluency. Discussions about training engineers for edge roles underline why capability development must accompany new technology.

Celean’s research themes point towards the same lesson. Digital visual planning is not simply a user-interface exercise. It involves process modelling, information quality, organisational routines and the social dynamics of meetings. People must understand what a status means, when an item should be moved and how exceptions should be recorded. Without that shared understanding, the system becomes a decorative reporting layer.

Enterprise systems can create another tension. They are designed to standardise data and support broad organisational processes, while Agile teams often need lightweight ways to adapt their local workflow. Integration is valuable when information can move between planning, delivery and performance systems without excessive re-entry. It becomes harmful when teams spend more time maintaining the tool than managing the work.

A sensible approach is to develop capability in stages. Start with a clearly defined workflow, train users in the purpose behind each visual element and test whether the information supports a real decision. Then refine the system with practitioners. This is consistent with a research mindset: observe use, identify friction, adjust the design and evaluate the result.

Reading lean-agile through Australian operations

Australian organisations apply these ideas in a market shaped by long distances, uneven population density and strong sector differences. A manufacturer in Melbourne may have relatively close access to engineering partners, while a mining operation near Perth may coordinate with suppliers and specialists across vast distances. A visual workflow can reduce uncertainty across those networks, but digital connectivity does not remove time-zone, transport or maintenance constraints.

Work habits also influence adoption. Hybrid teams in Sydney, Brisbane and Canberra often rely on short video meetings, chat messages and shared documents. These tools can support daily coordination, yet they can also scatter the record of decisions. A disciplined visual system provides a common operational reference, especially when a team includes office staff, site workers and external suppliers.

Regulation adds another layer. The Fair Work Act 2009 affects employment arrangements and consultation expectations, while work health and safety duties require organisations to manage operational risks rather than treat speed as the only objective. The Privacy Act 1988 and the Australian Privacy Principles are relevant when workflow systems store employee, customer or contractor information. A lean-agile implementation must therefore improve flow without weakening privacy, safety or fair working conditions.

The local market also includes many small and medium-sized businesses that cannot fund a large transformation office. For these organisations, the strongest application may be modest: a shared board for engineering changes, a visible replenishment policy for customer requests or a weekly review of ageing work. The method has to fit available capability and commercial pressure. A complex framework imported from a multinational may be less useful than a simple system that people maintain every day.

A practical research lens for teams

Research-informed improvement begins with a clear problem statement. “We need to become more Agile” is too broad to guide action. A more useful statement might be that engineering requests wait an average of three weeks for approval, or that urgent customer changes regularly disrupt planned production work. The first version invites slogans; the second creates something that can be observed.

Celean’s areas of interest suggest several dimensions for examining that problem. Teams can study how work is represented, how priorities are selected, how information moves between systems and how meetings use visual data. They can also examine whether a change reduces waiting, improves decision quality or simply shifts effort from one group to another.

Questions to examine during a pilot

A pilot should be small enough to learn from and important enough to matter. One product-development stream, maintenance process or internal service queue may provide a suitable boundary. The team can establish a baseline, introduce one or two visual policies and review the effects over several weeks.

The measures should combine flow and human experience. Cycle time, queue age and completion rate can show operational movement, while short interviews can reveal whether people understand the system and whether it supports better decisions. This balance avoids turning lean-agile work into a narrow exercise in dashboard optimisation.

The most useful outcome may be a clearer understanding of the system’s limits. A pilot can reveal that approval authority is too centralised, that an enterprise platform lacks a needed field or that urgent work has no agreed entry policy. Those findings are valuable because they direct attention towards structural improvement rather than asking teams to work faster inside a flawed process.

The next step is to select one Australian workflow, map its current waiting points and run a four-week visual pilot with a single agreed measure of flow.