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.
What if certain types of management or leadership rose in popularity because they fit the social structures of the time? And what if those social structures were influenced by other factors? Factors that also impacted work. And what if each leadership style was optimal for it's given context?
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.