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.
Thoughts on Refactoring
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.
Delivering Value
A while back, Jason Yip, tweeted about delivery of value and started an interesting thread.
Much of the discussion was about the definition of “value”. Is it specifically about revenue generation or direct customer benefit? Is it more generally about any form of value such as revenue, progress, or learning?
Troubleshooting Velocity
Recently, on a private forum, a member posted a query about their team’s recent drop in Velocity. Concerned about how their boss would respond, this individual wanted to know how to troubleshoot velocity issues.
After spending over an hour crafting a response, I decided I would also add it to my public blogs in case there are others who have similar questions about velocity.
Velocity Anti-Patterns - Attempts to show increased velocity
When leadership asks for an increase in velocity, there are a few common behaviors that occur. Each of them are an attempt to satisfy the potentially unrealistic ask.
It is intriguing to me how often a manager will make a change such as this to a system of work and then later proclaim that the team is gaming the system. This is simply not the case. In fact, the gaming of the system is the improper application of targets or goals for lagging indicators. The rest is just natural consequence.
You can find more on the topic of velocity and metrics for agile teams in my book, "Escape Velocity".
Velocity Anti-Patterns - Enticing More Velocity
Leaders (and teams) attempt to achieve velocity increases in numerous ways. Most, as you can imagine, have unintended side effects on the teams and none significantly improve the actual flow/delivery of value to their customers. Here we explore a few ways teams might be encouraged to increase their velocity. Unfortunately, no matter how well intentioned, using such techniques still has a negative impact.
This content and more on agile metrics is available in the book, "Escape Velocity"
Velocity Anti-Patterns - Demand for higher velocity
Demanding more velocity is far and away, the most common Velocity Anti-Pattern, and quite possibly the most harmful. It manifests itself in a number of differing fashions, but the basics are the same: Somebody determines that the team needs to get more done in less time. So they send out the message - “We are going to need more velocities.” This person is usually an authority figure and typically doesn’t do the actual work being asked of the team. And they clearly don’t know what velocity is. More velocities? Aw C’mon, really?
This content and more on agile metrics is available in the book, "Escape Velocity"
Velocity Anti-Patterns - Introduction
If you’ve been on an agile team that uses velocity as a key metric, you’ve probably experienced or at least witnessed some pretty strange behavior.
I asked a group of agile coaches and practitioners via Twitter and LinkedIn about dysfunctions they’ve seen on teams related to the use of velocity. I received plenty of responses that inspired head shaking and hand wringing. I pulled out the most commonly identified issues related to velocity and metrics and share them here.
You can find more on the topic of velocity and metrics for agile teams in my book, "Escape Velocity".
Announcing the Agile2017 Technical Program Team
I am absolutely honored to have been selected to serve as the Technical Program Chair for Agile2017. I have the further honor of managing the return of the Audacious Salon after its successful inaugural year.My first significant duty as Program Chair was to assemble a Program Team. For each track in my assign, I needed to identify a chair and co-chair to help define the track, recruit a review team, and ultimately select the track content.
Technical Debt and Accountability
I am wrapping up my second in a series for Clean Coders on Technical Debt. In the first episode, I explain the Technical Debt metaphor, how it originated, how it changed over time, and how it now is commonly understood in a way that is the opposite of what it originally meant. I talk a bit about the limitations of metaphors and how debt in particular has not served us well as a metaphor over time. So when a link to an article on the "Limits of the Technical Debt Analogy" hit my inbox this morning, I was quick to follow the link and see what the author had to say.
Unfortunately, this article is not at all about the limitations of the metaphor. The article is about how people other than those who write the software are responsible for the quality of the software. This article is bunk.
Using Collaboration Contracts
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.
Dinner with Family
Dinner together as a family was a key part of how we raised our children and how we kept our family so tightly knit for years. No matter what you had to accomplish in a given day, you did your damnedest not to miss dinner. I often left the office, came home to share a meal, and headed back into the office.
There were no boundaries at the dinner table. There didn't need to be. We talked about everything.