Search
  • Tim Burns

Why Agile is all about Delivery

Updated: Sep 5


Jason Isbell Always Delivers

Deliver Working Products

If you do one thing with your Scrum above all else: deliver working products.


If you are running a development team, that is what you are paid to do. So do it often, do it the best you can, do it in a repeatable way, and, most importantly, do it for a real customer who will judge your work and hold you accountable.


Great, another agile philosopher! Just what the world needs. Fair enough - let me provide some specifics on how you can upgrade your Scrum to make it more effective.


Here are three tips on improving your development in delivering working products.


Tip #1: Timebox, Don't Point, any Spike Tasks

A Timebox is a start and end date for a task. Therefore, the best way to approach a spike is to assign a beginning and end date. According to the Agile Dictionary, a spike is:

A task aimed at answering a question or gathering information, rather than at producing shippable product.

There it is: You are not delivering anything with a spike; you are gathering information. It isn't resolving a story - it isn't burning down a set of story points towards a product objective. It is gathering information so that you can complete a story.


Timebox your spike according to the story at hand.

  • Schedule time with the customer to understand why they need the story completed

  • Gather statistics from a working system to understand the scope of your story

  • Write up a Wiki page describing the problem.

  • Discuss your learnings with colleagues and customers

Tip #2: Specify the Story in a Consistent Form

When writing a story for a Scrum ticket, use the following form:

My Story As a <customer>, I would like to <use the component>, so that I can <achieve my goal> Acceptance Criteria After executing <the component> I will be able to <a specific action demonstrating the goal>

In addition, here is an excellent article on how to write stories better: It's time to start writing helpful User Stories!


When writing the acceptance criteria, use specific process examples or codified lists to formalize how to validate the functionality supporting the story.


Don't be afraid to go back and refine the stories during development.


Tip #3: Eat Your Own Dogfood

There is no such thing as perfect communication between people. The more the developer understands the customer, the better job they will be able to do. Too often, developers think their job stops at writing code. They expect a product owner to hand them the requirements, and they will dutifully type it out and release a product that works for the customer. I've never seen this work in practice.


If you are building a small product for a larger team, use your product internally on your team. See how your application functions in the real world and continually improve the user experience. The development team should fully support all their code in development and not ask operations for help. If it is too much work for the team to manage in development, they must go back and do a better job.


20 views0 comments

Recent Posts

See All

Here is the ticket master public API. https://developer.ticketmaster.com/ Could be a very interesting edition to cross-reference with Playlist info to get hot concerts that may be under the radar.

Elon Musk embodies the worst aspects of the tech bro spirit. He has no moral compass. He lacks compassion. He elevates the vilest voices in our world. He is not the kind of person I would want to