Over the past several years, as I’ve been helping teams and organizations improve their ability to deliver software products that are desirable, viable, and feasible, I have been experimenting with a Behavior Framework that has proven to be rather effective. And I’d like to share it with you in hopes that you find it useful and that you provide me feedback on your experiences with it.
My plan is to write a series of blog posts all related to the behaviors framework. Some of them will be about a specific behavior. Some of them will be about tools or techniques that help teams express one or more of the behaviors. Some of them will be my own experiences. And some will be damn near complete fiction.
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.
When I say, “work together”, I mean just that. Do the actual work together.
Every aspect of the product lifecycle is an opportunity for collaboration - Identifying problems to solve, user and market research, design and architecture, formulating experiments, development and testing, deployment, monitoring, maintenance, and gathering user feedback.
A lot of teams have a backlog of some sort and some form of Kanban board — whether it is Jira, Trello, Monday, Asana, MS Project, or a bunch of post-its on a wall. These are all ways of making the work visible. But they aren’t enough.
There are two key aspects to making the work visible; what is the work and how is the work progressing.
Over the past several years, as I’ve been helping teams and organizations improve their ability to deliver software products that are desirable, viable, and feasible, I have been experimenting with a Behavior Framework that has proven to be rather effective. And I’d like to share it with you in hopes that you find it useful and that you provide me feedback on your experiences with it.
My plan is to write a series of blog posts all related to the behaviors framework. Some of them will be about a specific behavior. Some of them will be about tools or techniques that help teams express one or more of the behaviors. Some of them will be my own experiences. And some will be damn near complete fiction.
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?
I was recently asked to answer a question on Quora about the challenge of keeping up with change in a software project. The answers were a resounding cacophony of “yes” - change is a real problem in software development.
Inspired by discussions with Jess Kerr and others, I took a different stance. Here it is:
Status Meetings - they happen every day, to thousands of people. Millions upon millions of corporate dollars are spent every year on them. Countless hours dedicated to attendance. And they suck. They are most often mind-numbing, pointless, disruptive wastes of time.
What if we could make them suck less?
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.
