How Where an Approach Starts Seems to Influence it Forever

September 27, 2014 — Posted by Al Shalloway

Note: this blog is part of the Series of Blogs on Scaled Agile, Lean-Agile and SAFeTM

Those who cannot remember the past are condemned to repeat it.  George Santayana

The more things change the more things stay the same. Jean-Baptiste Alphonse Karr

While I’ve always had an interest in history, I’ve never considered myself to be much of a student of it.  I’ve mostly found it interesting and useful to keep my arrogance in check.  By watching very smart people do amazingly dumb things out of arrogance makes me realize that there but for the grace of god go I.

Having been in software development for 44 years now and Agile development in particular for 16, I have seen both of the above consistently.  It is worth seeing our past because we are doomed to repeat it if we don’t.

Both eXtreme Programming and Scrum started out with small development teams.  It is interesting to observe that Scrum still adheres to a model of development as if only a team level is needed.  I have seen many in the Agile community (primarily those adhering to the philosophy from which Scrum sprang).  It is interesting to note that the Agile manifesto, which sprang mostly from Scrum and eXtreme Programming proponents, mentions business twice, the customer three times, management not at all, and the team seventeen times.

In my view, Scrum is still overly-centric to the team - which is one of the reasons it can’t scale on its own.   There is no discussion or even recognition of management except to protect ourselves from it.  Thank goodness the chicken and pigs story is no longer taught, but that was more political correctness about religions than it was a recognition that management plays a role in Agile.

The challenge with this team centric point of view is not just that management has been left out of the picture.  In large organizations, the relationship between stakeholders and teams is much more complicated than what can be filled by the product owner role.  The role of a product manager and a product owner is needed.  The product manager holds the space for the stakeholders to communicate with the product owners which hold the space for the teams. 

Many in the Agile community say this extra layer creates heaviness and is not Agile.  But it better defines the responsibilities required.  Few people have the ability to talk to the mindset of a marketing manager who is responsible for billions in sales while also being able to talk to development teams.  Having separate roles here enables much better flow of information. 

Again, at different scales the challenges are different.  In multi-billion dollar organizations with multiple stakeholders, product managers are required to help decide what to build.  Further down the value stream these high-level capabilities need to be decomposed by product-owners within the bigger picture context of driving from business value.  This realization is what implies the organization of business value by portfolio, program and team. More on that in later blogs in this series.

The Kanban Method is not impervious to this pattern either.  The Kanban Method started out with maintenance organizations. Maintenance organizations do not have the same dynamics of product development organizations.  Unfortunately, this does not always seem to be recognized.  In a maintenance organization load-balancing can be accomplished with a simple kanban system, teams are typically not needed and the workflow order is readily known (i.e., the need for acceptance test-driven development is accomplished via other methods).  So, in the Kanban Method’s roots of maintenance, these issues may be safely ignored.

However, Lean suggests load balancing, organizing into teams and adopting a good work order prior to implementing a kanban system.   I’ve often surmised that part of the reason LKU Kanban mostly ignores two of these issues, is because they weren’t relevant in maintenance organizations.  The point is to always be concerned about momentum playing a role in not changing one’s attitude about things once an approach has been settled on.

Please discuss these on the Lean Systems Society Discussion Group.

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 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