Sometimes when I meet with people who want to do Scrum (or anything Agile), they have a hard time looking beyond the past to a new way of making products.  They resist any change to the way things are done because they are often times too wrapped up in their old patterns of behavior.  I understand where this form of resistance originates – these individuals have been so involved with their the organization and its dysfunctions, they have forgotten that things can be different.  They have forgotten that things were different some time ago and their organization used to be “cool”.  What many people do not truly understand is they really do have the power to make their organization “cool” again and that if they really want something to change, it will change.

It is no mistake that the very first line of the Agile Manifesto reads:

Individuals and interactions over process and tools

One of the main themes in Agile is about individuals making a better professional life for themselves.  Apart from our families, our professional life is the second largest use of our time on this planet.  The relationships and interactions we have at work have some of the most far reaching influences over our lives, yet we all act as if we are passive actors in our professional lives.  If we are unhappy about our work life, we own some of responsibility for current state of affairs.  The powerful thing about Agile is we can decide to make the future better.     

In a recent example, I was coaching a group of programmers on how they can use Scrum to develop a new product.  They were very early in the development of their project and we were trying to reach a consensus of  how we will work together in the future.  I was struck by how many of the obstacles they were discussing which were result of “marketing”.  If “marketing” only did this or provided us with that or gave us what we asked for – you get the picture.  It’s not us that have the problems, its them.  While there was some truth to their analysis, but as in any good dysfunctional relationship both sides share equal blame for the situation.  What I found surprising was these programmers had ceded all their power for change to “marketing”.  If you believed them, nothing would change until you got buy-in from “marketing”.  As a result, they were stuck.  

I think I made a breakthrough with these folks because by the end of the workshop, they were very interested in finding measures which helped them see if they were on the right track for change or off in the weeds.  Anytime the participants in a workshop want to stay for a couple more hours to define metrics is sure sign of ownership.

Jim Shore has linked to an excellent discussion on pair programming from the perspective of an experienced programmer being asked to pair full time.  Short summary – everything you thought pair programming was, it is not.  This blog entry is definitely worth a read!

Jeff Patton has a good blog entry on why he is creating user story maps to maintain the Big Vision.  At the last conference in Boston, I attended his tutorial on user story maps.  Organizing the Product Backlog into a backbone of critical features, a walking skeleton of a barely releasable product and a series of releases is definitely the way to go when dealing with a large collection of user stories.  The best thing I like about the map idea is that it is visual.

Alan Shalloway has posted an interesting blog about how Scrum is evolving in its understanding of itself much the same way Extreme Programming (XP) did in the early part of 2000.  As someone who was very much into XP at that time, I agree that XP was first defined as the original twelve practices that you always had to follow and then morphed into XP is what you do after doing all the practices – not a very useful definition for people not familiar with the process steps.

However, the more I think about Agile and Lean, the more I become convinced that its ALL Lean and we do not need to rebrand what we do as “Lean-Agile”.  As I alluded to earlier, I believe that Agile is an instance of parallel evolution of Lean in the software industry.  Either by accident or deliberate thought, the Agile thoughtleaders of the late 1990′s came up with a manifesto for software development that is essentially Lean.  Only later when the Poppendiecks showed up (not sure when) is when many more people began to make the connections to Lean.

So what is Agile?  How is it related to Lean?  Lean is a set of values and principles that are portable across industries.  Unfortunately, many of the Lean practices were developed for manufacturing and if we have learned anything from Scrum it is this: software development is NOT a manufacturing activity, but new product development.  As a result, many of the original Lean practices are not applicable.  Normally, we would be out of luck as practitioners went through trial-and-error to learn what Lean tools worked in software, but we got lucky.  We had an independent instance of Lean appear in our industry about 10-15 years ago and we have gone through a lot of trial-and-error to understand what works and what does not.

IMO, Agile is the toolkit you use when you want to do Lean software development.  Many of the tools are mature, but there are also many gaps.  One that comes to mind is the weak state of product design in the Agile community.  Agile’s default position on product design is you iterate on your code until you get something the market wants – I think that might work if you have small products and\or only serving a single market segment.  For big organizations, multiyear projects that approach could be exceeding naive.  There are Lean tools out there that have gone through the trial-and-error process, so why not use them?

I watched this film the other night after it had been sitting around on my coffee table for at least a week (I am so swamped right now).  M. Night Shyamalan definitely understands how to tell a suspenseful story – put broken people in a bewildering, disorienting situation and then slowly crank up the tension and raise the stakes.  As a horror or suspense film, it worked OK.  There also were some beautiful shots – I distinctly remember a scene with Zooey Deschanel’s dress blowing in the wind against a backdrop of the green fields.

It is always a little sad when the actors you grew up with, or were considered to be heartthrobs,  start to hit middle age.  Both John Leguiziamo and Mark Wahlberg were playing roles that showed they are starting to hit the middle of their careers – they were both fathers and teachers.

Seems like Martin Fowler is adding more to the Scrum dogpile.  I have written about this concept here and here.  Again, I agree that it is up to us practitioners to make sure the technical practices are applied rigorously or you get a big Scrum mess.