Why Looking Into Principles Is Important

April 11, 2008 — Posted by Al Shalloway

I have been involved in several threads on more than one user group in trying to differentiate between what I view as Agile practices without the benefit of understanding Lean and what we do at Net Objectives where Lean both creates the context for and provides guidance to our Scrum practices. For some reason, these “conversations” have typically stirred heated debate, sometimes even personal attacks and once culminated in my getting thrown off a popular discussion group.  I thought I’d try to discuss why I talk about what we do the way I do.

To understand this, I need to digress into my approach of learning and teaching.  For many years, I’ve always been interested in why things work, not just how they work.  This is the scientist in me.  Rebecca Wirfs-Brock once described me as a model builder.  I don’t just build models because I find them interesting (which I do). I build models because they help me decide what to do when I am in territory I’ve never been in before.  I heard someone refer to this as “sometimes the best practice is a good theory.”

I learned a great deal about this several years ago when I saw a university professor do some object-oriented teaching at The Boeing Company where I was doing contract consulting/mentoring.  I was amazed that he didn’t have any prepared material or even an agenda.  He merely talked to people about design.  He explored how they thought about things.  He didn’t lead the conversation, but let the understanding and beliefs of his students lead it.  He had confidence that an exploration into what made good design would lead to object-oriented thinking.  I attended several of his classes, watching how he interacted with the students, hoping to learn from this master.

 I remember one day he was talking about the best way to handle drawing an arrow (with a computer). There was discussion about how to maintain state and the difficulties that were caused by having to maintain this by an outside agent for all of the different types of arrows required.  In discussing solutions to this problem, it was suggested that much of the problem was caused by needing to know so much about the arrows and their types and that things could be simplified if they didn’t have to know this.  Just after this, one of the students exclaimed – “but then the arrow would have to know about itself and how to maintain itself!” as if this couldn’t possibly be the answer.  Jaws dropped around the room as one student after another got this key insight in object-orientation – objects are responsible for themselves.

The amazing thing to me was the instructor’s courage to let the conversation go where it may.  I realized that he had confidence that, in fact, object-orientation was a better way to do things than procedural coding.  He trusted this, had faith in it. He trusted that an open, honest conversation about design would come to this conclusion.  He also, I am sure, was fine if it didn’t go the way he thought it would, and, in fact, wouldn’t even mind if it turned out he was wrong – because then he would learn something! J

I remember putting this to the test myself one time in my first Effective Object-Oriented Analysis and Design class (at the time a 3-day course). On the morning of the 3rd day, when I asked if there were any questions, one of the students said – “I don’t think you’ve made a very good case for object-orientation.”  After a silent profanity to myself stating the bad situation I was in, I asked myself a quick question as to whether I should somehow give him a quick answer and move on or actually engage in a discussion with him.  Unfortunately, I saw from the looks of the 25 or so people in the class that they too thought I hadn’t made a very good case for object-orientation (which, by now, being the last day of the class, I should have).  This conversation with myself took about one tenth of a second so it looked like I immediately responded – “why do you say that?”   He and I then proceeded to have an involved conversation about the use of encapsulation, modularity and de-coupling in design.  Usually I don’t let a student take over a class like this but it was a conversation straight to the point of object-orientation and everyone in the class was watching us, like two prize fighters, each stalking the other and making jabs at each other.  Only we weren’t fighting. We were having an inquiry into the principles of programming and trying to figure out what worked.  After forty five minutes of spirited conversation, the student concluded it by saying something like – “Oh, I see, thanks.”

The point of this?  I strongly believe that effective practices can be understood.  It just takes more time and one has to be careful that the understanding is based on reality, not mere theory.  But in understanding the practices, one has to be careful in being able to elucidate them.  To speak about them clearly.  To state what they are and why they work.  Otherwise, the person may understand what is going on, but he won’t be able to transfer that understanding to others. I remember one XP thought leader said something like “XP is your understanding of what you do after you’ve been doing XP effectively.”  A very nice Zen saying, but not likely to help someone who hasn’t been doing XP understand what it is. 

But discussing something is not necessarily the thing itself.  So I have to test my conversations. I therefore use the scientific method.  If the evidence supports my model, then I tend to believe it.  When the model predicts something that doesn’t work in the real world, I have to change the model. When I see a model working in many places, I begin to believe I am onto a principle, not merely a good practice.

Interestingly enough, I’ve been doing this for quite some time in this industry, on discussion groups, getting myself in trouble, at times.  When XP first came out I said I liked it but questioned why it worked.  Not questioning that it did work, just why.  I didn’t like, nor believe the notion that you had to follow all twelve practices to get the full effect of XP.  There was a synergy between them that at first I could only sense, but later I could explain.  When design patterns came out I suggested that the patterns weren’t the important thing but rather the though process behind them was.  Not a new idea, by the way. This is what Christopher Alexander says (the person who inspired much of the software patterns community).  But most people who study patterns forget this (if they ever learned it).  I remember when the acronym TDD started being used I accidentally called it Test-Driven Design.  I was ridiculed on a couple of discussion boards for suggesting your tests affect your design, that TDD was really a kind of design, not merely testing.  Now I would actually disagree with that label because I would go further and say it should really be called Test-Driven Analysis and Design but that’s another story. I also recall disagreeing that design was dead – but rather that we shouldn’t over design.  This opened up the question – how much design should we do? Interestingly enough, I’ve heard many thought leaders recant on the design is dead notion that was rampant a few years ago. More recently, similar things happened with several Scrum thought leaders, which was why I pretty much have left the Scrum Alliance.

