Software products are necessarily emergent – we not only don’t know what we precisely need to build but the need shifts as we attempt to figure it out.
Emergent contexts are complex and complexity is best managed by diverse groups of experienced individuals working together. They need to work together to interpret the outcomes of their efforts and decide what to try next. They need to leverage their collective knowledge - the amalgamation of all their perspectives - in order to make well-informed decisions.
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".
The Autonomy, Connection, Excellence, and Diversity (#CultureACED) framework is foremost in our minds and directs the work that we do. Our customers have and will become familiar with these ideas. Not just the words, but the actual tools and techniques we've successfully used in a number of organizations.
In a complex system, our certainty cannot be in our ability to know what will happen, but in our ability to learn and adapt. To accelerate our learning, we need to engage with the system in small ways. We need to probe the system to see how it responds and then adjust.
In a complex system, we must experiment.
Software products are necessarily emergent – we not only don’t know what we precisely need to build but the need shifts as we attempt to figure it out.
Emergent contexts are complex and complexity is best managed by diverse groups of experienced individuals working together. They need to work together to interpret the outcomes of their efforts and decide what to try next. They need to leverage their collective knowledge - the amalgamation of all their perspectives - in order to make well-informed decisions.
A lot of teams struggle with collaboration because they don’t practice Autonomy, Safety and Structure. They often don’t have the autonomy to opt in or out of decisions, discussions or even meetings. If they do opt in, teams might not have the safety to speak honestly or the structure to actually get to the best options and decisions.
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 the 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"
In the past few years, we at OnBelay have had the honor of working with companies on creating better engineering cultures and in that time have matured to a more structured approach.
One key tool we use today is the Experiment Canvas. My partner, Diane Zajac, and I co-developed the canvas. It is based heavily on our experience with A3s. It is still a work in progress, but I want to share with you where we are to date. Please feel free to use it and give us feedback.
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 the book, "Escape Velocity".
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”?
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.
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.
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?
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.
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.
The Autonomy, Connection, Excellence, and Diversity (#CultureACED) framework is foremost in our minds and directs the work that we do. Our customers have and will become familiar with these ideas. Not just the words, but the actual tools and techniques we've successfully used in a number of organizations.
