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.

I’ve read Domain-Driven Design (DDD) a couple of times now and consider it the most influential book on the way I develop software. But I’ve yet to blog about it. It’s time to change that.

Firstly, serious developers and analysts simply must read this book. It’s the sort of book I’d demand be read if I owned a software organization, though (being generous) around half of the book is applicable to Analysts.

Before I read DDD the concept of a Domain Model was somewhat fuzzy, even after reading Patterns of Enterprise Application Architecture. So often I’d seen ‘Domain Models’ purely holding state. I’d joined teams late in the game that had developed ‘intelligent’ Domain Models, but how they got there was a mystery. Questions like:

• Why had this domain concept become a class?
• Why apply this pattern in the domain layer?
• What direction are we headed with the domain model?

…the answers were never clear to me. Often one technician on the team had the answer, but I didn’t feel empowered with the knowledge to act without their consultation.

DDD hits home the importance of Domain Models and presents infinitely more information than development guidelines like ‘objects should have both state and behavior related to that state’. My most significant learning from it is an approach for distilling real world concepts into software, concepts that linger in the mind of domain experts but never crossed the divide. I won’t go into detail here, but the book presents the essence of distilling those concepts - unifying the language used across roles and, more generally, throughout the team.

It’s now a rare day when a team member’s ear won’t be ringing to the sound of me stressing the importance of modeling objects on domain principles, rather than abstract, somewhat related or technical ones. Analysts directly contribute to assembling simplified object models and are on the receiving end of questions like ‘does this concept have a name?’, ‘is there a general concept that encapsulates these things?’, ‘can we break this thing down, what do you think it’s composed of?’, ‘how would you identify each of these?’.

From a requirements perspective, it’s shifted my focus from understanding the requirements and acceptance criteria in isolation to understanding the core domain; the business of the users. According to the Kano Quality Model, customers are delighted when they discover new and useful features, stuff they wouldn’t expect to see. Immersion in the domain is key to having this capability.

From a development perspective, it’s given me techniques to aid modeling the domain in software. They focus on keeping the software simple and reducing translation time between the software and the domain. Again, I won’t spell out in detail what’s best covered by the book, but it is the kind of stuff you can start practicing immediately, the majority of it transcends languages and is bound to be relevant for many years.

The book also offers solid advice to leaders on effective team structures and subdividing teams and domains. This ground is probably less explored than other parts of the book but it’s no less important. From my experience it is used less, quite simply, because changes of that magnitude requires organizational clout that is difficult for a team to ascertain.

Here’s a brief list of observations from my DDD experiences:

• I find myself spending more time thinking, less time doing while at the same time being more productive
• I’m more proactive in engaging analysts. Emotionally there’s less of a divide between developers and analysts
• The code is more consistent and easier to navigate. You are less likely to be able identify the code of an individual
• You fear changes to the code less
• You strive to the understand the business’ problems more and focus less on simply producing software
• Design discussions are welcomed and flow naturally, there’s often less friction
• Breakthroughs, refactorings that significantly simply the implementation, come earlier rather than later

Credit where credit’s due; this book is quite simply an excellent geek read. For more info see Domain-Driven Design.