Nik Ilich
Nik Ilich Delivery

Tackling the “Lean” and “Agile” debate – Part 1

As agile & lean practitioners, we’re often asked by clients and interested parties alike to try and delineate the territories for ‘Lean Thinking’ vs an ‘Agile delivery approach’. There are numerous articles and talks that have tackled this question in quite some depth.

It is occasionally tricky to see the ‘value-add’ of conversations like these if the intent is to compartmentalise theory or methodology for simplicity’s sake; i.e. isn’t lean just about eliminating waste in manufacturing processes, and agile a project management methodology for software development? Occasionally people are also looking for what each isn’t in an attempt to protect their patch or status quo (e.g. agile doesn’t belong in operations, or lean is just about process). Enter the evangelists!

What is valuable, is knowing how we as practitioners can apply what we believe to be the right tool, technique or approach to the problem or scenario at hand so that we can assist our customers in realising value.

One thing to note and stress, they are both umbrella terms! They are not really a thing. They are just names used to encompass ways of thinking, and ultimately ways of working including the requisite tool sets and ceremonies.

Given that Lean came before Agile, we’re going to chunk the problem down and start with “What is Lean” in this post.

What is Lean?

“Lean” is a term that was coined by a research team from MIT (Massachusetts Institute of Technology) in the 1990s to describe what they witnessed when touring Toyota manufacturing plants in Japan. That was, the production of high quality vehicles with lower resource consumption in comparison to their western counterparts. In other words, Toyota was delivering the greatest possible value to their customers whilst consuming the fewest possible resources. Lean has since permeated various industries outside of manufacturing, including services sectors such as health and banking and finance, where people interact with processes to deliver outcomes for their customers.

Unfortunately like most management fads, the world rushed to understand how they too can implement this latest methodology called “Lean” / “Toyota Production System” (TPS). When this happens, people tend to look for a recipe that they can adopt to quickly realise the much anticipated benefits (i.e. plug & play). Consequently, lean was misinterpreted by many as simply a set of tools and practices that can be implemented in isolation in their chosen context (kanban, kaizen, fishbone diagrams, andon cords, waste walks, 5s etc.).

Lean is more about what you don’t see on the surface (i.e. the Toyota Management System). We think of lean as a mindset, or rather a way of thinking that is founded on strong values, guided by clear principles, and driven primarily by people, not processes or tools. At its core, lean thinking is based on “respect for people”, putting the “customer first”, and enabling “continuous improvement”. A “Lean House” (framework) is an effective way to portray these beliefs as the foundation of Lean, upon which the various principles are applied to enable the delivery of a consistently high quality outcome, in a timely manner, and at an acceptable cost to the customer (i.e. value).

A Lean House:

Applying a lean mindset encourages us to firstly define what is value in the eyes of the customer (i.e. what outcomes should the process deliver for who), and then empower our people to systematically identify and reduce any sources of inefficiency (i.e. waste, variation, overburden or Muda, Mura, and Muri) in the process that hinders the consistent and cost effective delivery of those outcomes. Put simply, empowered and supported people guided by structured problem solving processes and the appropriate tools and techniques is crucial for improving processes for the delivery of consistent and lasting value for customers. Repeat processes must then be standardised, implemented with effective change management strategies, and continuously monitored to ensure that changes are sustained and future opportunities for improvement are continuously identified. Without standardisation, it is not possible to consistently deliver an affordable, timely and quality experience for the end customer (reference back to the “Lean House” above).

Applying “Lean Thinking”:

At AginicDS, we are team of pragmatic and outcome oriented lean and agile practitioners that are passionate about working with people to solve problems. We do not believe in a one-size fits all approach, and prefer to tailor the “how” to suit the specific context / problem we are trying to solve. Whether we are adopting a “lean” or “agile” mindset, both encourage us to clearly define the problem at hand, and iteratively improve towards the ideal state over time. This is reflected in Deming’s Plan, Do, Check Act (PDCA) cycle pictured below, which we believe adequately reflects the continuous improvement philosophy at the heart of both lean and agile. In agile speak, we also explain this transition as Discovery (Plan), Delivery (Do and Check), and the Retrospective (Act /Adjust).

The Deming PDCA Cycle:

In today’s’ complex operating environments, we do not believe that a linear approach to solving problems will always work. As a result, our approach to solving problems respects this reality by encouraging us and our clients to be comfortable with adjusting or adapting our focus or thinking at every stage of the process where it makes sense. In a broad sense, we often follow the phases of PDCA, or Discovery, Delivery and Retrospectives for our engagements, but change tack and revisit our assumptions if we believe it is beneficial for the client and/or end customer to do so.

We have outlined below some of the key outcomes of each phase of a typical project, but stress the important of remaining flexible to “how” these outcomes are achieved.

Plan (Discovery):

In the discovery of planning phase of an initiative, we seek to:

  • Clearly understand the problem we are seeking to solve (i.e. the gap between the “current” and “should-be” states);
  • Build a team around the problem that contains the necessary experience / capability to solve the problem at hand;
  • Understand and quantify the impact of the problem so that we can measure the success of the initiative;
  • Explore the current state of operations in depth to better understand and elucidate the potential causes of the problem, and also to contextualise the problem in the end-to-end value stream or process so that we mitigate the risks of isolated problem solving (i.e. take a systems view of the problem to minimise unintended upstream and downstream impacts);
  • Define a future state vision to provide clear line-of-sight as to the ideal position, which we use as a true north or guide for focusing our attention on those actions that best align us with where we want to be;
  • Collect and analyse data to assist in identifying and prioritising the critical causes and root causes of the problem that we must define countermeasures (solutions) for in order to prevent the problem from recurring, and ultimately move towards the future state;
  • Brainstorm and prioritise the countermeasures (solutions) that are feasible and we believe will effectively address the identified root causes of the problem.

Do / Check (Delivery):

Once we have an agreed “next” state of operating that we believe will address the problem, we seek to conduct a real-life test / pilot within a limited blast radius to test the effectiveness of the solution/s prior to large scale implementation. As part of this phase, we:

  • Define an appropriate pilot context (“contained” but “representative” of reality);
  • Train and support the impacted staff (e.g. tools & template) in implementing the required changes;
  • Establish appropriate feedback loops and measurement systems to gather, assess and action if necessary both qualitative and quantitative insights gleaned from the pilot;
  • Analyse the results to determine the effectiveness / success of the solution/s (i.e. compare results against targets for the pilot).

Act (Retrospective):

At completion of the pilot / delivery phase, we conduct a retrospective or review with the project team to determine whether we have delivered the intended value to the client and/or customer as a result of the changes we have tested. The retrospective is also a critical continuous improvement opportunity to review the approach that we are taking with our clients, ensuring that we continue to adapt the approach and improve the effectiveness of the project delivery throughout the lifespan of the project. We typically find that teams continue this practice long after we have completed the engagement.

Kaizen Events – a Typical Lean Engagement:

Given the pace of change of today’s work environment and often the limited availability of personnel, we have found short-sharp improvement events (or Kaizen events) to be an effective way of delivering impactful change quickly. A kaizen event is a focused event typically held over 3-5 days with a committed team that focuses on solving the problem at hand. The intention is to bring the right people together with focused attention (minimal disruption), and complete the event with an agreed plan to pilot at the end. AginicDS is currently engaged with an NDIS client in Sydney, where the team are running “Kaizen Events” (rapid problem solving events over 3-5 days) with frontline employee involvement to rapidly overhaul and re-define key business processes that are currently impacted by delays, rework, and duplication.


Get in Touch

Leave a Reply

avatar
  Subscribe  
Notify of