Anyway, the point is, I have a great belief in understanding what I am doing.  As an educator who does training, consulting and coaching, I don’t like to ever tell anybody what to do or even make any kind of suggestion unless I understand the principles which affect what they are doing.  I then discuss things from a principle point of view – where the principles create the context for the practices I recommend. This helps both understanding and in assisting people to fill in the gaps where the practices they learn don’t exactly apply in their situation.   I have seen great things happen from this because an understanding of principles can be very profound.  I’ll give three examples.

The very first time I coached a team in Scrum happened somewhat accidentally.  I won’t go into details, but I basically spent 4 days with a small team over a 30 day period to get them started.  One of those days was doing an architectural review (which was what I was brought in for – but that wasn’t their real problem).  Anyway, a few years later, I was talking to someone who knew the technical lead of the team.  He commented about how he was impressed on how well the team did with only 4 weeks of coaching.  I told him that it wasn’t 4 weeks of coaching , it was 4 days of coaching over 4 weeks.  He was even more impressed.  But it shouldn’t have been with me, it should have been with the power that understanding principles gives to competent people (that is, the people whom I coached, who should get the credit). They were able to accomplish what they did because they understood the principles behind the approach I suggested – not merely a few practices.

I recall another time two people came to a 2-day Lean Software Development course of mine and on their own, after the course, made some changes to the organization’s marketing department that improved the productivity of their 100 person software development area by 20% - without touching the software development organization.  How did they do this?  Mostly by applying the principles of looking for systemic causes of problems, optimizing the whole, and going to root cause with the 5 whys while using value stream mapping to guide them.  Why hadn’t they don’t this before?  Because Lean gave them insights to look at their problem a different way.  BTW: This is an example of what I’ve been trying to get the Scrum community to see – sometimes your problem is not with the team but rather with the structure within which the team exists.  Team practices won’t help here.

I also recall a 5 day stint doing a Design Patterns class with some coaching.  Two months after it I was told that every team that had sent someone to the course was now doing Agile.  How did patterns help them do Agile? Because patterns (the Gang of Four patterns anyway) are really about handling variation – either up front or as it comes up.  Hence, I talked about how patterns are an enabler of agility because one can more easily design/develop iteratively.  They understood that building their code in stages with patterns enabled them to understand what they and their customers didn’t know at the start of the project.

I am not claiming to be a miracle worker (although I do believe I am a very good instructor).  I believe the power lies in my ability to get to the principles involved.  I didn’t come up with these principles (actually, maybe one or two).  Most of them I got from people like Martin Fowler, Bob Martin, Christopher Alexander,  Rebecca Wirfs-Brock, Ron Jeffries, Mary and Tom Poppendieck, Jeff McKenna, Ward Cunningham, Jeff Sutherland, Kent Beck, Alistair Cockburn, Jim Coplien (not in any particular order here and apologies to the many I left out).

In any event, I have great confidence and faith in several principles I have seen to be effective.  I believe the Agile community would be well served to discover and respect these principles more than I currently see happening now.  Now, when I say Agile community, there is a problem with that.  What do I mean?  I guess I mean anyone who says they are doing Agile.  I would not consider most people who think they are doing agile as actually doing Agile. But I am a great believer in the power of words.  I believe our reality shows up in our languaging – how we speak and listen to people.

A silly example comes from the movie Underdog (my wife still can’t believe I watched that movie).  There is a great line when Underdog is arguing with his owner – “this from a person who pees in my white porcelain drinking bowl.”  Is it a toilet or a drinking bowl? There is no it.  It’s in how we talk about it.  Many people think they are doing Agile because they have a 15 minute standup meeting daily.  OK, OK, you could say I’m arguing against a straw man – but I don’t think so.  In their minds, they are doing Agile.  They are part of the Agile community.  I think people need to understand why things work – not merely be given a few practices to follow and then think they are doing Agile.  Many Agile thought leaders belief we shouldn’t define what Agile is.  I disagree.

Now, I don’t believe truly good instructors/coaches simply throw a few practices at their clients, but there are many others who do.  There are also many people who pick up a book on Scrum and don’t understand why it works and then misapply the practices. Misapplying practices is easy to do because practices change according to the context they show up in. Yet people are looking for the easy answer and tend to look at practices for them.  There is no universal practice.  There are universal principles.

I like the term Lean-Agile for several reasons – and yes, marketing is one of them.  But let me explain.  I think I’ve already made my point that saying what we do at Net Objectives is Agile would not be clear enough.  We do a particular style of Agile.  We focus on making an enterprise (from multiple-team to department to entire organization) agile.  We want an enterprise to be able to respond to its environment – market conditions, competition, customer needs changing.  We call this Enterprise Agility.  I don’t believe you can do this just with Scrum or Agile thinking alone.  I would suggest people who have done it with Scrum (Jeff Sutherland, for example) pull it off because they also know Lean (Type B Scrum and Type C Scrum are very reminiscent of Lean to me).

So maybe I should just call what we do Lean Software Development.  In many ways, that’s most accurate.  But most people don’t know what Lean Software Development is. This means I can’t reach as many people as I’d like.  I don’t like this. Not just for the selfish, self-centered, marketing reasons I am sometimes accused of, but because many people really need to know Lean principles but don’t realize it.  It will help them achieve their goals more easily.

So I use the term Lean-Agile.  People who understand Lean know it is a marketing term.  Those who understand Agile have a partial understanding of what I mean and know they don’t know all I mean.  Now I have a chance for a conversation.

Cheers,

Alan

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

"Many Agile thought leaders belief we shouldn’t define what Agile is. I disagree."

This made me think...

If it's the mindset that leads to the behaviour, then it's most important to define what we believe over explaining what we do. It's still important to explain what we do, given that it may work in spite of, not because of what we believe. But every failure I've seen has been due to an issue of beliefs and mindset rather than execution of any particular practice.

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