Agile is not a silver bullet methodology that helps engineers build product faster or somehow equips organizations to deliver higher quality software to customers more frequently at less cost. Rather, it is a journey that builds the organizational culture, mentality, and behaviors that deliver more value to its customers with higher quality, greater reliability, and improved timeliness. Striving for agility is comprehensive. Knitting the pieces together can be complex.

Therefore, to help understand “agile,” we have been working on a “framework.” This framework hopefully displays the comprehensiveness of agile, while knitting together the essential practices and services necessary to deliver agility. We like to think of this as an “Agile for Dummies” framework.

Agile for dummies framework

Delivery Value Stream

The Delivery Value Stream consists of all the activities required to deliver high quality software (or any product for that matter) that the customer values and will pay for. The Delivery Value Stream starts from the initial conception of the product within marketing and design and product management, through the creation of the product (product development and/or manufacturing), to the delivery of the product to the customer (operations, logistics, etc.); including the ongoing monitoring and measuring of the product performance within the marketplace.

Culture of Innovation and Experimentation

Perhaps most importantly, for an organization to be agile (for agility to exist), there must be leadership that encourages a culture of innovation, experimentation, ownership, and accountability throughout the entire value stream. Continuous improvement and performance excellence is also at the core of this culture.

Value Creation

I like to think that there are three main or central questions to building software. Each question represents one of the major components of the Delivery Value Stream and each is accomplished with unique skills, resources, knowledge, and methodologies.

  • What value needs to be created?
  • How do we create that value?
  • How often – at what frequency do we need to deliver that value?

Answering the “What value needs to be created” question is often answered through Product Management, Human Centered Design and ultimately represented by the Product Owner. Through experience, knowledge, research, discovery, experimentation, observation, etc., Epics, Features, and Stories are written to describe the context, intent, and value of WHAT needs to be built to meet the customers needs and desires.

Answering the “How do we create that value” is the product development engineering team – systems and application architects, database designers, developers, test engineers, etc. It is their job to convert the Epics, Features, and Stories created within the “What” definitions into the usable, high quality product that the customer values. Depending the size of the project and product, the skills required to define the how may be within a single team (full stack), or shared and coordinated, in some cases, across many teams (ART). In either case, engineering teams are to focus on HOW the product is to be built.

How Often
Traditionally, one might think of this region of the framework being addressed by an “operations” team. But within an “agile” environment, we would anticipate a DevOps solution where the design and operations teams are working together to shrink the delivery time of usable software to the customer utilizing continuous integration and continuous delivery methods, tools, and practices. HOW OFTEN can be dictated by numerous factors: quantity and size of teams; the complexity of the product; where the product lies within the development cycle; and the anticipated need to scale. To ignore this component of the framework however, is to put the core of agility at risk. Namely, it prevents customers from providing essential feedback to the Product Management and Product Development teams on a regular cadence.

Organizational Change Management

As an organization chooses the path of agile, major shits in behavior changes must occur throughout the organization for agility to occur. Often, the most important changes (and the easiest to overlook or ignore) need to occur in the leadership. Organizational Change Management (OCM) is an essential component not just in the implementation of the departments that deliver WhatHow and How Often, but also with the leadership to build a culture that supports and grows agility. Implementing, instituting, and maintaining a culture of agility requires comprehensive, intentional OCM to reach all levels of the organization.

Feedback Loops

Finally, and no less important, is the importance of building Feedback loops throughout the process and organization. Feedback, in all forms, qualitative and quantitative data, is the breakfast of champions. Feedback loops, formal and informal, must be built to facilitate constant and continuous feedback throughout the entire Delivery Value Stream. Without feedback, continuous improvement is stymied, and research, discovery, and experimentation is blinded. And while all the agile methodologies do have feedback loops within their structure, the organizations that find ways to extend beyond these grow their agility more as well.

In conclusion, agile (noun) is not a silver bullet. To be Agile (adj) requires a comprehensive approach to product development; while complex and integrated, it nonetheless can be explained relatively easily, even for and by us “dummies.”