Agile Delivery Cheat-sheet
By: Andrew Webber
Tags: Microservices, Continuous Delivery, Agile, Scrum, Software Development

If your process hasn’t changed over the course of a year, you’re probably not doing agile. — Martin Fowler

Agile, being a mind-set and not a process, encourages us to think about establishing continuous feedback with the customer. “Individuals and interactions over processes and tools”. The Agile landscape is made up of Values, Principles, Methods, Practices and Tools. When collaborating across departments and organizations, having similar Values reduces friction. Its worth noting that the Agile mindset is not limited to engineering departments. Agile Values transcend industry and departments like Marketing or Legal. This guide outlines some key observations on how teams can transition to Agile.

Overview

Empowered cross-functional teams

Collect quantitative data on customer and operational success

Deliver weekly to daily small increments of value

Automate from pilot to production

Empowered cross-functional teams

Take control by letting go. — Keith Code

An agile team is a non hierarchical collection of specialists representing User Experience, Quality Assurance, Product Enablement, Engineering and Delivery disciplines, working together to deliver customer value. An agile team is empowered to deliver customer value; having the tools, budget and authority to make decisions relating to their customer’s satisfaction.

An agile team establishes a psychological concept of a Safe Space. A Safe Space is a collaboration construct where any type of issue or discussion can be raised freely without consequence. There is no-blame-culture and responsibility for issues are shared across the team. Any team has the right to free thought and the ability to construct its own shared beliefs. Recognizing this right allows any team to bring the Agile mindset into reality.

Agile team responsibilities include the following:

Technology selection, application architecture, security and scalablity

Application deployments and upgrades

OS and Database maintenance where necessary

Application data backups and recovery

Metrics, monitoring and alerting

Compliance and total cost of ownership

At first glance, that’s a lot of responsibility. Operational experts are embedded in the team to help manage delivery concerns (commonly referred to as DevOps). Subject matter experts are also represented in the team from areas such as security, localization and observabilty.

However, agile teams may decide to shift some responsibilities by consuming managed services from a service provider. Examples include consuming services from a shared platform, working with an infrastructure enablement team or a third party. Use cases include Kubernetes as a Service, Serverless, Database as a Service, Container registry and more. Total cost of ownership and budget constraints typically become a decision making factor. However typically the team is best placed to make a decision as it is closest to the business problem.

Agile teams typically have a close relationship with teams such as Infrastructure Enablement, Security, Architecture and Documentation. This relationship allows expertise and governance to scale across the organization.

Agile teams have objectives that derive from the Program Enablement team (the co-ordination of multiple agile Product teams). The Program Enablement team objectives ultimately align with or are empowered by business and corporate leadership goals.

An agile team is self-organizing. The team decides which methodology or practices align best to delivering customer value. Methodologies and practices include but are not limited to:

Yes, a team deciding to do Waterfall based delivery, based on customer data, is by definition taking an “agile based” decision. In other words, the team decided how it wants to work in relation to the market conditions.

Although agile teams need to report within a co-ordinated reporting structure, agile teams typically pick there own tools. The agile industrial complex has many vendors looking to sell tools and solutions. However agile teams understand that productivity outweighs consolidation. Some agile teams simply use a post-it board to track and manage backlog.

Finally agile teams love to learn and continuously improve. A learning culture is established to continuously improve how the product is developed. They take pride in their work and recognize the value of craftsmanship. Practices such as aggressive refactoring, pair-programming, continuous integration, design improvement, test driven development all contribute to increased product quality and delivery speed.

Collect quantitative data on customer and operational success

How do we know if we’re going in the right direction? — inquisitive employee

Agile teams love making informed decisions supported by evidence. To do this they collect data like customer feedback or workshops data, delivery statistics and operational metrics. In order to not get overwhelmed by a massive amount of data, agile teams focus on four key KPIs.

Idea to delivery duration — How long does it take to go from idea inception to “happy customer”.

Delivery frequency — How often does the team deliver value over time.

Mean time to recovery — How well does the team execute against planned threats; disaster recovery, data restoration.

Change fail percentage — How often does the team revert; rollback, hotfix.

These KPIs are typically extracted from a single or multiple data repositories maintained by the agile team. Example repositories include backlog management systems, bug or support ticket systems and production monitoring systems.

Once tracked, this data allows the measurement of how successful the team is at making decisions, whether it be product related or engineering estimations. Remember, this transparency is not about finding someone to blame. The data allows the team to learn and improve how decisions are made in order to become more successful.

Teams that automate observabilty gain the ability to perform evidence based decision making in real time. Reacting faster than your competitor means a competitive advantage and the happiest customers.

Deliver weekly to daily small increments of value

How do you eat an elephant, one bite at a time. — Hungry person

Deliver, monitor and adapt. Frequently delivering small changes of value has a number of advantages:

More frequent feedback cycles helps find out if the team is going in the right direction, faster

Less burnout, predictable small units of work limited by Work In Progress limits (WIP)

Increased quality due to a smaller blast radius, if less has been changed, there’s less to test.

Increased stability and organization scalablity. Typically, in order to meet a high frequency, manual processes must be automated (e.g Deployment, Localization, Documentation, Communication)

Agile teams invest in skills to deliver a new fully operational product every day, twice a day or even multiple times a day.

Automate from pilot to production

If your in a hurry, slow down to go faster — The Power of Pause

“Being busy is not a badge of honor”. Being busy means less time being creative. Its not about longer hours but smarter hours. We want the day to react to us and not react to the day. As business demand increases, manual processes become the bottleneck.

Automation helps us scale, allowing us to deliver a competitive advantage with more time doing value add. Automation enables predictability. Predictability reduces burnout, increases quality and drives efficiency.

Automation is typically a by-product of the team’s investments in craftsmanship, enabled by an organization with a learning culture. Investments in automation are estimated and prioritized by the team. Typically teams mandate automation as part of a definition of done, a team agreed checklist that defines what it means for work to be completed.

High performing teams use the same automation for pilot environments in production, again increasing predictability. This automation doesn’t stop at the application layer. Entire infrastructures can be spun up and maintained in production with the same approach for pilot environments.

Some fear automation means job insecurity. If everything is automated will I still have a job? When we transition to new energy sources do we end up using less power? Initially maybe but then we find new use cases to use more energy. The same can be found with automation. Once everything is automated, new challenges emerge. New challenges mean new opportunity. Got the skills to automate? Your not going out of work any time soon.