Let’s Learn to Do Our Jobs Better, Not a Framework/Method, Better

July 23, 2015 — Posted by Al Shalloway

The software industry seems so caught up in certifications and learning the latest framework, method or approach. The focus is on the wrong thing. It should be on learning how to learn, learning how to do our job better, learning how to collaborate better.  This has sometimes been talked about with the shu-ha-ri metaphor:

  • Shu – initially obey traditional wisdom – that is, just do the techniques without question.
  • Ha - Break with the traditions to go further than the initial practices
  • Ri - Transcend the traditions to do what is truly needed.

I am not sure of the value of this metaphor as I’ve not seen people to use it to spur people on to good actions.  Mostly it’s been a way to justify telling people to do practices without explaining principles (the Shu).  But then I don’t hear people say how to leave a practice via Ha (instead it’s called Scrum-but).

The real challenge is that we’re doing knowledge work – not martial arts. And many people take the metaphor too literally.  In the beginning of studying the martial arts, you are not doing real fighting.  Following practices by rote is ok, because you are in a safe place.  When we start learning an Agile method we are engaged in “battle”.  What’s exacerbates the situation is that many people use sensei’s, er, I mean consultants, who specialize in only one approach.  This means, however, that the range of options is narrow and it is not as likely people will be starting close to where they should.  If one size doesn’t fit all then starting with one-size means you very likely will get a less than optimal starting point.  This is why I recommend finding a consultant who embraces multiple approaches.

We need a better way.  We need to look at how we learn not how to adopt a framework or method.  There are a lot of insights that will help you do this, but I’ve seen two that are critical to understand when transitioning people to a new approach:

  1. As people learn, they go from wanting an answer to wanting to create their own path
  2. Whatever approach we start with may not be the approach we want to be using after a while – so we need to learn to think outside of our approach, a way of transcending our methods

The first point can be characterized in Dreyfus’ model of learning.  People start out as novices, move to advanced beginners, becoming competent, then proficient and finally expert.  In working with people I have found the following table to be useful:

Stage of Competency What They Want to Happen
Novice Be told what to look at and to do
Advanced Beginners Be told what to do
Competent Be provided choices
Proficient Be provided a roadmap
Expert Allowed to make their own roadmap

In other words, any approach we undertake should have the following:

  • A method to decide where to start that’s best for us
  • A well-defined starting point where people can be pointed in the right direction
  • A method to select new choices as challenges arise and/or the abilities of the teams improve
  • A way of navigating these choices
  • A set of principles on which all of this is based so the now proficient people will be able to create their own roadmap

Navigating these paths mean we have to learn how to question our approach. We have found that a method called double loop learning is essential.  Double 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.  Both Scrum and the Kanban Method incorporate single loop learning, but neither use double loop learning (if they did, Scrum and Kanban Method consultants would be telling you when to not use Scrum and Kanban Method, respectively. 

The bottom line is we need to have our focus be on learning how to improve and how to learn.  It shouldn’t be focused on how do I do X (whatever X is).

 

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

Thanks for introducing the Dreyfus stages of competency in this forum. There are lots of smart people in the software development world, but they seem to have a huge blind spot when it comes to adult learning. I hope this starts a great conversation about how people learn to perform.

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