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

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.

I might be the wrong person

I once had a personally troubling experience where I was let go from a team for failure to fit in. The team, as it turns out, did not "gel" properly. It seems it was determined that I was the cause or at least one of the causes of the discord. Rather than speak with me about my behavior, provide me actionable feedback, or offer me an opportunity to alter my behavior, the team lead chose to instead make a recommendation for my dismissal.

When I got the call to let me know that I was to be relieved of my duties pending the completion of the current project, I was blind-sided. Stunned, and trying to remain calm, I asked about my performance of duties. I was assured that I did the job well. That there were no complaints about my ability to do the work or my actual work performance. The issue was that certain members of the team didn't feel like I was a complete team player. Asking for specific examples, I received vague and strange feedback; things about how I behaved at social events, observations on my lack of attentiveness in the team room during times when we were all doing individual work, and favoritism toward a specific team mate such as talking to them more than others or bringing them a tea when I got one for myself. Most of the feedback included phrases like, "...just kinda felt like...." or "...sorta seemed...". Few concrete examples and nothing that warranted termination.

I thought it over, and rather than accept the situation, I appealed to the management committee. I asked for the opportunity to speak to the specific points that warranted my termination, or to at least be provided such points in writing so that I could clearly understand the basis of the recommendation for my termination. No such information was provided. Instead, the management committee overturned the ruling, allowing me to stay in the position.

As the project was coming to an end, a new Team Lead was announced for the next project. This new Team Lead had a professional relationship with the prior Team Lead. Whenever a project begins, there is an opportunity for the Team Lead to adjust team composition, if it is deemed necessary for the success of the project. It is kind of a "fire somebody for free" card.

As you might guess, I was again let go for failure to "gel" with the team. This, according to the new Team Lead, was based on their personal observations of the team and was not influenced by any other factors. This new Team Lead had worked previously with every member of the team except me; I was the only new(ish) member. This Team Lead had not been present at any team meetings, outings, or interactions with the team since I'd joined. In other words, the new Team Lead had no possible personal observations about my interactions with the team. None.

When I asked again for feedback, I was simply told that the team failed to "gel" and "needed a little shaking up". I was again assured that my performance of duties was not the issue. And again, when I asked for the observations that warranted my termination in writing, nothing was provided.

This time, I decided not to fight it.

Clearly, I was the wrong person for this team.

In hopes of avoiding such a situation in the future, I think it important to identify what exactly it is that you're getting if you decide to add me to your team, committee, or board. As this is my only experience of the sort, my examples of how I might be the wrong person are a direct reflection of the behavior and expectations of this specific team. If I have another such experience, I will certainly expand the list.

  • If firing someone comes before providing them feedback in your leadership model, I might be the wrong person for your team.
  • If being buddies is as important as (if not more important than) doing the job well, I might be the wrong person for your team.
  • If getting food for one team member, but not all is grounds for termination without warning, I might be the wrong person for your team.
  • If refusing to allow a team member the opportunity to share their own perspective before firing them (or ever) is part of your management style, I might be the wrong person for your team.
  • If providing mother's rooms "will encourage the wrong kinds of people to be here" is part of your culture, I might be the wrong person for your team.
  • If trivializing Code Of Conducts and victim blaming is acceptable, I might be the wrong person for your team.
  • If "the manager feels personally close to you" is a job requirement, I might be the wrong person for your team.
  • If your hiring process is done by a committee to help avoid bias, but the team lead can overrule the group to bring in a "dear dear friend who just needs to be here", I might be the wrong person for your team.
  • If the nature of one's personal relationships outside of work is used to evaluate work performance, I might be the wrong person for your team.
  • If the team is expected to attend social outings in sexually charged atmospheres, I might be the wrong person for your team.
  • If people who express discomfort with sexually charges atmospheres need to "lighten up", I might be the wrong person for your team.
  • If jokes about a man forcing a woman to commit a sexual act against her will is "harmless adult humor", I might be the wrong person for your team.
  • If the manager motor-boating a member of the wait staff is "just good fun", I might be the wrong person for your team.
  • If receiving late night photo texts of other team members in bed with each other helps your team "gel", I might be the wrong person for your team.

Velocity Anti-Patterns - Attempts to show increased 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

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

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

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

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

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

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 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.

Leadership and Humility

Leadership and Humility

In November of 2015, HBR published an article entitled, "We Like Leaders Who Underrate Themselves". The authors describe an extensive study based on 69,000 managers, 750,000 respondents and hundreds of companies where through an analysis of 360-degree feedback data, they found that leaders who rate themselves poorly compared to how their subordinates rate them are not only seen more favorably by their employees, but actually have more engaged employees.

Bottom line to the article:

"The more people overrated themselves, the higher the probability that they have fatal flaws and the lower the probability they have any strengths. The more people underrate themselves, however, the higher the probability they have strengths and the lower the probability they have fatal flaws."