Best practices are not the best at all!

I sometimes get tired of listening to people talk about best-practices, and today is one of those days!

Deming a long time ago started pitching the idea of continuous improvement, back when the Japanese were the only ones willing to listen to him. In his now famous "plan-do-study-act" cycle (PDSA) he popularized the feedback and learn-by-reflection tools. In this cycle he introduces the importance of implementing your plan (not becoming afflicted with analysis paralysis) and then studying it to see what needs to be improved. This is the core of improvement: implement something, and learn from failures (missed schedules, missed sales, etc.) and successes!

Best practice as a concept is an oxymoron with the PDSA cycle and the continuous improvement concept. Best practices assume you know exactly what applies to all or a large class of situations that may have nothing else in common except the environment! A good example of this Best practice disease syndrome is when you are making decisions based on what others have done and learned but not implementing it based what your environment is and what you can learn from it.

By all means read about best practices, but use your brain and adapt the practices to your environment/restrictions. Best practices are only the best for those that applied them first, for you they should be just suggested practices.

Once you have applied the suggested practices, study their effects and learn from them. If you don't improve, you will be left behind. Look what happened to Toyota's non-Japanese competitors...

OK, I confess there's one best practice I use constantly, but that's called "Learning"! :)

Another interesting Agile Finland Seminar

Yesterday another Agile Finland seminar was held in Helsinki. There were 3 speakers and the guest star of the day was Tom Gilb.

Tom has been working in this field for many years and pitches himself as a precursor of the agile movement. He mentions "iterations" as something that he popularized in one of his books.

Tom stated that current agile methods lack quantification and that's why his own proposed XE (as in eXtreme Engineering) is better. In his method he adds a few things on top of a normal iterative process like scrum (weekly iterations, weekly one-page, status reports) but most importantly he adds the requirement for "quantitative" requirements. He basically said: "if you cannot quantify your requirements you cannot know if you are achieving them". He pitched quantification as the key aspect of the XE method.

In the Agile community we have not discussed quantification and scientific analysis very much, in my opinion this is something that will become more and more important in the near feature.

Macs taking over the world?

It was also nice to notice that a lot more Macs were visible in the auditorium, previously we had seen only PC laptops but now I only saw Macs everywhere (with one exception), could this mean that Macs are becoming the tool of choice for IT professionals? Certainly there are more and more reasons to do it. With most of the tools we use daily moving to the web or a hosted version you become tied only to your browser, not your OS. As a side note it is also worth to note that of the 3 presenters 2 had Macs!

All in all a very nice seminar that was followed by a lively discussion in a close by restaurant that was certainly happy to get the extra business from the agile crowd! :)

A Seminar about Agile implications for old-school project managers

On November 14th, 2006 I'll be speaking at a seminar about the implications of Agile on the lives of old-school project managers.

The old-school project management is still probably the widest used approach to software project management and I tried to explain it's core values here and here.

My talk in the seminar will focus on how the old-school project managers can improve their work and their results by following a new set of values instead of the "old" values in the old-school methodologies.

If you want to know more you only have to register and show up! :)

See you there.

Is the military getting "software development" ?

James Bach is a well known test specialist that has espoused Agile software development since the beginning. Even though the testing community is still searching for consensus (which may not even be a good thing) James is definitely quite ahead of the pack.

His latest post on testing in the military is very "to the point". Check it out.

It's not that they love process, it's that they love bad process. Documentation? Bad documentation. Who can look upon 2167A or Mil-Std-499 without dismay? I'll tell you who: paper mills and people paid to arrange the ink on all that paper. It's just a scam and a travesty.

James Bach's Blog » Could the Military Be Waking Up?

Reducing waste

Tim Ottinger has a very good observation on his site about the importance of reducing waste and the difficulty of achieving it through Agile in organizations that are just starting. 'Nuff said.

Agile software development is all about eliminating collateral effort. No unnecessary documents, no unnecessary meetings, no unnecessary code, no unnecessary anythings. The mantra is "maximize the amount of work not done." You eliminate as much as you can (and no more).

Tim Ottinger: Collateral Effort