Finding the Right Delivery Framework for Your Software Teams | Capital One

What is Agile — a simple introduction to Agile

Once I was in a meeting with some executives and I started my presentation by asking this question, “What is Agile?” The answers were not what I was hoping for. Some of them brought up the name of some Agile frameworks like Scrum or Kanban. A few others mentioned ceremonies like Daily Stand Ups and the use of Jira. Now, I would consider myself an Agile framework agnostic agilist but that doesn’t mean I don’t respect people who love specific frameworks. However, it is not the frameworks we use that makes us agile, nor the tools that support our management of the process.

  • Agile mindset and an Agile culture is important in every organization. However, an Agile framework is not always necessary if that mindset and culture are firmly in place or being firmly developed.
  • Agile is an approach to behavior change where organizations, teams, and people shift their mindset to be more customer-focused.
  • Becoming an Agile organization means being more open to feedback from customers and responding to their feedback as quickly as possible.
  • Agile teams build a small piece of the product that can deliver value to customers and repeat the cycle of early and frequent delivery by working through a backlog of customer experience requests and changing with the industry and the technology.
  • Agile is about breaking down silos through frequent interactions and autonomy in decision making.

How to pick the right Agile delivery framework

Based on my experiences as an agilist, I would suggest using the Cynefin Framework to help pick the right Agile delivery framework for your teams. The principles of the framework are well tested in both government and a broad range of industries to solve organizational problems. Based on this framework, we can divide organizational problems that software products can solve by putting them into one of the following categories — Complex, Complicated, Obvious, and Chaotic.

Examples of the Cynefin Framework in action


A few years ago, I was working for a large government software development initiative. The initiative required decommissioning eight legacy software applications and building a new platform that encompassed all the features from each of these individual decommissioned applications. The application architecture was constantly evolving and many other decisions were yet to be finalized, which meant the software development teams were often left in the dark and did not know where they were headed.


Another time, I was working for an enterprise technology group organization within a company that was undergoing a major data restructuring. Most of the data engineers in the team were writing code and scripts for extract, transform and load (ETL) operations. Some of the databases they were working with were highly complex with data integrity issues. Huge analysis for each set of data; and schema tables in each database were required. Teams were using Scrum as their agile delivery framework. However, at the end of every sprint, teams were not able to complete most of their work nor was there work that could be reviewed easily.

Traditional (WaterFall)

Then there was the time I was working for a healthcare IT company building applications for state Medicaid customers. When I started working for them, they mainly built web portals, but some states started asking for Android and iOS apps as mobile phone usage grew amongst their customer base. We had some experience building iOS and Android apps for other projects and the requested features for these mobile apps were available in the original web portals, including — insurance ID cards, provider offices or hospitals, claim status, coverage, etc.

When frameworks do not help

When I was working for a travel company, the organization that had a global distribution system (GDS) as one of their main products, a database of airlines, rental cars, and hotels all around the world leveraged by other sites and companies. The base system was built 40–50 years ago and the company did not have a staging (non-production) environment to develop new features, apply fixes for issues and test the fixes or improvements. If something is broken, it is very hard to fix it since it had to be done through a trial and error method. Software engineers were in fire fighting mode whenever any issues were reported from the customers. In this situation, there is no delivery framework that is helpful to solve such problems. Often, organizations need to de-commission such applications and build something new that can solve customers’ problems as quickly as possible.

How to Solve Bigger Problems?

This blog provides a basic outline for selecting a delivery framework for small teams or organizations. However, if you work in a much larger organization with multiple software development teams, there is an entirely additional set of frameworks needed to scale delivery mechanisms. Stay tuned for the next blog in this series which will address how to select the right scaling delivery framework.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Sandeep Paudel

I am a continuous learner, technology enthusiast and a thought leader who loves to solve complex business problems through innovative and lean/agile mindset