This article focuses on using Chain of Command as a means of reducing cyclomatic complexity in our code. Along the way, we also create better adherence to SRP.

I recently worked with a team on a fairly significant refactoring. I paired with different team members each day over a three day period as we moved code around, pushing responsibility into other classes, reducing complexity, and make the code more expressive. On the fourth day, I put together some notes on the things we saw and general guidelines for the team to keep in mind. Nothing herein is new to the community, but it might be new to you.

Collaboration Contracts are a way of identifying who is involved in a decision and what level of decision-making authority each participant has. This isn't a delegation model where some individual is empowered and imparts unto others some fraction of their authority for a limited period of time. This is a collaboration model where all participants are equally empowered, but find consensus on all topics to be a suboptimal approach.

I often find myself talking to people who are in the midst of a switch to agile and who find the change very difficult to get used to. They may be strong advocates, but their team just "doesn't get it". Through discussion, I find that many of them are attempting what I refer to as "Shock and Awe" agile. If you couldn't tell by the name, I consider this another agile coaching anti-pattern.

Some time in mid-January, I was thinking about various organizational patterns and how companies run. I was thinking, in particular, about the idea of a "leadership team". I tweeted that leadership teams may be an indication of dysfunction.

I got a few different responses, all of which amounted to "please say more about this."

I think I saw Daniel Pink's TED Talk on "The Puzzle of Motivation" for the first time in 2011. I'd been reading some about leadership, management, and organizational psychology up to that point, but Pink's talk and his distillation of these complex concepts into a simple framework (Autonomy, Connection, and Excellence) inspired me to read more on the topics. Over the course of the next couple of years, I consumed a decent amount of material. You can view my Goodreads account to see what books I was reading. Unfortunately, there is no easy way to share all of the scientific articles and other sources I also consumed.

I've worked for essentially two types of companies - those that have clearly defined job ladders and those that don't.

A clearly defined job ladder provides people a clear picture of what they need to accomplish and what skills they need to display in order to move into a new role. A clearly defined job ladder provides a baseline for performance appraisals. Everyone in the organization knows what is expected of people in each role. Are you displaying these attributes with a level of proficiency requisite for the role, or are you not? Job ladders make the expectations of progress and the opportunity for advancement clear and consistent.

I like to practice my craft. I enjoy participating in Code Retreats. I enjoy facilitating Code Retreats. I like working on kata and koans. And a lot of what I talk about includes references to these practices. We at LeanDog are always on the lookout for people who are passionate about improving their own craft. I thought I'd start a blog entry where I catalog resources that might be of interest to others looking for ways to sharpen their saw.