What Every Framework/Method Should Have

March 27, 2015 — Posted by Al Shalloway

I was asked my thoughts about the blog LeSS SAFeTM.Comparison. It prompted me to think - many people are comparing one approach to another.  I've done this myself as I think it's a way to learn options that are available. But most folks don't go far enough. Instead of asking "how does A compare to B?" perhaps we should be asking "what does A and B need?"  

The Key Components of a Framework Or Process

  1. A Well-Defined Starting Point.  People must understand the approach they are undertaking.  Everyone must buy into this explicit starting point. 
  2. A Method of Getting to a Reasonably Good, Well-Defined, Starting Point.  Most approaches provide one starting point - either one defined by the approach itself (a la SAFe) or exactly where you are, no matter where that is (a la the Kanban Method).  
  3. An Elaboration of the Principles on Which the Approach Is Based.  Most everyone claims there approach is based on Lean now. But not all truly are. 
  4. A Roadmap for Improvement. How should one abandon practices and adopt new ones within the approach being taken?
  5. A Re-thinking of What One Is Doing.  You should be questioning your own approach on a regular basis. Systems are complex, results vary.

Let's go through each of these in a little more detail 

A well-defined starting point. As Dean Leffingwell well eloquently says "People want a noun." By this he means they want to know what to do and have a simple way of identifying this.  For years I had resisted this  thinking I needed to get people to think right out of the box. But, the reality is, people do want to understand what they are doing when they start something new.  The trick is not to tell them everything, but it also is not to make them re-discover everything. Organizations transitioning with Lean-Agile methods must have a well-defined starting point that everyone has bought into.  From there, they can see how to improve.  

A method of getting to a reasonably good, well-defined, starting point.  Where to start is very important decision.  It should consider where you are, your culture, who is driving the transition, technical methods/debt and more.  There are 40 or so inflection or decision points that can be used in achieving a reasonably good starting point.  A blog called How Where an Approach Starts Seems to Influence it Forever examines how we approach starting an Agile transition influences us for a long time. Investigating where to start is it makes it clear there are alternatives, which assists us in re-evaluating our approach.

An elaboration of the principles on which the approach is based.  Most every approach now claims they are based in Lean.  Some are, some aren't.  Having Lean in your name or marketing literature doesn't mean anything.  Lean is based on systems-thinking (taking an holistic view and recognizing the impacts of one part of the system on another, attending to time ("just-in-time") and building quality in.  An approach must explain why it works, not merely provide an answer and explain that it is Agile.

A roadmap for improvement.  As your organization adopts whatever its new approach is and as it moves forward, backwards or merely stagnates, your people will need to abandon practices while adopting new ones. Approaches should describe how to move from one practice to another.  I often see teams dropping sprints and now claiming to be doing Kanban.  But never explaining what Kanban practices they were doing.  Each practice has a purpose.  It's fine to drop it, but how you now accomplishing the purpose of the dropped practice (see How to Abandon Practices).

A re-thinking of what one is doing.  If no "one size fits all" why are we not looking at if we have the right "size"?  I am not sure of one approach that incorporates double-loop-learningDouble loop learning is the modification or rejection of a goal / approach in the light of experience.  Double loop learning recognizes that the way a problem is defined and solved can be a source of the problem. "Single-loop learning" is the repeated attempt at the same problem, with no variation of the method and without ever questioning the goal.  

In A Nutshell

Our transition to better methods should include a process to tell us how and where to start.  But it must also guide us in navigating new practices while abandoning ones that have become less useful. It must aid us in understanding what is useful and even challenge the methods we are using.  While transitions to software development are about learning, we shouldn't have to re-learn basic principles or practices.

What if your approach doesn't have all of these things in it? Add them yourself.  No framework, approach or method is complete.  Use whatever you are using as a set of tools, not as the answer.

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 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


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