I have been espousing an understanding of principles for quite some time now. While I do believe that one typically does not truly understand something until they do it, I believe we often look in the wrong area for things and that being told what to look at (in the form of principles or rationale) can steer us into better action quickly.  I recently had an experience of not being told principles, eventually learning things myself, and realized I would have learned a lot faster had I been told them - so I thought this might be a good illustration of my point.

Recently at the Rails conference, Bob Martin served up a very provocative talk: "What killed Smalltalk could also kill Ruby." There has been a fair amount of controversy about this particular presentation, most notably from the Smalltalk community who consider themselves to be not-at-all-dead. They point out, for instance, that Smalltalk was not free "back in the day" and Ruby/Rails is, and that this makes more of a difference than many of the factors Bob was referring to.

For my part, I don't care all that much whether one language or another is in vogue as much as I care how the technology is being used and specifically how our profession is or is not maturing as a result. Bob said that we were not a profession in the past but are now. I tend to agree with him. He also equated the notion of a profession with the concept of disciplines which I also totally agree with (this should not be too terribly surprising to anyone familiar with the book I wrote recently - Emergent Design: The Evolutionary Nature of Professional Software Development - and if you note the particular engineering practices we choose to teach at Net Objectives).

So I'm with him on this, but I think there were a couple of things missing in his equation.

I have heard it said many times that patterns have to be discovered. Years ago, after reading Christopher Alexander's "Timeless Way of Building" I felt that this wasn't really true - since patterns are not really just "solutions to recurring problems in a context" but rather an exposition of the forces present in the context including the relationships between these forces.

Last year I was diagnosed with a "nodule" on the right side of my thyroid (this is the word they use when you have a tumor and they don't want to freak you out). My doctor told me that the nature of the thing (soft, large) meant that it was unlikely to be cancerous, but that we might want to remove it anyway because it might turn cancerous later.

I asked "would I have to stay overnight in the hospital, or could this be done on an outpatient basis?"

He nodded and said "well, it's superficial, so…"

I interrupted. "Ah, good, so it's no big deal."

He looked puzzled. "Um, no. What?"

"You said it was superficial, so that means it's no big deal, it's trivial."

"No," he said, "it is not trivial, it is superficial."

This blog is based entirely on a recent post I made on the Kanban Dev group. I have slightly extended it here for clarity.

I get a lot of comments from Agilists who have not done Lean or Kanban suggesting that there is little difference between all of these things (XP, Scrum, Lean, Kanban).  They tend to think the differences are just a few practices which you could do anywhere.  I do not agree - for reasons which this blog will elaborate.

I have been telling a message that people who do Scrum can be more effective supplementing Scrum with Lean-Thinking.  I do not think this is any more being negative than someone telling a newbie driver a regular car does better on the road, or you need an SUV if you want to drive off the road.  As a  person with a mathematical and scientific background, I believe it always makes sense to understand the context within which whatever you do works.  read more »

 Redefining Lean

Virtually 2 years ago I wrote a blog called Challenging Why (not if) Scrum Works.  Basically, I was looking to see why Scrum worked so I would be able to best take advantage of Scrum. I believe Scrum works very much due to the structure of the team, the iterative nature of development and the proper context within which the team works.  In this prior blog, I reported my experience with teams that were co-located, had all team members work together and worked on only one project compared with those who  read more »

I just attended the Lean Kanban Conference in Miami.  I have been going to conferences for 12 years.  My mainstays of the last few years have been regional open conferences, SD West, SD Best, Agile Alliance, SQE’s Better Software, SQE’s Agile Development Practices and APLN regional conferences.  I’ve had to redefine my 1-10 scale.  What was formerly a 10 has to be moved down to 7 to make room for the new 10 this conference was.  Truly amazing. 

 Report from Lean Kanban 2009

Kanban is an emerging practice in Lean software development. Founded on solid principles of flow and utilization theory, it seems to address many of the issues people have had with Agile approaches. Over the next few years, Lean Kanban is going to become an important part of the software professional's toolkit.

The Lean Kanban Conference 2009, May 6-9, 2009 in Miame, brought together practitioners and thought leaders to discuss how to help the community go forward. This podcast is a report by Alan Shalloway about what he, Guy Beaver, and Alan Chedalawada (all from Net Objectives) learned from this special event.

Over the next few weeks, Alan will be posting some blogs about what he learned at the conference. See blogs.netobjectives.com. It will be the topic of several upcoming podcasts on Lean-Agile Straight Talk. 

You can learn more about this conference at www.leankanbanconference.com/

And make your plans now to attend the UK Lean Kanban conference in September. For information, see www.ukleanconference.com

 read more »