Agile

Velocity Anti-Pattern - Demand for Higher Velocity

Velocity Anti-Pattern - 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 the book, "Escape Velocity".

 

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.

A Lightweight Incident Response Framework

A Lightweight Incident Response Framework

Sometimes, there is an edge case we didn’t anticipate that causes issues in production.

And sometimes, there is a common use case we didn’t test sufficiently cover that causes issues in production.

And sometimes, production goes down. For reasons yet unknown.

For some of us, there is a production support team that handles these things. They might call us, if they need us, but they handle this stuff. For the rest of us, we need to handle the incident ourselves.

The following is a very simple framework for responding to incidents.

Tuckman Was Wrong!

Tuckman's Theory of Group Development was first published by Bruce Tuckman in 1965. In Tuckman's original explanation, groups and teams go through four stages as they become a cohesive, high-performing unit; Forming, Storming, Norming, and Performing.

While a commonly accepted model of how teams form, science tells us that Tuckman's Theory is wrong. The stages he defines are not really stages at all, do not happen in a specific sequence, and are not all experienced by all teams. Our top argument for why teams need to be kept stable has been invalidated.