An Explanation of My Framework/Method Hopping

December 5, 2017 — Posted by Al Shalloway

I am proud of the fact that I have been accused of method hopping.  I have and I do. The question is why.  Essentially I use whatever method I find to be valuable.  Some have come and gone as being at the top of my list.  Twelve years of building and expanding our own I finally see value in documenting it and using it as our explicit platform.  But let me explain my history.  This is not just a personal story, but is intended to illustrate some learnings.

In the 80s I started becoming reflective about my coding abilities.  I was an extremely fast developer who wrote very brittle code.  I had a reputation for being 10 times faster than the next best person.  In 1984 I noticed a bug (I’m pretty sure not my first) and asked myself for the first time “what was I doing that I put a bug in my code.”  I noticed the irony that before this I always described it as “I found a bug” but this was code no one had been in before, ever.  I then realized the irony of asking the question and asked “how could it have taken me 14 years to ask this question?”  From this point on I started to consider the source of my bugs as often being a result of the environment I was in.  Not a coincidence that at this time I was also studying Deming in a 2 year long business seminar.

When I was introduced to XP in 1999 I was immediately struck by two things.  First, it’s brilliance.  I knew it would work because I had done most every practices at some point in the 15 years prior (for example, automated acceptance testing in 1983).  However, doing the practices in the isolated way I had and doing them without a model to guide my actions was the equivalent of eating an ice cream bar with the wrapper on.  I had clearly never been doing XP before 1999 even though I may have done most of its aspects.  This impressed upon me the importance of a framework for thinking and the value of explicit knowledge.  It also impressed upon me that I typically came up with what were later known as XP practices as a result of needing to fix a problem, but that doing so one, didn’t have me always use them and two, had me re-invent the wheel a lot.

When I couldn’t get development teams to pair-program I switched to Scrum.  This, I believe is my one real sell-out.  I see now that working more on getting XP adoption would have been good.  BTW – pair programming is an interesting example of something that easy to explain and even easy to do.  But difficult to get people to do it.  After using Scrum for about 4 years, we started getting into Scrum at scale.  Back in the day (2004) this was 3-4 teams.  Scrum of Scrums was the in thing so we tried that.  Couldn’t get it to work (still haven’t figure out how). 

Our president, Alan Chedalawada (who is the one who originated most of our business driven philosophy), decide to try shared backlogs based on our prior Lean experience.  It worked well, and Guy Beaver and I wrote some of this up (2009) in our Lean-Agile Software Development book and called the method the product coordination team – which is essentially what people now call Scrum-of-Scrums where the teams collaborate on what they will build before self-organizing on it.

It was clear to me that Scrum as limited to its practices and mindset on how to find impediments and remove them was great for a team but limited for an organization.  Lean was providing us insights on how to see the major impediments with just a few conversations (see Value Stream Impedance VSI). Most people already have the ability to see this, but making the VSI more explicit enhances that ability.  I started talking about the importance of Lean in Scrum around 2005 after having quite a bit of success in doing so.  This was not appreciated by the Scrum thought leaders of the time and they accused me of trying to sell my own method (as if I owned lean). 

I was in this dilemma of knowing there was something better than Scrum at the organizational level (for which it was not designed) and having to make agreements about what our CSM courses were containing.  I decided in favor of going for customer value even though this definitely cost me hundreds of thousands of dollars in certification fees (at the time we were barely a million dollar company so this was a significant decision.

Fortunately, this was about the time Kanban came out so I joined forces with David Anderson.  Unfortunately, his Kanban method ignored many of the good lessons we’d learned from XP and Scrum so we had a parting of the ways.  At this point we did a combination of Scrum and Kanban and called it Team-Agility.

I found out about SAFe coming out and had a conversation with Dean about it.  The challenge for me was mostly people were following Scrum and its bottom up scaling approach.  Ken had even said one should always avoid getting teams to work together as that was less efficient.  However, using Lean can create more efficiency and having small teams on big projects may increase efficiency but delay the realization of business value.  SAFe addressed many of the issues that needed addressing.  See Not Doing SAFe? No Problem. Not Doing These?  Big Problem. We became SAFe partners (eventually Gold) because SAFe was exposing issues that had been ignored.  I never endorsed the “all-in-all-the way” approach.  In fact, in our first SAFe implementation at Northwestern (now a case study) I had to insist on our approach of doing it in phases.  We also added many new practices that were not available in SAFe at the time (Kanban at the shared services level, more detail on emergent architectures, …).

SAFe has been an explosive success.  Some people tend to dismiss this as marketing prowess.  But there are three important reasons for this:

  1. People want an answer
  2. Large organizations can often only move forward with a set agreement
  3. The demand for Agile at scale is much greater than the supply of experienced consultants

Hence, SAFe plays an important role in the Agile space – providing large organizations to move forward with less experienced people.  This is a good thing.  However, it’s not our thing.   So, over the last few years we’ve been writing up more and more about our approach.  While FLEX may be new, most of what will be on its website in the next 12 months comes from documents written over the last 8 years.

Finally, one other thing to point out.  Since 2005, Lean has been the basis of my thinking.  FLEX goes well beyond Lean, but Lean provides great insights into how things work in software based business development.  Bottom line, I stick to things when they work.  Move onto news things that I’ve discovered are better.  I regularly challenge Lean-Thinking.  Just a few years ago I admit to thinking it could explain most everything.  Then one my folks (Luniel de Beer) introduced me to Turn the Ship Around (awesome book) and I realized this was a different model for management than Lean profess.  Not inconsistent, but different.  When you find one exception you know there are others.  Perhaps this is why in the past couple of years I've seen so many other things that I hadn't totally appreciated.  Yes, I wish I could have learned these sooner. But I learn at the rate I can and move along as new ways come up.  This is why I said we use Lean-Agile as a backbone and it's not our method. 

It's also why FLEX is being updated dynamically as we learn.  I believe our Lean-Agile methods should reflect our continuous learning. It also means my "hopping" days are over as FLEX will continue to be adjusted as our learning expands.

This was not intended as a vent, btw. I find that looking at the history of things to be valuable.  Hope you found some value.

Al Shalloway

 

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.



        

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