The New View of Lean-Agile Software Development

February 27, 2016 — Posted by Al Shalloway

Lean has been described in many different ways.  The view I am promoting here is specifically for Lean being applied to software development.  This is quite different than when Lean is applied to problems in the physical world such as manufacturing and product development.  Software has unique challenges and they require a different method of applying the Lean mindset and principles.

Lean can be thought of as a combination of mindset (belief system), principles used for guidance and practices. 

The Lean Belief System

Take a systems thinking approach. Systems thinking tells us we have to look at the whole. That focusing on aspects of our challenge will result in unanticipated side effects. Furthermore, the belief is that the system within which people find themselves almost always has a greater impact on their performance than their abilities.  Hence, when looking to improve the performance of an organization a Lean-thinker will look to improve the system and not so much the people in the system. This is in direct contrast to most of our popular methods which tend to focus on only certain aspects of the systems within which we find ourselves (see Framework Tunnel Vision). 

People will do well in a good system. You can think of this as Lean’s perspective on ‘respect people’.  ‘Respect people’ is a mantra of the Agile community but it’s hard to tell what that means from a decision point of view.  Respect people to do what?  To do their best?  While that may be true, doing their best may not be good enough – not if they are in a bad system.  Systems thinking and believing that people need a good system within which to operate means we must focus on improving our systems as well as our people.

Be committed to quality. This has often been called ‘build quality in’ but it is much more than that.  It is a commitment to high quality – to not just the quality of the product, but to the quality of the process.  Yes, the process – that very word which is somewhat denigrated in the Agile Manifesto.  Be clear, I’m not saying we should be committed to a process, rather I’m saying if we think there is a method by which we’re supposed to work then we must work that way to achieve our best results.  In other words, we don’t have conversations about ‘is this good enough?’ For example, if we say that we believe having test specifications are a good thing then we always have them.  We do this because we have a belief that the system causes most of our errors, our process is part of our system. Hence, if we have errors then we most likely have something wrong in our system.  If we don’t fix it now, more errors will result.  More waste, more cost.  If you have a leak in your basement when do you fix it?

A Commitment to Continuous improvement. One of the innate human characteristics is to strive to improve.  Improving our methods is more than a business imperative, it is essential to provide meaning to one’s existence.  Continuous improvement should involve how we work and be and not just the results of it.  There is a business an human aspect to this.  Both very important.

Leadership. Unlike the Agile Manifesto which does not mention management once in either manifesto or in its principles, Lean puts a strong requirement on management to lead an organization in the beliefs just mentioned.  This is managers as leaders.

Lean Software Development Principles

Drive from business value.  Lean is about the delivery of business value incrementally, predictably, sustainably and with high quality. Driving from business value provides both a great return on our capabilities as well a method of aligning across the organization.  As Don Reinertsen says – There is more value created with overall alignment than with local excellence.”

Create Visibility.  This means visibility of our work and our agreements.  Our agreements are both between management and those doing the work and between those doing the work. These typically involve creating explicit workflow agreements.  These explicit agreements enable everyone to know what is going on and is the basis for Lean’s visual controls.  Visual controls are a special kind of information radiator that visualizes both he work and how the work is being done.

Achieve flow through the elimination of delays and rework (eliminate waste). This is often characterized as “just in time.” While developing software (either in IT or product development) is not the same as building cars, this mantra is orders of magnitude more important in software than in the physical world.  I would suggest that all challenges in an organization will manifest themselves as a delay in feedback, a delay in feedback or a delay in value delivered.  It stands to reason then that a focus on eliminating delays will improve our workflow.

Manage queues and work in process.  It is important to both not be working on too many things and not have too many things be waiting to be worked on.  Working on too many things causes delays in our workflow.  It causes people to wait on each other.  While people talk to the clear task switching that results the much more insidious aspect of this is just having work wait around.   This is one of the more important aspects of Lean – it shifts our focus from doing what we do better to eliminating the delays between the work itself.  Again, in software this is way more critical than in manufacturing or physical world product development.  A quick look at what happens when delays between code and test occurs provides huge evidence for this.

In Summary

I am suggesting to look at Lean as a combination of mindset, guidance and practices (which I admittedly haven’t specified as yet).

Core Lean beliefs include:

  • Taking a systems thinking approach
  • That people will do well in a good system
  • We must be committed to quality
  • We must have a commitment to continuous improvement

Lean Software Development Principles include:

  • Driving from business value
  • Creating visibility
  • Achieving flow through the elimination of delays and rework (eliminating waste)
  • Managing queues and work in process

It is important to note that we can take these beliefs and principles and apply to them to any set of practices we undertake.  We can also use them to see why some frameworks and methods work and how we can improve them.  The question isn’t whether you should be doing Lean or not. The question is whether Lean’s beliefs seem right to you.

Al Shalloway, CEO

Net Objectives

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.


Comments

Al,
Thanks for the lean concepts review. I work in a SAFe environment and lead the lean and agile movement within my company. I am often telling people we are too busy to be good. The leads to many wait cycles because we are optimizing local work. We spend quite a bit of time worried about our communications and teamwork at the team level and not so much time worrying about the communications and teamwork at the organization level. Maybe it is because this is a harder nut to crack. Until an organization learns how to have these local pieces work as a system they will continue to be sub-optimized.

The title of my response is "We are too busy to be good." This needs to be addressed as a system failure from the top leaders in an organization. I think many of us tend to focus on agile and the practices that support it. We forget that software delivery is a system and lean concepts can and should be applied. In our case we are using SAFe as a framework to meet our Lean needs. SAFe has system thinking built into the framework as this was the driving reason we all liked it when we selected it 4 years ago. However as we find in the agile practices, we need to ensure we are driven by the principles and not solely by the practices any system brings. Continual improvement to our lean and agile principles from all levels of the organization is required to deliver quality software our customers need, when they need it.

Note: You were the first person I heard in person talk about lean and agile principles in Hollywood about 5 years ago.

Thanks for your comments. Definitely people going beyond their WIP and being busy is a critical process. I've been trying to get folks to realize Lean is the most effective way to see how to start improving the management of organizations to help alleviate this challenge. Several of my blogs (especially the one about why not to try to change culture, but to focus on management systems) has been lost on much of the Agile community. SAFe has taken us a step in the right direction in many ways, and in the wrong direction in others. Of course, this isn't SAFe's fault, as with everything, it depends how you use it.

Thanks for your comments. Definitely people going beyond their WIP and being busy is a critical process. I've been trying to get folks to realize Lean is the most effective way to see how to start improving the management of organizations to help alleviate this challenge. Several of my blogs (especially the one about why not to try to change culture, but to focus on management systems) has been lost on much of the Agile community. SAFe has taken us a step in the right direction in many ways, and in the wrong direction in others. Of course, this isn't SAFe's fault, as with everything, it depends how you use it.

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban