Why Software Delivery is so slow?

Agile promised us fast delivery. So why are most teams still struggling with delivery speed?

Welcome to the free edition of Optivem Journal. I write about Modern Test Pyramid & Modern TDD practice to help you escape the nightmare of Legacy Code. I know you're stressed & don’t have time, and you don’t want to wait for several years. If you want support on your TDD journey, join our paid community of 160+ senior engineers & engineering leaders. Get instant access to group chat & live Q&As:

---

Most companies are NOT agile. They work in a waterfall style:

1. Development phase

2. UAT & bug fixing phase

3. PROD & hot fixing phase

During the development phase, everything appears to be going well.

Then, in the UAT phase, everything comes crashing down. QA Engineers report numerous bugs, and developers are frantically fixing them.

Release Cycle Structure

The following is a typical structure of a Release cycle:

1. Development phase (multiple sprints)

2. UAT & bug fixing (1+ sprints):

   1. Deployment to UAT

   2. QA Engineers report bugs

   3. Developers fix bugs

   4. QA engineers re-test

   5. Repeat

3. PROD & hotfixes (1+ sprint)

   1. Deployment to PROD

   2. Customers report bugs

   3. QA Engineers reproduce bugs

   4. Developers fix bugs

   5. QA engineers re-test

   6. Repeat

---

📢 On Wed 18th Jun 17:00, I’m hosting TDD & Unit Tests (Live Q&A):

P.S. If you’re a Paid Member, you’ll receive a 100% discount (see Event Description for instructions on how to redeem your 100% discount).

---

Releases are so slow!

Due to increased regression bugs found during UAT, it leads to greater rework costs, because the later the bug is detected, the more expensive it is to fix. The UAT Stage then takes longer and longer, causing the overall release cycle to get longer, thus delaying releases. (The problem is further worsened in the PROD stage, where the cost of rework is even greater.)

The Band-Aid Solution: Increasing headcount

Companies try to hire more developers and QA Engineers, but it’s just a band-aid solution. Over time, releases still get longer.

The Root Cause: Why Slow Delivery

Root Cause: Manual Testing

• Development takes too long because developers have to spend a lot of time on debugging

• UAT takes too long because QA Engineers have to spend a lot of time on Manual Testing, and Developers have to waste time during late rework (very expensive)

Root Cause: Test Last

Teams follow the waterfall approach:

1. PO writes requirements

2. Developers write code to satisfy requirements

3. QA Engineers test the system based on the requirements

The consequences are as follows:

• During UAT, QA/PO & Developers discover late misunderstandings of requirements, thus causing higher cost of rework for developers

• Before UAT, Frontend and Backend Developers experienced a lot of integration issues between themselves (as well as integration issues with External Systems) because there was miscommunication regarding their contracts, and they had to wait for each other to finish to be able to test

What’s the solution?

Solution - Part 1: (Automated) Acceptance Testing. We should translate Acceptance Criteria into Acceptance Tests, and use this as a replacement for Manual Regression Testing.

Solution - Part 2: Test Driven Approach:

• TDD - System Level: By writing Acceptance Tests before coding (i.e., ATDD), it helps PO, Developers & QA Engineers reach alignment regarding requirements, thus reducing time wasted due to requirement misunderstandings.

• TDD - Component Level: By writing Component Tests before coding, it helps Frontend & Backend Developers reach alignment regarding integration, thus reducing time wasted due to integration issues

Want to learn how? Read my TDD in Legacy Code series.