Proposition

Rotate leadership roles in agile teams often.

Background

I’ve been a proponent of flat organisational structures since my time at Thoughtworks.  It’s especially great at promoting communication between all staff.

It empowers.  It’s great for morale.  It promotes healthy debate and ideas creation.

In this model the importance of organisational hierarchy is overshadowed by the tiers of employee experience.  The senior are most vocal.  The craftsmen lead the journeymen who lead the apprentice.

Leadership roles are typically filled by those from the most senior tiers.  The choice of leader is usually subjective and different candidates offer different pro’s and con’s.  Something can be said for rotating a number of senior staff through these roles.

What I’m proposing here is the same theory applied to agile teams.

Benefits

• Leadership is considered as ‘just another role’: does away with the notion that leadership implies promotion, which stimulates an undercurrent of inferiority and superiority.
• Equality prevails: Equally recognises the skills of senior members.
• Fresh perspective: Different perspectives of problems and solutions are offered.
• Encourages individual growth: leadership roles are a great way to grow confidence, whereas stepping out of leadership roles is grounding and brings different knowledge to the coal-face.

Reconsider when…

• Individual accountability is important: It works best where blame culture does not prevail and teams and individuals learn in a non-threatening environment.
• Seniority is the minority: Apprentices may be better served with a fixed figurehead.
• Teams with staff churn: Better leaders are those already having experience working within the team.

My team has been recently tweaking our daily ceremonies.

Once upon a time we had a combination of standup and huddle.  Standup being the usual brief on yesterday and todays focus and blockers.  Huddle being the team gathering around the story wall and discussing progress and issues in depth.

We eventually acknowledged the overlap between the two and ditched the standup in favour of focusing on stories and their flow through to completion.  Participants stood - keeping it brief was the focus.  The team lead facilitated the session and organized the team to smooth the flow of stories and ensure important information is shared.  Consequently the team lead was very much the focus of the meeting.  Within minutes of completion other participants would often be unable to recall the contributions of others, as their attention was on summizing information on their story.

The main intention of the meeting, however, is not to provide information to the lead.

It’s to share information among the entire team.

So we trialed running huddles in a presentation format.  The entire team is seated around the story wall.  Pairs/dev present their stories to the team in turn, divulging:

• Progress over the last day
• Tasks on the horizon
• Design highlights
• Business decisions
• Confirming the estimate

The exact manner that information is delivered is entirely at the discretion of the individuals.  Anything that captures the audiences attention is encouraged.  Humor is encouraged.  The atmosphere is relaxed.  There are no time limits.

Presentations are both informative and entertaining.

The difference has been dramatic.

In a manifesto sense, here’s what I’m thinking:

• Quality of information over brevity

• Attention seeking over ritual

I strongly recommend experimenting with it should any of the symptoms we suffered from sound familiar.

What is Behavior Driven Development (BDD)?

According to behaviour-driven.org BDD was born from NLP experiments (astonishingly, nlp.com mention NLP and hypnosis in the one sentence!).
It is a combination of TDD and DDD. Here are some of my attempts at describing BDD:

A process for describing the behavior of a system that is understood by both technologists and non-technologists.

DDD applied to the domain of TDD.

The concept of a ‘vocabulary for describing behavior’ is at its core, but interestingly the behavior-driven site falls short of defining the vocabulary (note the incomplete links at the base of this page).
BDD is strongly linked to TDD as tests are often used to describe the features, or behaviors, of a system. Consequently, part of BDD involves writing tests using the vocabulary.

Enter RSpec

That’s the driving principle behind RSpec. Test::Unit is perfectly fine for defining tests, but it doesn’t employ a BDD vocabulary.
RSpec does, and it throws in a side order of Mock and Stub support often needed for TDD. As it happens this support is virtually identical to that provided by Mocha.
Take your pick, the support both provide is particularly cool as you can Mock and Stub methods of any object, sure you can create Mock and Stub objects (in a fashion that I’ve been used to with EasyMock and JMock) but the object doesn’t have to be a Mock or Stub in order to Mock or Stub a method invocation.
To highlight this here’s an RSpec demonstration applied to a banking model;

  describe Account do

    before(:all) do
     @@amount = 100
    end    

    before(:each) do
      @account = Account.new
    end

    it 'should withdraw cash via a Transaction' do
      Transaction.should_receive(:deduct).with(@account, @@amount)

      @account.withdraw @@amount
    end

    it 'should log unsuccessful operation when withdraw is unsuccessful' do
      Transaction.should_receive(:deduct).with(@account, @@amount).and_raise(InsufficientFundsException)

      @account.should_receive(:log_outcome).with(:unsuccessful)      

      @account.withdraw(@@amount).should_raise(InsufficientFundsException)
    end

  end

Pretty cool huh?! This mocks two methods in a manner that can’t be easily repeated with Java:

• A class method, Transaction.deduct
• An instance method of a real object, @account.log_outcome

Take a look at the recently tweaked documentation on the RSpec site for info on it’s other features (like partial argument matches), and more generally its implementation of a BDD vocabulary.

Why use RSpec?

One of my initial encounters with RSpec was via a blog critising BDD that goes so far as to suggest RSpec is pronounced ‘arse peck’, so I’ve been skeptical from early on. I have been particularly cosy with XUnit tests, a mock framework and consistent test method naming conventions as a way of specifying behaviors, so I didn’t feel the urge to change. Test::Unit and Mocha can pretty much yield the same result - what did I have to gain?

Still, this ol’ school approach requires some discipline and custromizations to read like a BDD vocabulary. RSpec, on the other hand, encourages codification of tests in a consistent BDD vocabulary. But hey, if you don’t intend on using the vocabulary for communications between roles (and that’s a substantial change) your missing the major benefits of BDD - so why bother?

Nonetheless, it’s worthy of consideration.

With its subtle shift in the XUnit language I believe it produces more readable tests. That coupled with its nice mock and stub support and the potential benefits of a shared language for describing behavior - the pro’s start outweighing the con’s.

Parting Thoughts

I’ve read some BDD proponents claim they sought out BDD as a solution to tests that are tightly coupled to source, hindering refactoring and causing a maintenance burden.
I fail to see how BDD helps here; this is a natural consequence of writing unit tests. For tests to do their thing, an API under test must be invoked - you can’t avoid that. If you change that API; surprise, you’ve got to change your unit tests! If you’re suffering this affliction maybe you should test against an API few layers up, like HTTP. Personally though I’d be blind without my unit tests, at a minimum they aid design and verify correctness.