The key expectation for Agile based project deliveries


I always like to attribute many things we do at work to a real life example elsewhere, say at home.

Let’s consider that you order a pizza for your family at home. You give your requirement, your contact information and pay for the delivery either upfront or when the delivery takes place.

From the moment you order the pizza, your patience has a limit of waiting for the delivery boy. Perhaps half an hour, or an hour after which you will begin to consider what to do next. So finally the pizza boy comes in and hands over a pizza. You are smiling, your family is happy and you are feeling great that you got what you ordered.

But just then you notice that you have got a 9 inch pizza instead of a 12 inch one. You ordered a panneer pizza (veg), but you got a pepperoni pizza (non-veg). And the boy arrived an hour and a half late so your pizza is cold and not edible anymore. You are seething with anger and decide to cancel your order. For good reasons. The delivery did not meet your requirements.

This example is somewhat a simple one, but brings about the fundamental things that one would like to expect while committing to a job for delivery.


the most fundamental expectation in Agile is to develop WORKING SOFTWARE

The pizza example highlights a lot of things that can go wrong with Agile development some of which is listed below

  • Understanding the requirements wrong
  • Designing the wrong product
  • Delivering the product too late
  • Delivering an unusable product
  • Delivering something that has no business value to anyone
  • .. and lastly having to deal with the frustration caused by time delays, misunderstanding needs, and bad products on your hand which you cannot use. An evening with family shattered.

Of all the things that goes into putting effort for each iteration the most important thing to focus on is to have working software at the end of the iteration. This is not about finishing up a piece of code, but rather what can an end user do with that piece of code.

What is the business case that has been achieved with that code completion? What part of the overall software is now usable or consumable by end user? These are the questions that should go into defining the meaning of working software in the delivery context.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s