BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Applying Lean Tools and Techniques to Scrum

Applying Lean Tools and Techniques to Scrum

Bookmarks

Key Takeaways

  • Simple Lean tools and techniques are excellent impediment removers by establishing root cause and countermeasures
  • Scrum wastes such as high backlog inventory, are often ignored due to overall net performance gains and are now problematic for remote Scrum teams
  • Scrum can be deemed wasteful when following the ceremonies to the letter of the Scrum Guide, particularly when remote
  • A continuous improvement mindset is reinforced, and in some cases reignited, by embracing Lean, a philosophy of continuous improvement
  • Lean is a psychological safety enabler for a Scrum Master by allowing failures or problems to be discussed as soon as they are detected

Scrum as a framework is complemented by the wide range of Agile tools, frameworks and approaches, so much so that Scrum paired with another framework, or hybrid Scrum as it is classified as, is becoming more and more popular. One such complementary approach is Lean, yet it has an incredibly low adoption rate within Scrum teams. Lean is often misunderstood as a heavyweight process when in fact it is a philosophy, one that is grounded in continuous improvement. Pairing Lean thinking and the application of Lean tools through Scrum can create a more resilient variant of Scrum, one which looks to eliminate impediments at their root cause and build on counter measures to ensure they do not repeat. 

This article focuses on some of the challenges that Scrum is facing as a whole, but particularly so in this remote centric world we have found ourselves in for the past year. The topic of waste, a central theme that Lean helps focus on, shows us that Scrum can be improved upon, and by raising awareness that good can be better, and teams can realise a more high performing variant of their Agile approach with minimal training or upskilling needed.

Main challenges remote Scrum teams are facing

Scrum teams are beginning to discover that Scrum as a framework can in fact be defined as wasteful. That waste is often masked by in-person interactions, which Scrum has always advocated for. While Scrum pairs well with other Agile frameworks and approaches, Lean, an approach which focuses on waste reduction, is rarely paired with Scrum for this to become visible. This has led to a lack of awareness or focus on the elements of waste that exist. 

The movement to remote work has brought a lot of changes outside of how a team operates to contend with. You have subpar facilities compared to an office. From simple lack of space, with some friends of mine working off of a kitchen table for over a year now, to not having appropriate ergonomic equipment at home to handle a 40-hour week. That’s before the added strain of other people or families in the house; in my case, I have a 2.5-year-old, an 18-month-old, and a newborn which brings an added dimension to the day! 

So off the bat, the environment changes are difficult to handle, but when you keep following Scrum as per the Scrum guide, you see a magnification of the issues which I am attributing to waste. Take, for example, the recommendation for Sprint Planning, of taking up to eight hours to complete. Ergonomically, we are looking at taking 10-minute breaks every hour. Sitting on a video call for the bulk of your day is not just uncomfortable; it’s not productive or participatory. Often, calls that involve technical discussions to break down user stories are led by a small number of people, often the experts. In person, the interactions are much more fluid and involving; when sitting on a video call up to 80% of your team are idle, with distractions aplenty through emails, chat channels and the internet at large. 

It’s a similar experience for other ceremonies, and I am finding that teams are becoming more mechanically Agile, in that they are doing the ceremonies and following the process, but starting to lose sight of the rationale and reasons behind why we do such things; that’s the mentally Agile aspect that good coaches try to instill. To try and address some of those challenges, I have started to look at Scrum through a Lean lens.

Why Lean?

Lean is something I always had an interest in; it’s something a lot of people misunderstand and perceive to be another framework. Lean is a philosophy, and its origins go back to the 1930s Toyota Production System, so it has a huge head start on the wider Agile software movement. 

