The unknown variable, Che Guevara theories applied to agile teams

In Che: Part One, Ernesto Che Guevara states:

In War and Peace Tolstoy remarks that military science assumes that bigger armies with more men wield greater force.
On the other hand, only vaguely, do they recognize that during military combat the final strength of an army is also its true physical capacity multiplied by one unknown variable.
One unknown variable. This variable is none other that the spirit of the troops measured as their greater or lesser desire to fight and confront danger.
Men with the desire to fight who also understand why they are fighting regardless of who they are fighting whether under military geniuses or those of normal intelligence fighting with clubs or machine guns that fire 30 rounds a minute these men will put themselves in the best positions and so they will win.

Immediately after hearing this I’ve started a comparison with agile projects.

It’s obvious in these days, with agile becoming mainstream that bigger armies (expensive tools? costly hardware? costly solutions?) and bigger teams don’t imply success in software development.

What is then the unknown variable in an agile team?
I would compare the physical capacity with the knowledge base of the team, with the general collective intellect.
The desire of fighting is nothing else than desire of success and play with risks and issues in a project.
But then, it’s in the understanding of the why they are fighting the most interesting part.

I’ve seen teams over-performing in few different situations: some were strongly committed to the success of a startup, feeling part of it (my experience at Fluidtime), some other were committed to reach excellence (a common behavior at ThoughtWorks).

The why can be different from team member to team member, some people need to feel that they are part of a whole, some others need recognition and differentiation.
Some others are carrier driven, some others have a strong desire to learn, improve.

Finding the right motivation in your team members will make your team run faster and smoothy, the unknown variable will boost your speed and quality.

Posted in General Stuff | Tagged , , | 2 Comments

AOP, NUnit and Selenium: clever screenshots of failures

Last week I did struggle finding out why a test was failing only on our Cruise box, only in the Cruise build.

I wanted to get a screenshot of each failing tests, and I think I found a clever solution: aop.

We already use PostSharp on our code base for logging, transaction demarcation and hibernate session support, so I wrote a simple annotation for our acceptance tests:

  1. using System;
  2. using PostSharp.Laos;
  3.  
  4. namespace Web.UI.AcceptanceTests
  5. {
  6.  [Serializable]
  7.  public class ScreenCaptureAttribute : OnExceptionAspect
  8.  {
  9.   public override void OnException(MethodExecutionEventArgs eventArgs)
  10.   {
  11.    SeleniumManager.Selenium.CaptureScreenshot(string.Format("C:\\{0}.jpg", eventArgs.Method.Name));
  12.   }
  13.  }
  14. }

Every time a test will throw an Exception Selenium will take a screenshot of the screen: pretty simple.

The only caveat is that it won’t work if Cruise is running as a service, and to get a decent result you’ll probably need to maximize the web browser windows.

Posted in General Stuff | Tagged , , , , , , | Leave a comment

Suffering of Selenese Flu? Try webdriver

I’ve been suffering of selenese flu for months, being on a .net project we were using selenium RC. The typical symptoms are flaky, slow tests and sometimes a lot of sleeps in your code to make it work.

Selenium has its age and it struggles to cope with the current web 2.0 asynchronous calls & rich javascript.

Fortunately old good Simon is working hard at Google on webdriver, and in December the official port has been released also for the .net platform.

It works alright, there are some classes missing and you have to put the IE dll on your project as a content so that it gets copied on the bin folder to make it work.

A part from that, it’s faster, more reliable, more fun to write.

It’s time to cure your flu, webdriver is your medication.

Posted in General Stuff | Tagged , , , , , | Leave a comment

5S and Software Development

Phase 1 – Seiri, Sorting: Going through all the tools, materials, etc., in the plant and work area and keeping only essential items. Everything else is stored or discarded.

  • Remove unused code
  • Uninstall useless software
  • Remove unused libraries

Phase 2 – Seiton, Straighten or Set in Order: the intent is to arrange the tools, equipment and parts in a manner that promotes work flow.

  • Build Scripts
  • Shortcuts
  • Symbolic Links to reach dev paths
  • Labelling of builds / deploy to QA

Phase 3 – Seiso, Sweeping or Shining or Cleanliness: Systematic Cleaning or the need to keep the workplace clean as well as neat.

  • Keep desk clean
  • Keep the OS desktop clean
  • Sort out emails

Phase 4 – Seiketsu, Standardizing: Standardized work practices or operating in a consistent and standardized fashion.

  • Patterns
  • Communication, common language

Phase 5 – Shitsuke, Sustaining the discipline: Refers to maintaining and reviewing standards. Once the previous 4S’s have been established, they become the new way to operate. Maintain the focus on this new way of operating, and do not allow a gradual decline back to the old ways of operating.

5S definitions are taken from wikipedia

Posted in General Stuff | Tagged , , | 1 Comment