Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

As mentioned here:

http://scrummethodology.com/the-agile-manifesto-and-twelve-principles/

Agile and Agile Scrum is pro-business not pro-software development. A business can execute flawlessly on the wrong software or wrong requirements and cease to exist. Additionally, the company could deliver the wrong software features and miss the market leaving the customer unsatisfied and motivated to take their business elsewhere. The software is only valuable if the market agrees. Therefore, Agile embraces the idea that a steady stream of value delivered to your customers is the name of the game - not a steady stream of pristinely written software void of value.

Shorter cycles are preferred as Agile does not seek to play the fortune teller game. Humans are terrible at predicting the future. We all trick ourselves in believing that we can do it. This is the exact reason (*) Waterfall is at a disadvantage compared to Agile in most dynamic business situations. Plans created months ago degrade over time. New information is difficult to seamlessly integrate with the static and aging plans. Shortened delivery cycles naturally reduce the need for precise prediction during the time teams are formulating their solutions. Instead, the technical team must only worry about what they can control in more realistic and shorter time periods. This concept is certainly a tricky one to grasp and it would also be wrong to assume that Agile is all about making it up as you go along. Agile values planning and requires it, but Agile recognizes that the plan is not the end game - happy customers and creating business value is the real goal.

Agile values information in the present much more than speculative information projected in the mid to long-term future.

Agile and Agile Scrum is seeking to strike a balance between exerting energy on a plan versus exchanging that same energy by building solutions around immediate information. Agile values information in the present much more than speculative information projected in the mid to long-term future.

Agile and Scrum surrenders to the fact that even the best plans are going to be wrong - so this is exactly why we opt to deliver frequently to our customer. The partnership that can be established with these frequent interactions is also one of the hidden benefits with Agile and Agile Scrum. High stakes software development is more about the trust established (or not) between a business and the customer. Bad news can be delivered more easily when trust and transparency are valued higher than other aspects of the business relationship. This will yield collaboration which will foster joint problem solving.

Agile and Agile Scrum is less about the methodology and more about creating legitimate solutions that keep customers happy and business healthy.

In business, working software delivers value to real people with real unmet needs. Agile and Agile Scrum is less about the methodology and more about creating legitimate solutions that keep customers happy and business healthy. It is really easy to lose sight of this within IT departments. Job titles combined with specific job functions cloud this message. Ask a Database Administrator (DBA) what they do and they will tell you that they clean tables and balance the data volume within the database environment. However, all of that is necessary to keep a customer happy. One day there could be a better way to keep the customer happy and the DBA should be focused on that goal as this will lead to better or innovative solutions. Frequently delivering working software or even partially working software will clearly reveal the needs of the customer. Extracting real customer need will reveal opportunity and this is why Agile and Agile Scrum is powerful as it naturally creates these opportunities to co-evaluate and even co-create working and valuable software with the customer.

(*) Waterfall is great for massive engineering projects where the goal never changes - like NASA projects. Get to the moon or land an expensive piece of metal on an orbiting rock. The goal is static and clear (even binary - you succeed or you don't), but the solutions are in question. Therefore, before a solution is selected, exhaustive planning must first take place. Oh, by the way - NASA can afford to do this because they have billions of dollars to create 2 or more of their prototypes to test and they have a decade or more to get everything just right / "perfect". Businesses don't have decades to "get it right" and most certainly do not have billions of dollars in the project budget. Different rules for a different game.

About Author

Nick Maravich

Nick Maravich

I am software enthusiast and I have worked in Start-Ups and in large organizations. I am currently an Enterprise Agile Coach with a Healthcare Organization.