Ask your Amazon Echo... What is the Prime Directive?

Agile. So you think you're an agile practitioner? Well... I can tell you, if you spend more than 75% of your day in meetings, trying to predict how much time it will take to complete the project, then I would strongly disagree. Twiddling and re-twiddling fabricated estimates you somehow created without building software or releasing to production does not make you an agile practitioner.

Agile is all about the enablement of releasing code to production... OFTEN !!!  And by often I mean more often than 10 months... or another way of putting the same statement... NEVER.  Come on, people.  'NEVER' is not acceptable.  I would be happy with once a month, and once a week would be delightful.  I am not even going to think about having the discussion around the idea of continuous deployment.

And by production... I think we should strive for apps to be released to a device where an actual person can touch the screen and make things happen.  Bundling up features into a releasable package would be fine and probably quite acceptable to the consumer / user of the application.  The benefits of releasing the application to a somewhat public audience, where we can get 'real' feedback would be invaluable.  You do realize we are all about feedback... keeping the product in alignment with the changing needs of the product owner and the business.

As you read the remainder of this... please sit and read this as you are the product owner or better yet, the technical manager of an agile team trying to deliver business value to your company.  Why would you want to deliver a product... early and often?  Why would you want to receive feedback (real feedback) from the customer and allow your progress to be driven (guided) by these changes in direction.  Seems like the right thing to do.

In the case of my example for this post.  Making even a small adjustment to the release cadence would make a huge impact to the delivery of the product including quality and correctness.  Imagine if we could deliver something every six months (remember currently we are sitting at 10 months... with nothing delivered).  Delivering something every six months seems a pathetic goal for a team accustomed to delivery on a weekly basis, but to a team only delivering yearly... this would be a doubling of the value delivered to the customer.

Why would you want to deliver faster?

• faster customer feedback
• what you are trying to build, will change... do you want a waterfall project where you deliver something 12 months after defining it... I am sure you can remember one of those projects.
• risks become smaller because you are dealing with them faster
• value faster
• code management is easier
• smaller regression cycle (both from an automated and manual standpoint)
• trust... working software... makes customers happy
• cycle period from request to working software is smaller

EARLY and OFTEN... not a bad thing!

Docker Machine