Tap, tap, tap

I attended a seminar with master Rigan Machado where he shared the history behind Brazilian Jiu Jitsu. With every technique he explained the person who introduced it and the event where they dominated opponents all the way to the championship. Unlike other martial arts who have also been around for centuries, BJJ continues to evolve due to active competitors that introduce new techniques and counters.
A few months later I had the pleasure of attending a seminar lead by Ryron Gracie who focused on facing our fear while training. He said "if you are afraid to get tapped when you spar, then you will never get better". He said for most people tapping, or surrendering to your opponent, is a sign of weakness because they are afraid that if others see you tap that you aren't any good at grappling.
As my Shihan Johnny tells us during every class, tapping just means you got caught and you will get caught hundreds of times, its all a learning process
Professor Gracie encouraged us to take risks and intentionally make "mistakes":

"...when you roll allow your opponent you in a triangle and practice escaping. The more you allow yourself to get caught, the more you will understand what it takes to get yourself out of trouble."

He told us that one should experiment a little in those positions; shift ones weight around; grab onto something; move ones hips slightly; and that will eventually one will learn to become comfortable and I guarantee you that you will be the best escape artist. Do not be afraid to tap, nobody really cares! No one will make fun of you or think your are terrible at this!

The trouble with self-organization

A common anti-pattern of  self-organizaing teams is the lack of a "capable" leader. Often people end up in leadership positions and they are not the "right person" for the job. What is worse is that we do not provide them with adequate tools or a support system to help them succeed. In my opinion good leaders are:

• Knowledgeable - How well does this person 'know' your flavor of agile?
• Empowered - Can actually make a difference? Do they have the authority to remove impediments?
• Trustworthy - Does the technical team and the business believe in what this person has to say?

What about your team? Really? Wow you guys have a good team! That is pretty rare because...

Research has found that 97% of people are followers and only 3% are good leaders. If this is true it means that the contact person role is the responsibility of the wrong person 97% of the time. This also proved to be the fact. The self governed teams had become very reactive and ineffective, so now this organization faces this fact and reinstitute the positions of front line leaders. http://www.idcon.com/article-good-to-great.htm

I consider myself a three-percenter, ninety-seven percent of the time. ;)

BDD is not about tools

My team had to integrate with a third party tool whose client library was written in javascript. In order to prevent sprinkling dependency dust all over our code base, we isolated our integration point in a gateway object. After a little research a few members on our team decided that they wanted to test drive the code using Blue-Ridge, which includes ScrewUnit. They felt that this library was very comprehensive and pretty stable. However, when it came time to write some tests, I was really not looking forward to introducing this tool into our codebase.

Screw.Unit is a Behavior-Driven Testing Framework for Javascript. It features nested describes. Its goals are to provide: a DSL for elegant, readable, organized specs; an interactive runner that can execute focused specs and describes; and brief, extensible source-code.

As I understand it, BDD is TDD that is well factored and uses an expressive vocabulary. Dan North started changing the way he thought about writing unit tests so that they were readable and make it easier to teach others unit testing.   

I also thought it [JBehave] would be a valuable teaching tool for introducing TDD and BDD without the distractions of the test-based vocabulary.... Chris and I realized we were trying to define a ubiquitous language for the analysis process itself! http://blog.dannorth.net/introducing-bdd/

In my opinion these tools don't do anything special, they simply attempt to provide a template for developers to write structured unit tests. I personally also find the syntactic sugar, a.k.a DSL, of most of these frameworks to be confusing and inconsistent, which runs contrary to what Dan was trying to do with JBehave:

#xUnit

#-------------------
def test_new_accounts_should_have_an_initial_balance_of_zero
  account = create_new_account
  assert_has_zero_balance account
end

#RSpec
#-------------------describe "A new account" do
  include AccountExampleHelperMethods
  before do
    account = Account.new
  end
  it "should have a balance of $0" do
    helper_method
    @account.balance.should eql(Money.new(0, :dollars))
  end
end 

Is Ruby's Test::Unit::TestCase inferior to RSpec? Was the RSpec test somehow clearer and more expressive than the xUnit version? I claim that these frameworks do not magically lead you to a utopia of ubiquity and expressive code. Writing good, clean, valuable code is a skill.

Templates are good but great code is better...