I’ve worked on a few software projects over the years and many of them have been run within an Agile environment.
Agile is a software planning methodology where the work is carried out in small chunks, the requirements are listed in a backlog, which is worked on through these small chunks of development time, called sprints. At the end of a sprint a piece or pieces of work are delivered. This allows software teams to move quickly through the software requirements, be able to deliver software quickly and be able to handle changes in requirements as they go, become agile in the direction they move forward
This is the general theory, unfortunately from what I’ve seen over the years teams that have a Agile project management methodology, but who’s software is still built using a pre-Agile approach struggle to deliver what Agile promises.
The reasons for this are, if your software architecture is still very closely coupled, meaning one layer (the front-end) can not be fully developed in separation from the backend. It is extremely hard for the developers to make quick, fast changes because they run into numerous issues. They may have to wait for the backend team to make a change to an API in order to provide data that the front end needs, if there is no tests in place there isn’t the time for tests to be added or new tests to be written. This can lead to bugs coming into already delivered software and as the team moves forward in their Agile way, the time available to fix bugs and write tests gets less and less, leading to the possibility of the bug list growing and growing.
Implementing an Agile software project management approach is far easier than moving an large enterprise application to being able to be worked on in an Agile way. Arranging two week sprints, setting up a task list board and having a backlog and your ready to go is far easier than getting your software setup to be Agile, but it is possible.
The key to solving these problems is moving the architecture of the project to a more separated approach. Where each layer can be developed on independently, and doesn’t rely on another layer having a new piece of functionality in place before work can start on a new feature.
Dividing the work in a sprint between delivering features and updating the architecture of the application to be more separated allows, over time, the project to become more in line with an Agile approach. The developers can amend the application so the front end can run in separation from the backend. The UI layer can be written in separation from the front-end layer, allowing the UI to be mocked to show users how new features could look so feedback can be given earlier in the process. Leading the feedback being added into the sprints work load before all the other layers have implemented a feature.
Modern web tools can help
Using more modern web frameworks and tools can help. Using something like Angular to build just the front-end Logic, while the UI is built by another developer. This UI can be what is demonstrated to the end user in sprint planning when gathering requirements so the entire team knows what is expected. Using frameworks like NgRx and Nx workspaces allow the Angular developers to move the Angular code add to a consistent pattern that all the Angular developers on the team can follow, leading to a consistent structure allowing any of the Angular developers to work on any part of the application (especially if this is a large enterprise application) without much ramp up time. This can be extremely beneficial for distributed teams or teams with offshore developers.
Tools like NestJS or Node can allow the front-end team write mock endpoints which they can use to build from, while the backend team works on the real production ready APIs.
If the structure of the response is agreed upon, in sprint planning, then the mock APIs (which could return static Json) should be fine to get started building against.
Agile Can Work
Agile can really work as a way of managing the workload of a team, but without an architecture that can support quick code changes bugs will linger and more and more time will need to be spent on fixing issues.
An agile project management approach with a flexible approach to the codes structure will lead to applications that can be delivered quickly.
I like the Agile methodology, but we need to consider the structure of our existing code before going head first to a fully agile approach.