What are the most important ideas for a software delivery team to discuss?
Later today, I will be attending a meeting about software estimation. We will discuss if estimating is essential and figure out the right level of estimation to do for our teams. Overall, reasonable goals and a good approach. But these are not the most important topics for a software delivery team to be discussing.
Discussing technical practices is an important idea for software teams. Are we going to use TDD or BDD? Can we deploy this in a serverless environment? Should we ship straight to production? What was our MTTR over the last quarter? Are we deploying often enough? Do we build our telemetry solution? These are valuable ideas that get team members excited about their work. And these are not the most important ideas.
Discussing process is a significant component of building a software team. Should we use Scrum, XP, or Kanban? Can we improve our practices? How many meetings do we need? When is the next retrospective? Which format is best for writing user stories? Is our daily stand-up efficient? There is value in each question. And these are not the most important ideas.
Discussing business goals is vital for software delivery teams. How many downloads did we get in the app store? What is our drop off rate? What is our CAC/ATV ratio? What’s the burn rate next month? What are our OKR’s, and do they support our MIT? These are valuable ideas. And they are not the most important idea.
The most critical question a software team can discuss is, “Are we making things a little better for our users?” Are they a little happier, a little more productive, a litter better off because of your team? Sometimes that may be through software and the systems that we build. Other times, it may be by simplification by removing features that can eliminate an entire class of problems.
Many times, we don’t know. Then, we depend on the technical practices to help us figure things out. We lean on goals and vision to come up with concepts that we can explore. We put ourselves in the users’ shoes. We lean on our process and our feedback loops. We know a little more.
Is the user better off because of your efforts? Address that question, over and over. The solutions may not even involve software delivery.