Lean is definitely an inspiration for Scrum and other such Agile frameworks, but over time, the overall Lean influence within Scrum, was reduced down to an emphasis on the need for continuous improvement. That mindset is actually underpinned by the empirical process approach that Scrum is founded upon. Lean provides a lot of tools and techniques that focus on waste reduction, which never translated over into Scrum. My personal thoughts as to why that is the case is the simple fact that teams who have adopted Scrum after following no methodology or a Waterfall approach have seen huge improvements in their new way of working, versus the older way. It’s often a case that teams are pleased that this new way is faster, more efficient and more enjoyable than the old way, and the status quo is achieved. This leads to stagnation, as the Continuous Improvement mindset that both Lean and Scrum share slows down. Retrospectives become tiring, the team feels they have achieved their perfect version of working and they work within the confines of their environment. 

I have seen this and as a coach, I know the team can achieve more and tighten up; I tried a number of different approaches to bring about change but always felt there was a gap in my toolbox. It turns out that gap was Lean. The interesting thing is the team was unaware of Lean or the complementary nature of its tools and techniques; such is the prevalence of Scrum tools and approaches. I feel that this gap would have gone unknown and unrecognised by the team without someone having explored it with a view to improving the current status quo. With Lean being predominantly implemented in manufacturing industries, it is unlikely that software engineers would discover this by accident.

Last year with the move to remote working and learning, I went looking at my own performance and development goals with a view to adding something to my own skill set that would interest me and help my team at the same time. A number of years back I was researching a course in Lean that I had almost signed up for at my local college Waterford Institute of Technology. At the time, my workload and travelling for work would not enable me to commit to it, but now I had an opportunity. 

I enrolled in the Masters of Business in Lean Enterprise Excellence. The lecturers there have a world renowned background in Lean and through several thought-provoking lectures and 1:1 engagements, we started to hone in on some of the problems that I was struggling to articulate my thoughts on. I felt there were challenges and improvement opportunities facing some of my Scrum teams with regards to how they were working through the framework in a remote capacity. Viewing my team through a Lean lens gave me enough insight to know that untapped potential existed. Through the course, I’m now undertaking a continuous improvement project, one which results in a Lean Black Belt, and is focused on reorienting Scrum towards Lean. Discoveries out of that project have given me several approaches, tools and scenarios that I could try within my teams. As part of the project, my goal is to share my knowledge and insight, as I am on a journey of learning that hopefully others can learn from and contribute to; this has also led me to the Scrum Master Summit to talk about my experiences to date!  

How waste looks through a Scrum lens

One of the first areas I examined was the Inventory Waste of Lean. This is the waste that encourages a Just in Time manner to production, wherein you don’t hold more stock than you need to create your product, as unnecessary storage costs something. The analogous inventory in Scrum terms is the Backlog. The Backlog is something that teams overinvest in, often due to enthusiasm. 

Within Lean, there is a concept known as Little's Law, which is a queuing theory of probability to look at the arrival rate and service rate to ascertain when you will receive a response. The classic example used is a coffee shop: if you had two baristas, taking one minute to serve a customer and six customers in the queue, you can say with reasonable certainty that you will wait for around three minutes in the queue before being served. 

My team works on quarterly planning to align with business needs, wherein we commit to delivering a certain number of initiatives in that timeframe. We had 15 initiatives in our Backlog and were servicing at a rate of two initiatives per quarter. That’s eight quarters to fully exhaust the backlog, assuming it stays static, and our team had the bulk of those 15 well fleshed out, with multiple conversations with stakeholders and the team to break down the user stories. 

If it takes two years to exhaust the backlog; how Agile is that? That is a long time in a fast-moving industry like software engineering, where the customers' needs and that of the market can change rapidly. The time commitment to flesh out such a backlog is a cost attributed to inventory waste. We implemented a work-in-progress limit to cap our backlog at eight initiatives to begin with, to get our service rate to exhaust the backlog to a year. This has provoked excellent value driven trade-off conversations, as the barrier to enter the backlog is now established, and to gain some of the team's time on progressing a request to the previous depth, the knowledge is there that the request is important.

I recently presented at Devconf.cz on the topic of How Lean is Your Scrum, which is a good 30-minute overview of the eight wastes of Lean that I identified as being present in Scrum. In summary, the eight wastes of Lean are Defects, Waiting, Transportation, Motion, Overproduction, Inventory, Extra Processing, and Under Utilized Talent. The eight wastes manifest themselves through the ceremonies, the backlog and even the cross functional nature of the team wherein cross training and repetition are necessary to achieve the task at hand. 

