Agile Software Delivery That Works

An introduction to how software was delivered, how it is delivered now and the challenges faced in the transition.

The Old Way

It wasn't that long ago that the most common method of delivering software was through what is known as V-model or Waterfall which started with Requirements Design where all the requirements are identified and documented. Then came the System Design where engineers figure out how those requirements are met, after that was High-Level Design where all the modules that would make up the application are identified along with their interfaces so they could interact with each other. Then there was the Low-Level Design phase where each module was actually designed to produce a low-level document in pseudocode.

Finally, testing could begin firstly with Unit Tests to validate low-level design, then Integration Tests to validate high-level design then System Tests to validate System design and finally User Acceptance Tests to validate requirements design.

Other steps to consider are the non-functional tests which covered things like server speed and security testing which should really also be included in the requirements design. The testing for these elements should also be ongoing even in the traditional style of software delivery. This method of delivering software typically took years before it could be used by the end customer was difficult to change and involved a great deal of capital before the benefits were felt.

The New Way

Now of course everyone is trying to implement some form of agile delivery process the foundation of which is to go through the above described stages as quickly as possible multiple times rather than just once. Starting with delivering what is known as a Minimum Viable Product (MVP) which is the smallest useful solution possible then iterating through the process again over a period of about 2 weeks and slowly extending the functionality of the initial MVP. Then going through this process again potentially forever while continuing to add functionality ad make other changes on an ongoing basis.

While a great deal of software was delivered through the V-Model and it is still useful in many scenarios it was not the best way to deliver software solutions in a world where things need to happen quickly to take advantage of opportunities that presented themselves, stop the competition from taking away pieces of your business because you couldn't make the necessary changes quickly enough to your systems and finally businesses needed software solutions they can adapt and change because they are not quite sure what the final solution would look like or because they need to experiment and make regular changes depending on what their users want.

Current Challenges

One of the biggest challenges with this transition taking place with how software is delivered has to do with the fact that strictly speaking there is no distinction between developers and testers anymore. They're all known as developers.

Team members need to be cross-functional meaning they not only write code but also execute system and integration tests. This is because earlier on in the development cycle (Sprint) there is a high emphasis on writing code and later on testing code, at the same time there is some preparation required before test execution begins which runs parallel with the initial code development at the beginning of the sprint. This becomes even more critical when it is expected that test automation scripts are ready to test the code developed in sprint which is usually possible with API tests but extremely difficult with UI tests.

Another issue is the size of the team which still tend to be large when there should be a max size of 9 with a optimum being 7. With larger projects there will be multiple teams that coordinate activities through a process called Scrum of Scrums. The problems with large team sizes stems from the fact that scrum teams are supposed to be self organising and self managed so the larger the team the more difficult it is to manage and organise.

There are inherent problems with redesigning systems to increase its capacity, extend its functionality while ensuring it continues to meet current requirements and is still secure. The ability to do this has been made so much easier as monolithic applications were basically broken down into smaller applications i.e. microservices resulting in compartmentalized applications that work independently. While a solution with a microservice architecture is easier to update and make changes to it is ultimatly more complicated to manage. To understandsome of the complexities you can refer to this article on what a microservices architecture looks like.    

Conclusion

Ultimatly delivering software in an agile way provides the opportunity to tweak the process to suit how your organisation works but it will also required some changes by the organisation as well. The agile process is also being applied across the organisation and not just to software delivery but also to Human Resources, Administration, Customer Services and much more.

The Agile Manifesto currently is the defacto guide of how the process can be used for ultimate success. There is so much more to consider than whats in this article but it does give an insight into some of the challenges faced and different teams/organisations will be facing different issues depending on how they implement agile. While it does provide an opportunity to give your organisation that competitive edge it is complicated and difficult to implement particularly with large organisations that have multiple moving parts that need to work together.