THE AGILE MANIFESTO: APPLYING PRINCIPLE #3

In February, 2001, seventeen independent thinkers, self-described as “The Agile Alliance,” collaborated on what emerged as the #Agile ‘Software Development’ Manifesto, a set of values and the “12 principles of Agile Software”. I have provided a brief explanation of each of the agile principles here, but this article will discuss Principle #3, “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale”. I will dissect its meaning, review some best practices, as well as discuss some of the challenge’s organizations face when implementing this important principle. As you may have noticed from other articles, I will take the perspective of applying this to any product, not solely software.

Organizations do what works. Sometimes in doing so they forget to adapt and improve. While things are never as good as they can be, people often believe that if its working there is nothing they need to do differently – the adage “if it ain’t broke, don’t fix it.” However, too often they find themselves excepting good enough or even mediocrity as a marketable product. They forget or fail to learn from the stories of Blockbuster, Compaq, and Solyndra and inevitably are forced to change or shutter forever.

If you do not listen closely to your customers and instead of delivering high quality products they want, you throw everything at them that you think they might want, and worse at exceptionally low value, you are sure to fail. Understand that it is not about how much you deliver, per se, but rather how well what you deliver functions for your customers and fills their needs. Therefore, Agile teams need to build quality into their products so that their customers are not burdened with bugs that prevent them from using the product without issues and challenges.

So, we need to get away from the “timeline first mentality” and focus on delivering working products that have been effectively developed and thoroughly tested. We need to discourage delivering products that are simply good enough and instead adopt a zero defect, stop-the-line mentality. This not only effectively satisfies our customers’ needs but also decreases the amount of rework necessary to resolve defects identified late in the process, improving flow.

Furthermore, we must understand the term “deliver,” which can mean different things. While it may mean your organization is deploying your product to a staging environment, production environment, or some warehouse somewhere, it may mean to others that it has been released to their customers for immediate use, while to others it may only be released to a select set of customers or beta users. In any case, no matter what environment you are delivering your product to, you will want to deliver it in a working manner. We need to build quality into our products to alleviate the need for rework and shorten that timescale.

Delivering working software, or any product for that matter, is about quality. Our customers do not appreciate any products they purchase that do not work as expected. Instead, they want and expect to rely on the products we build and deliver to them. When we deliver quality working products we satisfy and sometimes excite our customers. When we build quality in and deliver working products frequently, we delight our customers in ways that increases brand loyalty.

We can all agree that frequency is a very subjective term unless further described by measurement. In the case of this principle, “The Agile Alliance” defines frequency as the delivery of working software within a relatively large band of 2-10 weeks. While many organizations practicing agile these days are delivering far more frequently, and some extraordinarily successful shops thousands of times daily, the principle is there as an attainable guideline toward continuous delivery.

Why such a wide band of what is acceptable? Each organization is different and has different flow impeders related closely with the eight wastes of #Lean. Every organization has different maturity levels when it comes to their continuous delivery pipeline and #DevOps practices. Every enterprise has its own set of challenges, their own unique products, culture, and processes. These challenges and unique circumstances are why some can deliver multiple times daily, and others struggle to deliver even once a quarter or even a year.

Furthermore, the intent is for this delivery frequency to continuously shorten. In alignment with Principle #12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly, the expectation is that teams will continually improve their practices and review and refine their value streams to ensure wastes are eliminated and efficiencies are maximized. Teams need to retrospect their efforts every iteration – whatever that length may be, shorter being generally better – and work toward elevating that delivery frequency, that is making it more frequent.

As noted above, you should continuously work toward faster delivery, whatever that means to your organization. You need to look to deliver your products, or enhancements to those products, to your customers as frequently as makes sense. This is determined by the business based on many things such as market rhythms, events, and milestones. When can your business gain the most benefit from this products release? When can you extract the greatest value from it? Now or sometime in the future?

In any case, a shorter timescale provides for more frequent feedback from your customers enabling your teams increased agility and ability to pivot, as necessary. Whether we are gaining that feedback via live demos, beta use, leading indicators and/or some sort of telemetry, it can be extremely informative and drive our teams in the right direction.

Preferably, all our teams are continuously improving and looking to resolve those things that are impeding our progressive delivery. As feedback is received and retrospectives effectively done, actions are taken and the time to deliver working software or products shortens gradually and sustainably.

1. Implement short 2-3 week Agile development cycles called “Sprints” or “Iterations” with demonstrable delivery of a working product each cycle. This will require the team to break larger solutions into smaller chunks consumable and deliverable within this timeframe.
2. Adopt using a Kanban with best practices such as WIP limits, Definitions of Done, well written stories, policies, and working agreements.
3. Continuously look to adopt extreme programming (XP) practices such as Collective Ownership, Test Driven Development, Pair Programming, and Refactoring within your teams.
4. Demo all the things! At the end of each sprint demonstrate the working solution to all stakeholders and customers and encourage open and honest feedback. Include the team!
5. Regularly retrospect processes and practices and make improvements iteratively.
6. Separate deployment from release and communicate/educate the teams as to what that means within your organization.
7. Continue to refine and improve your continuous delivery pipeline and DevOps practices to include blue/green deployments and testing and staging environments that emulate production.
8. Consider mapping your current and future state Value Stream semi-annually in order identify wastes and impediments to the process and implementing improvements.
9. Adopt a zero defect or near-zero defect culture with a stop-the-line mentality.

In summary this principle is relatively simple to understand. Deliver working software, not defect / bug ridden software that must be regularly fixed. Deliver it as often as makes sense. Break it down into smaller chunks so that we can demonstrate its capabilities, receive feedback, and adapt to any necessary changes. The smaller we can break down a solution, while still providing value to our customers, the faster we can deliver it, and the faster we and our customers can extract value from it.