The Essential Ingredients of a Navigation System

February 26, 2011 — Posted by Al Shalloway

At Net Objectives, a fair amount of the work we do is helping organizations move from where they are to where they want to be. We call this Lean-Agile Transition. Part of what we do is create a road-map from where they currently are to where they want to be with either assessments or our specialized Lean-Agile Transition workshop. Don't worry, this blog is not going to turn into a sales talk. It's just that in doing this, we were discussing that what we do is not unlike a GPS navigation system.

In discussing such a system, we asked – "what are the essential components of a navigation system?" We came up with four:

  1. You must know where you are
  2. You must know where you want to be
  3. You should have a variety of routes to get from where you are to where you want to be
  4. You need to enable the user a way to pick the route that's best for them.

For example, when I use my Android to navigate to a place, it asks me where I want to go (#2) – it knows where I am because of the built in GPS (#1). It then asks me if I am walking or driving (#4) - in its database it has walking routes, fast driving routes, shortest driving routes, etc., (#3).

I think it's self-evident that these four components are the basics – the minimum system required for a decent navigation system. Imagine, if you will, having a GPS that only gave you one route to choose from. This would mean that in many instances, the system would be very ineffective. For example, if you wanted to walk from where you were to where you wanted to go but the system only gave you driving directions, you might have to go around the block due to one way streets (or worse, be told to drive on a road with no sidewalks). Even if you were always driving, you might want options to avoid expressways due to the higher risk of traffic problems (or, if you're like my wife, you just don't like driving on them).

A "one-size fits all" approach to a system as simple as navigation doesn't work. Yet, how many consultants do you know have more than one route to get you from where you are to where you want to go (#3)? In fact, how many don't even ask you about where you want to go, but assume they know right from the start? (ignoring #2) I think making software organizations more effective is a lot more complicated than a navigation system. I'd be aware of anyone whose actions implies it isn't.

Alan Shalloway
CEO, Net Objectives

Related links:

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.


Comments

I my mind a navigation system for an organisational change isn't too different from a navigation system for developing a software system. Hence I don't need to know exactly where I want to go (#2), but only the general direction as that will allow me to learn and be wiser on the end goal along the way.
And sometimes you don't even have to know the general direction. In highly complex, non-linear or low transparency situations, there's no way to know what direction is right and what is wrong. You simply have to do something to acquire knowledge. Poke the system.

Obviously there is a period of learning required to figure out where you are going. As I mentioned, we do assessments, or some basic training to get a foundation of understanding.  But after that, it is important to know the general direction, even if the final destination is not known.  I believe there is a science underneath software development.  This does not mean everything is deterministic.  For example, quantum physics is a science and is clearly not deterministic.  Lean product development flow tells us some things that virtually all organizations want to do:

  • lower delays between steps
  • focus on working on most valuable things
  • avoid having too many things being worked on at once
  • create acceptance test specifications prior to writing code
  • create visibility of the work-flow (both what and how
  • more ...

If these things aren't being done, then your destination should include them.  I believe there is more certainty in the destination than there is in the method of getting there.  In other words, we take a step in the direction we want to get, get some feedback and take another step.

Alan ShallowayCEO Net Objectives

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