DevOps Zone is brought to you in partnership with:

Kevin Rutherford, PhD, is a UK-based extreme programmer and agile software coach with over 30 years professional experience. He developed the Reek code-smell detector for Ruby and co-authored "Refactoring in Ruby". Kevin is a DZone MVB and is not an employee of DZone and has posted 12 posts at DZone. You can read more from them at their website. View Full User Profile

Releasing vs Delivering

04.26.2011
| 3128 views |
  • submit to reddit

Here’s a quick thought that you might like to use in your next retrospective: Do you know that the software you just released has realised the expected value?

What if the answer is that you don’t know? How could you find out? And what might be the positive or negative side-effects of going to find out?

Here’s another way to look at the same question: Do you deliver more value by moving to the next story/MMF, or by helping the current story/MMF to release its full potential? Is there a single answer for your software/service? If not, what factors or conditions would cause the answer to change?

References
Published at DZone with permission of Kevin Rutherford, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Muhammad Faiz replied on Fri, 2012/04/13 - 8:56am

Interesting article.
Sometimes I wonder the same thing to myself when we deliver Releases of software.
Understood the client pays a licence fee but and they pay for a service.
But the process involved in getting changes into production and the impacts to the business to conduct UAT I wonder is it all worth it for what is being provided.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.