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”.