Agile 2.0 and the Continuous Delivery Mindset

Today’s Agile is not “agile” enough. This was the message I took away from the Agile Roots conference in Salt Lake City this week, where topics around Continuous Delivery and returning to the foundational principles of Agile weaved into many presentations. As I observe trends in our industry as well as the tech sector as a whole, it becomes more clear all the time that even established businesses now operate in an environment of extreme uncertainty. Prescriptive methodologies that drive long cycle times simply cannot keep up with the pace of change in an increasingly services-oriented world.

Continuous Delivery provides the technical foundation for a software development lifecycle that can respond to this pace of change. I remember a few years ago when AtTask first adopted Scrum, and started shipping code every month. We thought it remarkable that we could deliver working software at such a rapid pace! How quickly things change–it’s not uncommon for development to ship code into production several times a day! Examples include IMVU, Etsy, and Flickr and many others. Even in large scale organizations like Facebook, a daily deployment is now possible through robust automated testing and clever use of virtualized infrastructure. As I’ve described in other posts, AtTask has adopted a rich CI pipeline, which includes many of these features and now facilitates daily deployments. We have the technology to react to change at the pace the market demands… but do we have have the professional will?

An “Agile Mindset” can be demonstrated by adoption of the agile values in the decision making process of an organization. Agile teaches us to focus on delivering value over adherence to a plan, and to focus on results over process. Ironically, Scrum as it’s most commonly practiced is a heavy weight process in itself, and while it can help enforce agile principles, there are many examples of companies who keep to the pomp and ceremony of Scrum, but gain little value from the flexibility it affords to the product development process.

One of the Agile Roots keynotes this morning was given by Dr. Israel Gat (@agile_exec) on the subject of Agile 2.0. The thesis is that converging market trends require a re-assessment of the Agile practices we have followed over the past 10 years… that in some ways the Agile of last decade is just not “agile enough” for the years ahead. These trends include:

Hyper-segmentation of markets: such as the proliferation of social tools serving every conceivable niche community

Transiency of markets: It is not uncommon for a market need to come into being, but exist for two or three years only to be superseded by a new innovation

Value chains becoming value webs: Most value is derived in the interconnected world by the confluence of different synergistic services.. For example, a phone that is also a camera that integrates your phone contacts with a photo sharing service.

In response, we must tailor the processes which facilitate value delivery to match the speed and uncertainty of the market we operate within. Here are a few examples:

Replace pre-planned backlog silos with a shared backlog which is pull-based, allowing teams to self select from a prioritized order.

Begin to track capacity not as a function of estimation, but by measuring throughput (cycle time) on consistently sized units of work. This is also an Agile 2.0 way to predict delivery dates.

Instead of focusing on what features to add to a product, refocus efforts around customer development. This could include product features, but encompasses other areas such as in-product feedback mechanisms and processes to facilitate rapid bug resolution.

Replace sprint planning and intermittent grooming sessions with continuous grooming of the backlog in response to new market learnings.

Demonstrate and sign-off work in discrete functional units instead of arbitrary time boxes, such as Sprints.

Some of these are radical changes for an organization built around the heart-beat of sprints… In the past, the business itself has been subject to the rhythm of development. In Agile 2.0, we jettison many of these processes which have been rendered technologically obsolete, and free ourselves to focus on moving past value creation to value realization. We decouple the mechanisms of software creation from the requirements of the business to position and sell. It requires the bravery to recognize that the market is intrinsically uncertain, and to venture there.