Note: this blog is part of the Series of Blogs on Scaled Agile, Lean and SAFe^TM 

Net Objectives has been assisting large scale clients become Agile for almost a decade.  This blog describes the key components of this thinking and how they address the main causes of waste at scale. Our next blog will describe how this thought process can be thought of as the essence of the Scaled Agile Framework.  In the same way Lean can be used to explain why Scrum works, this larger view of Lean can be used to explain why SAFe^TM works.  It is not a choice between the two, it is a way of using one to think of the other.

Lean can be thought of as a combination of Lean-Thinking, Lean-Management, Lean-Culture and Lean-Tools. All four of these are needed to be effective and can be summarized as follows:

Lean-Thinking is essentially the “laws” of lean.  This is systems thinking, flow, building quality in. Many like to think of software as a craft or art.  While there are these aspects in software development, there is at least as much science.

Lean-Management is the transformation of managers to leaders and coaches.

Lean-Culture is an attitude of continuous learning and the agreement between managers and developers that they will work together to improve their methods.  In includes an attitude of win-win-win (company wins, customer wins, employees win).

Lean-Tools are used to help us get our work done.  Kanban, 5-whys, visual controls and A3s are such common tools.

In a decade of working with large organizations transitioning to Agile methods, we have found the following must be accomplished:

• Work must be driven from business need and organized in a hierarchy of portfolio, program and team
• Architectural and technical issues must have a representative equal to the business stakeholders of the organization
• Work must be decomposed starting with business capabilities until it is broken down into features.  Using minimum business increments (MBIs) are invaluable
• The product owner role must be expanded into a product manager and product owner role
• There needs to be an enterprise and system architect roles to manage technical issues
• Someone needs to be responsible for managing the development value stream
• Teams must coordinate via shared backlogs and synchronize on a regular basis
• It is important to try to achieve cross-functional teams when it is economically viable
• Planning must deal with expected releases, risk management, dependency management and how to coordinate work
• The proper work flow order, typically including some form of acceptance test-driven development, must be considered.
• One must take a realistic approach and recognize where you are.  This includes addressing your ability to accept change, current state of technical debt, degree automated testing and degree of continuous integration.

It is interesting that most practitioners find these self-evident.  I suspect that is because they are facing, first hand, the issues involved here.  Most consultants, on the other hand, often attempt to take their approaches and see how to apply them to the job at hand.  Or, as often as not, apply their approaches regardless of where they are.

Oddly enough, the Scrum approach of force-fitting a particular approach (cross-functional teams working in a time-boxed manner) and the Kanban Method approach of always creating visibility and implementing a kanban system before doing organizational change are both variations of a one-size fits all.

Please discuss these on the Lean Systems Society Discussion Group.

Al Shalloway 
CEO, Net Objectives