Having a bias towards delivery

Having a bias towards delivery

So I’ve been having a lot of conversations lately about Scrum, and agile processes and it got me thinking. What is the difference between an effective agile team, and an ineffective one? What is it that makes some projects real excel in an agile world, and others not.

And as I was thinking about this, it got me thinking of the most effective developers I know. I’ve had the privilege of working with some really inspirational developers and engineers in my career and the more I thought about it, the more I realized there was a common thread between them all.

They all had a bias towards delivery.

So what exactly does that mean? And how does that lead to success in this field? Let’s start with the term bias, according to Merriam Webster, a bias is “an inclination of temperament or outlook.” So the bias is a focus on what we are inclined to do.

So when I’m talking about a bias towards delivery, I am talking about focusing our efforts with an inclination towards what the delivery will be, or what the outcome of the effort will be.

Isn’t this just Agile?

One of the most common problems in Agile development is that many of the team members or development teams, will often just approach scrum as a “take a checkpoint every two weeks.” Or how often we have this discussion of the idea of “definition of done.” All of this built around how we break up work, and that’s all valuable, but all too often I still see this fail because it fails to prioritize shipping software over going through the motions.

So as much as those activities are valid, I do feel like all too often the delivery element is lost in the discussion. IF you look at the Agile Manifesto, the creators of this philosphy saw this all too clearly. The very first principle of agile is:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Principles behind the Agile Manifesto

Examples

So this is all great discussion but let me get tactical on how this all too often is a problem for software engineering teams. How many times have you seen user stories that have no acceptance criteria or worse just say “meets definition of done.” This does not cover or provide definition for what the delivery is at the end. This just says some boilerplate cut-line that’s supposed to be a guide.

Let’s take a couple of concrete examples, first you have the following as a User Story:

  • Title: As a user, I should be able to edit my profile and make changes to my contact information.
  • Description: The user should be able to update contact information in their profile including email address, phone number, or twitter handle.
  • Acceptance Criteria: The solution will include all required changes, and appropriate unit tests, and conform with our definition of done.

Now to some people that looks perfectly fine and reasonable, but I actually argue that it is very ambiguous and doesn’t have a focus on delivery. My biggest question, “What is the expected delivery at the end of the sprint?” For example I would ask the following questions:

  • Is the expectation that I just have a PR Submitted?
  • Does it need to be merged?
  • What should a demo of this to the product owner look like?

It is not immediately clear looking at this work item what delivery looks like of this solution. Now this one isn’t terrible, and we can probably derive a lot of the information from standard practices in an established team, but the next example I have is much worse. The most common culprit I’ve found is the infamous “Research Spike”.

You’ve probably seen stories like this before:

  • Title: Spike – Research options of using PostGres vs Cosmos for Geospatial queries.
  • Description: Evaluate and compare the benefits of using PostGres as a GIS data store vs Cosmos DB for Geospatial queries.
  • Acceptance Criteria: Complete evaluation of technologies to help empower architectural decision.

Now this is really not a good use of effort, and provides almost zero guard rails the developer or support for timeboxing this evaluation. There is no real way to discern what specifically the evaluation would entail, and leads to things like “Moving this evaluation forward as we could use more time.”

A great way to change this I would argue is to focus on what will the delivery in 2 weeks look like. And also get very specific about what the focus of the spike will be. So if we change the above to something like this:

  • Title: Spike – Research options of using PostGres vs Cosmos for Geospatial queries.
  • Description: Evaluate and compare the benefits of using PostGres as a GIS data store vs Cosmos DB for Geospatial queries. Evaluation will provide the following key answers:
    • What are the potential performance gains to query execution times?
    • What new features will be available after changing platforms?
    • What potential feature loss could occur with the move?
    • What are the cost implications of the switch?
  • Acceptance Criteria: Delivery will include a report focusing on the questions above a Proof of Concept showing the relevant details from the report during our sprint demos.

Looking at the above, it becomes very clear what the expectations of the spike, and the delivery at the end of the two weeks looks like. It also means that the odds of this item “moving to next sprint” is very low. There is a possibility of this leading to additional research spikes, but it focuses the effort on what should be delivered.

How can I start adopting this approach?

At the most basic level a common practice of many of the great engineers I’ve had the privilege to work with is that they start the sprint by looking at each work item and saying, “What am I going to deliver at the end of the sprint for this?” And they decide on what that is, and work backwards to what they need to do to get there. I would recommend starting there and aligning your mindset towards what you are ultimately going to deliver. This will cause you to ask more questions of the work items your assigned and push you towards more the tangible delivery items that you should be focused on.

Leave a Reply

Your email address will not be published.