When we talk about making the work visible, there are two key aspects - what is the work and how is the work progressing. In this article, we are going to focus on how the work is progressing. Specifically, we are going to look at Cumulative Flow Diagrams as a means of visualizing work progress.

I’ve recently started working with some teams who have elected to use the classic three questions during their stand-ups - “What did you do yesterday?”, “What will you do today?”, and “Are there any impediments in your way?”

I’ve been talking about and advocating for different stand-up formats for quite some time. I, frankly, think the three questions are too focused on individual activity and lack focus on group progress.

If you like the format of three questions, may I suggest you try some different questions?

How might the Dreyfus Model of Skills Acquisition apply to pair programming? Is it better to pair a novice and proficient or a novice and expert? Does novice to novice pairing make any sense at all? Doc explores these and other questions.

So there we were, at an agile conference. Well, not at the conference exactly. But at a bar very near to an agile conference.

A few patrons were talking agile stuff - like they do. And someone, as evidence in support of their stance that all metrics are evil, used the “But the Scrum Guide”, defense.

“But the Scrum Guide doesn’t prescribe any metrics. As a matter of fact, the word metric is not in the Scrum Guide. Not once.”

I found this claim dubious, so I checked it out.

Why even have a stand-up meeting?

From my perspective, the daily stand-up is an alignment meeting. The desired outcomes are:

• Shared high-level understanding of the overall plan/progress

• Shared understanding of the near term work

• Alignment on how we can best collaborate right now

Having too much Work in Process, also known as Work in Progress (WIP), is a remarkably common issue. In my experience, management often encourages this behavior. I don’t know if it is the notion that we will get more done if we work on more things simultaneously. Or perhaps there is a fear we won’t get enough things done unless we work on several of them at once.

This blog post is inspired by another Quora question; “What metrics do you use to track Agile Efficiency?”

To begin with, I want to state that if I had to choose between efficient and effective, I’d choose effective. Efficiency is often about output (how many widgets per hour), whereas Effectiveness is often about outcome (was the purpose consistently met).

Agility is about responding to change. Efficiency is achieved by driving out variation. An over-focus on efficiency will lead down a path of standardization and control, making for a less agile system.

That said, given the question was specifically about agile efficiency, I’d look at a few things - Throughput, Cycle Time, Deployment Frequency, and Mean Time to Recovery.

I stumbled upon a thread recently where the question was posed, “What are some common mistakes when refactoring code?”

The answers were interesting. The more I read, the more I realized that folks weren’t talking about the same thing. They were all saying “refactor”, but many were describing scenarios that sounded more like a rewrite rather than a refactor. This is not uncommon. I’ve encountered this on multiple forums, in slack discussions, in blog posts, and in actual human to human conversation (it happens).

In a previous excerpt from the book, “Escape Velocity”, we looked at Velocity as a lagging indicator of a complex system. Here, we are going to think about velocity by way of analogy.

In this excerpt from Escape Velocity, we take a more in-depth look at Velocity and try to answer (at least in part) the question, “What Is Velocity”?

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.

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.

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

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"

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"

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

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.

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

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.

I read an article today that was posted on LinkedIn. I'm not going to link to the article. I'm not going to tell you who wrote it. I am only telling you about the article to set the stage for what I want to write about in this quick post.

In the article, along with "taking the best from Waterfall and Agile" and mixing them together into a "perfect methodology", the author, as a self-proclaimed change agent, suggested you should force implement all CMMI Level 5 developer practices at once.

Fist to Five (a.k.a. Fist of Five) is a simple tool for measuring level of agreement in a team. Often, this is far more expedient than discourse, even among those in agreement. Secondarily, it helps to overcome “silence means consent” for teams where this may be an issue. This is not a replacement for discussion, merely a way of getting a quick check to determine if more discussion is actually warranted.