Principle #3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
While there are many people who believe that the key reason to adopt agile frameworks and methods is for increased productivity, I tend to find this to be more a healthy byproduct of a team working together over time (and thus could be found in other methodologies).
The real benefits of agile lies in greater transparency, predictability and faster time to market.
The third agile principle speaks directly to these, especially quicker time to market.
When organizations I have coached are having issues with agile adoption, I have come to expect that they will have difficulty upholding this principle because it requires the most organizational change. It is no coincidence that there is a greater desire for “dev-ops” as agile transformation is attempted by more, especially large, organizations. In one of my regular presentations I argue that there are two things necessary for agile success over the long term: One of these is Continuous Delivery (or at least continuous integration; the other necessity is acceptance test driven development or ATDD, with my preference being BDD).
It is difficult to deliver working software often, but it is critical. In fact, even if a team is not good at delivering working software often, there is a tremendous amount of value to be obtained trying to deliver software often if only to find out the reasons why your team cannot.
In consulting with organizations I am often asked to merely optimize agile teams, but the real work of transforming to a complete agile system is not considered. These “Wagilefall” organizations are nothing more that Waterfall process with “agile” development (In a lot of cases even this “agile” development itself is not very agile).
I often ask organizations a simple question, “How long does it take you to deliver even a single line of code change into production?”
This is one simple question to gauge your agility. If the answer is more than a day or so then there is a lot of work that needs to be done for continuous integration or continuous delivery. I find it amusing to think that a “big bang” approach with months of code changes can be successfully delivered if it is so difficult to deliver only those few changes that are a result of a single iteration.
Feel free to add me on Google+
Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Android | RSS