Additionally, Scrum has difficulty in handling bugs and escalations within a Sprint; any team that is purely customer-facing, in an SaaS environment for example, will understand how difficult it is to plan a sprint when unknown bugs and escalations that are customer-facing hit. Even with reserving capacity, it can lead to missed sprint goals which leads to frustration in the team, and their experience of Scrum becomes tainted by the application of it in a domain that is ill-suited. 

Another issue I have experienced is teams not being set up technically to execute Scrum in an efficient manner. By that, I mean the presence of automation, test beds and infrastructure often emerges during the teams’ sprints in a reactive manner, often brought up in the retrospective. The software engineering best practices mindset is rarely thought out ahead of the Scrum teams’ path, and rarely in my experience forms part of the upfront backlog. The focus on value generation for the customer rather than sustainability for the Scrum team is often the dominant thought and focus early on in the lifecycle of the team. Some teams have a Sprint Zero approach, and this could be a good time to lay the foundation to ensure a frictionless execution of Scrum.

Applying tools and approaches from Lean within a Scrum-based way of working

Lean as a philosophy is driven by the notion of a continuous improvement (CI) mindset. Key elements to achieving that philosophy include the cultivation of a learning organization, with the right management support of the approach. This is often rooted in a culture where the CI mindset can be nurtured and can grow. A Scrum team inherently has the CI mindset in place; it should have management backing and buy-in to help the team transform. Scrum is a very welcoming culture of sharing, working towards goals and a sense of team commitment. 

With that understanding, the application of the tools becomes an easy conversation for the ScrumMaster or team to introduce themselves. Impediments are a way of life in Scrum; Lean has a plethora of tools to help diagnose problems and evaluate root causes to ensure they don’t occur again. The tools are simple to use, involve basic materials to run and require minimal training; they are conversational in nature, and to run a cause and effect it’s a simple matter of guiding a question and answer session with the aim of discovering what happens when this occurs. They are perfect complements to the Daily Scrum. 

The more intermediate approaches, such as the usage of A3 reports for tracking and visualising the story being told from the problem statement, to the identification, countermeasures and resolutions, are hugely beneficial when introduced in a retrospective to bring accountability to the team when they have committed to fixing an identified issue. 

Introducing Value Stream Map (VSMs) can happen at any stage and form a cornerstone of a strong backlog of potential improvement items to drive a wider retrospective. Many Scrum teams naturally pair well with Kanban, and really applying Kanban just takes a small mindset change to make it a real pull-based system with WiP limits adhered to. My own experience is that teams use Kanban for the visuals and the work stage breakdown, which is a super introduction to Lean in one sense, but viewing it another way, pulling value through the system pairs so well with the Scrum mindset of value-driven delivery.

Enabling teams to spot waste

Reinvesting in the Continuous Improvement mindset is a great starting point to always ask the question of can we do better? Taking a very critical look at the team, their process, their tooling and where they are wasting time in a given week can bring a backlog of ideas to tackle that waste. 

A favourite Lean tool is the VSM which will look at the current state and try to identify a proposed future state. When taken in a metrics oriented manner, whereby we time when we are actively participating and when we are idle, we get an activity ratio; the goal being to have as high an activity ratio as possible across the entire Value Stream as well as at individual steps. Low ratios at individual steps are a good sign that we are being inefficient and can provoke conversations to investigate the root cause. 

Pairing that with great tools like Fishbone Diagrams, 5-Whys, Cause and Effect diagrams and other such visual troubleshooting aids that Lean provides can allow us to draw up a Future State. That becomes a roadmap for Agile teams to move towards incrementally, making small changes, implementing countermeasures to ensure they are adhered to, seeing how they settle in, adjusting, adapting and eventually overcoming and moving to the new future state. That should be a future state with minimal waste and an optimised environment, with all of that enabled by simply giving the team time, space and the right tools to try and identify it.

Benefits from removing waste

