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

Agile is all about solving problems, the Cynefin Framework can help you pick the right agile framework for your team

According to the 2020 State of Agile Report, Agile software development is now the de facto delivery mechanism at more than 95% of technology organizations worldwide. With widespread adoption and organizational interest in Agile investment, many individuals and organizations have created different agile delivery frameworks. As a result, there are many frameworks in use at this time in the technology industry, including some notable ones such as Scrum, Kanban, Scrumban etc.

This article will share the importance of Agile and how different frameworks, including Scrum, can fit into your organization based on the software products you’re building. We will also cover how using the Cynefin Framework can help you identify the best agile delivery framework for your use case.

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.

So, if those executives didn’t have it right then what is Agile? Agile is:

A mindset where people in organizations live by Lean/Agile principles; and values while ensuring these principles are upheld most of the time

Is an Agile delivery framework always needed for software development?

The straight forward answer is “NO! “ because:

• 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.

A simple comparison of software development problems and suggested delivery frameworks

What if you are unclear which of the other four contexts is predominant in your organization?

That’s called a Disorder state.

In this situation, break the situation into its constituent parts and assign each to one of the other four categories as explained above. Then make decisions as appropriate.

Examples of the Cynefin Framework in action

Scrum

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.

It was very painful when a decision was pending and the creative people had to remain idle until the decision was resolved. The technology organization offered help to the decision makers which they accepted. They suggested that software development teams start running experiments by building prototype APIs, learning from them, and iterating again. Over a period of one to two months, a clear pattern emerged and it became easier for leadership to commit to a microservices based architecture for the new platform. This microservices architecture was a completely new technology to the organization and they foresaw that many more experiments would be required before the application would be fully developed. The software teams were already using Scrum, so the decision to use Scrum as an Agile framework for the entire initiative proved to be beneficial.

Kanban

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.

We worked on adopting their agile delivery framework from a Scrum to a Kanban framework so the teams were able to spend enough time on analysis. In addition, the team was struggling with multiple impromptu asks for data architecture and other deliveries from several units within the organization. It was easier to select top priority items from the backlog and manage various categories of requests and work on them. Since in depth analysis and flow of work items were most important in this case, refining our approach with a Lean based Kanban Agile framework made more sense here, and it was eventually implemented for them.

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.

Once the application was built for one state, the same process could be repeated for other states. There was no need for experimentation, much analysis, or to reiterate one feature after another because they were all largely the same. We remained in touch with the clients and updated them on the progress of the application development. However, they were tracking their progress through a traditional work breakdown structure and were able to complete the software development within the contractual timeline. Teams maintained an Agile culture and mindset but no Agile delivery framework was used. In fact, they used a traditional waterfall approach to deliver applications successfully across several states.

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.

Sandeep Paudel is an Agile Program Lead at Capital One Bank and has experience of working as an Agile Coach, Scrum Master and Project Manager. He loves solving complex business problems through innovative approaches and Lean/Agile Mindset. He is a AWS Solutions Architect, SAFe [Release Train Engineer (RTE) & Product Manager], PMP and CSP-SM certified. He can be reached via Linkedin here: https://www.linkedin.com/in/sandeepaudel/

DISCLOSURE STATEMENT: © 2021 Capital One. Opinions are those of the individual author. Unless noted otherwise in this post, Capital One is not affiliated with, nor endorsed by, any of the companies mentioned. All trademarks and other intellectual property used or displayed are property of their respective owners.

Originally published at https://www.capitalone.com.