Agile going mainstream

Let’s try to map the technology adoption lifecycle bell curve along a timeline for Agile methodologies:

• 1995-2000 - Innovators for a coherent set of values, principles and practices,
• 2001-2005 - Early adopters, spreading the word and crossing the chasm,
• 2006 up to now - Early Majority.

As Martin Fowler suggests in his recent post on Scrum, from now on, the highest risk of decay for the movement stems from the lack of understanding of the huge mass of new adopters. They tend to focus exclusively on the practices, while forgetting about what truly matters and represents a competitive advantage, namely values and principles.

The worldwide proliferation of Agile Conferences for the 10 last years constitute a sure sign that the approach has become more accessible. I highly encourage those who want to gain an accurate insight of what it is all about, to attend to one (or more) of them.

Here is, in chronological order, a list of Agile conferences I know about for this year (2009):

• XP Day Swiss (Geneva, March 30, french) - If you speak french, please welcome the first edition of this event in Swiss ; I know a few organizers of this one and believe they will make it a great, practical and useful experience for the participants!
  
• XPDay France (Paris, May 25 and 26, french) - every year since its first occurence 3 years ago, I have dutifully attended to the Paris conference ; the french community is more active than ever, and I am very happy to meet new talents from my country. In addition, the place where it will take place is truly gorgious ; once again, I just can’t miss this event!
  
• XP2009 (Sardinia Italy, May 26-30) - The tenth International Conference on Agile Processes and eXtreme Programming in Software Engineering
  
• Agile 2009 (Chicago USA, August 24 to 28) - This event gathers the international VIPs and some founders of the Agile movement. The far geographical distance makes it a bit expensive for us europeans, but I am considering maybe giving it a shot this year.
  
• XPDay Benelux (likely November)
  
• XPDay London - (likely December)
  

I address this post to Agile newbies that want to succeed in their projects: “Please, pay a visit to one (or two) of these conferences, to get in touch with more experienced folk, and try to understand what the essence of Agile is truly about”.

Work Smarter, not Harder

Isn't it a nice tagline?

Both Agile methodologies and Lean push in that same direction : use the combined brainpower of the team to build and maintain the most efficient system in terms of value to the customer and return on investment.

In our daily work, we try as a team to work that way... and the more we try, the more we feel strong and confident (but also the more we measure how incredibly far we stand from true efficiency!).

Around us, a basic “routine” organisation (pattern 1 in the set of cultural patterns of software organisations, as described by Gerald Weinberg in his first volume of the QSM series) interact with us. Most project managers seem to value this single equation:

     "people count * average individual productivity = added-value per day"

They hardly allow a hint of self-criticism to reflect on their habits. From time to time, they buy expensive tools, ask for a quality audit, or add people to the workforce, confident that it will bring the great leap forward they need in their ability to deliver fast and with high quality.

Everybody knows (or should know) there are tons of insightful litterature about the pitfalls of that approach (the oldest I know being “The Mythical Man-Month” from Fred Brooks), so I don’t feel like repeating these brillant analysis.

In this starting year, I’d rather like here to list what I believe, from my experience so far, to be fundamental rules for a “small” team for succeeding in any complex software project, independently of the adopted methodology:

1. Reduce the number of “simultaneous threads of activity” for a same person: our conscious brain is mono-threaded, and the cost of switching between contexts is daunting,
2. Allow some slack time for your team, priceless for the long run success (promotes innovation and a spirit of continuous improvement). Encourage individual studies and organize team workshops on various aspects (product vision, software design, work environment, organisation...),
3. Prefer developping the competence of your team before hiring external resources; then consider the latter action to help achieving the former,
4. Stop the dumb rat race for features - numerous studies have clearly demonstrated that most softwares are overloaded with features, that are seldom, if ever, used and a pain to maintain: rather, slow down a bit and choose judiciously the new functionalities by focusing on their alignment with a coherent product vision,
5. No mercy for defects: pause the current activity as soon as a defect has been detected. Fix it immediately if it should take less than a few minutes, or plan for a better (still near) time otherwise, but never forget to hold on the task flow, to analyse and look for the root cause of the occurence of this defect,
   

I may certainly have forgotten other important points, but I believe the respect of these define a necessary backbone of good habits for a software team.

To end this post, I will quote Robert Martin, describing what I believe to be the core discipline of all members of a “smart working” team:

“[The professional craftsman] adopts an attitude of calm, focuses on the problem to be solved, and then step by step solves that problem without rushing, without yielding to the need for speed, without surrendering to the desire for a quick conquest”.