With awareness of what waste is, the act of removing the waste falls on the team. The Scrum Guide is exactly that: a guide, not a rigid rule book. The teams are empowered in a self-organizing manner to create their own unique flavor of Agile. Previously, they felt constrained by the Scrum Guide, and the need to stay within the lanes it gave them. By raising awareness in retrospectives and individual coaching, an understanding of the principles and rationale for why the ceremonies exist was reinforced. Through doing this, the team is now guiding their own flavor with a marked increase in engagement and participation as they look to modify their approach to eliminate wastes they have identified. This is undoubtedly leading to a stronger, more resilient form of Scrum within the teams, focused on principles vs the execution as per the guide.

The first benefit is an immediate reduction in workload for the team, moving towards the sustainable pace that good teams strive for. We are no longer running a long march on the backlog, are much more efficient in how we run our ceremonies and the preparation that goes into making those ceremonies smooth. We have seen a saving of around 5.5 hours of Scrum ceremony meetings in a week. That capacity is about 20% of the team’s overall output, and this has culminated in the team being able to invest fully in a No Meeting Friday experiment where they get ample time to invest in personal upskilling and have that day as an overflow in case they hit impediments during the week. This has not impacted our delivery capability and has arguably increased our skillset and potential to take on more varied work as time goes on.

The quality of our products is improving visibly sprint on sprint. An emphasis on getting things right first time and performing root cause analysis to ensure that bugs and issues do not reappear has created a higher level of quality and trust in our tools, services and processes, giving the team and our communities a more stable and enjoyable environment to operate in.

Fostering psychological safety

Psychological safety is important within teams to allow an environment where mistakes can happen and can be addressed, with no fear of repercussions. It’s equally important to allow ideation to emerge, with no ridicule associated with an idea. This means we get an environment that produces constant innovation, and people who will happily report their own shortcomings with the view to addressing them in a continuous improvement manner. Psychological safety is something that doesn’t happen overnight, and for the most part doesn’t happen organically. It’s something that needs careful consideration from the leadership team and Scrum Master to help grow it. 

Scrum provides a great starting point in the form of encouraging a safe space for a self-organising team to hold blameless retrospectives, allowing the team to critique their own performance and their role without getting personal. The ability for the team in the daily Scrum to put their hand up and report a potential impediment is also hugely important to allow a potential problem be discussed and evaluated, even if that problem has a human origin. That togetherness of the team moving towards one goal helps to ensure that raising an impediment or reporting an issue is done for the good of the team, and helps to neutralise any personal feeling of blame. 

Backing all of that, I have found that embracing failure as a learning opportunity needs to be backed by leadership, who can work with the Scrum Master and stakeholders to ensure the team has an environment that is conducive to innovation, with the flip side of innovation being that failure has a high probability as we try and stretch the imagination to generate a competitive advantage, and ultimately, value for our customers. A great starting point is reading The Fearless Organisation by Amy Edmonson; we made this available to all of our team to help them understand the culture and environment we want to create in our team.

Conclusion

The topic of Lean in the context of Scrum is an iceberg waiting to be discovered for most Scrum teams. As more maturity emerges in a Scrum team, a noticeable improvement from where they began to where they are now becomes visible. That’s often the point the transformation is deemed a success, and from there on in, sustainability is in mind. That goes against the ethos of Scrum, which always has continuous improvement in mind but this is often neglected in mature conversions. By raising awareness on this topic and the integration of Lean approaches- a philosophy grounded in the pursuit of continuous improvement- teams can easily restart their continuous improvement mindset and create a more streamlined, optimised variant of their Scrum processes to better weather the storm that is remote-centric Scrum.

About the Author 

Leigh Griffin, a senior engineering manager at Red Hat, has been leading remote Agile teams for the past five years. Griffin gave a talk about using Lean tools and techniques to add additional tools to a ScrumMasters arsenal to help with impediment removal and root cause fixes at Scrum Master Summit 2021. The video on How Lean is Your Scrum is a great accompaniment to this article.

Rate this Article

Adoption
Style

BT