Monday, June 9, 2008

Generic Agile

In this post on Generic Agile, Rachel Davis talks about the idea of mixing up different types of agile methods to arrive at something useful that fits the organization's style and timeframe. Rachel presents some great points and for the most part I agree and it is in fact what I am trying to do myself. 

The interviewer asked what advice and recommendations Rachel would give teams that are looking to change their processes. In response, Rachel said that they should read around many different flavors and not to get too hung up following practices exactly. While I agree that reading around various flavors is a good thing, I can't help but think that during early adoption it would be better to call in a coach who has worked successfully with lightweight processes to help the seed to grow. If a team experiments with different pieces of various processes without first having a working knowledge of them, it might risk pulling apart harmonious practices that are not so effective individually.

In my judgement I am possibly over harsh on the ability of others to pick up on this - but I doubt I would have so easily grasped it myself had I not been fortunate enough to work with a great coach.

3 comments:

Brad Wiederholt said...

With these last 2 points, I'm really beginning to form an apprenticeship theme in my mind. I've recently thought (last 10-15 years) that the "engineering" piece of "software engineering" is a fallacy, stuff changes too fast, noobs and professionals alike too easily follow the latest flavor of the month, and there is not a whole heck of repeatability in the industry. Agile is another example. Like you said, a coach could help. I propose that maybe we should think about rolling the clock back a few centuries and examine the master/apprentice relationship to see what lessons we might learn from it.

Andrew said...

Great point Brad. When I graduated from school a lot of emphasis was placed on apprenticeships. I almost went in for one myself.

There does seem to be a stigma attached to them now which I perceive as more of an ego problem with modern society. No one wants to emerge from years of college study to be merely an underling, yet in many cases, great people in life have served their time learning from great, experienced people. When I started out in computing, I had a good mentor and I like to think that this set the tone for much of what I have done.

While we're on the subject of turning back the clock, I also think that many of the best computing ideas came out of the 70s and 80s and not much has really changed (as far as SW development is concerned) since then. Sure, advances in hardware allow some cool stuff now, but there haven't really been any revolutionary changes to SW development. Just old ideas repackaged and re-marketed to a crowd that doesn't remember them the first time around.

Paul said...

Andrew,

...I doubt I would have so easily grasped it myself had I not been fortunate enough to work with a great coach

Rachel was my coach along with a guy called Ivan Moore. I learned by example, which is one of the reasons why I feel obliged to pass it on.


Brad,

... rolling the clock back a few centuries and examine the master/apprentice relationship to see what lessons we might learn from it.

This is exactly how it works. Any complex, non-deterministic, creative activity requires you to climb the learning curve of knowleged->understanding->skill at the knee of someone who has climbed the same curve before you.

The Japanese seem able to accept this as natural. In the UK (and in the US I think), we have an aversion to admitting that we don't know, and perhaps we need to be shown. We tend to believe that because they are paying us a salary we should know it already.

This culture as another ugly side effect which is that no one can admit making a mistake and not knowing.

Not knowing is natural, and making mistakes is part of learning. In my experience the lack of humility and acceptance of these two key truths is the biggest obstacles to learning. This lack of acceptance also inhibits collective organisational change for the better (Kiazen).

Paul.