insight How do you make your software development project a success? Make it Agile, is the popular answer. And many methodologies exist that will help you do that, such as Scrum and Kanban. But those methodologies usually focus on the work process, and not so much on the technical aspects of a software project. However, these technical aspects can impact your agility in a big way. What are these technical aspects, and how do they impact your software development project? Let’s find out.
In this article, I’ll describe the following technical practices that will greatly influence the agility of your project:rnu003culu003ern tu003cliu003eCoding standardsu003c/liu003ern tu003cliu003eCollective code ownershipu003c/liu003ern tu003cliu003eSimplicityu003c/liu003ern tu003cliu003eContinuous integration / continuous deploymentu003c/liu003ern tu003cliu003eTest-driven developmentu003c/liu003ern tu003cliu003eRefactoringu003c/liu003ern tu003cliu003eClean architectureu003c/liu003ernu003c/ulu003ernBut before we can understand how these practices impact your agility, we need to be clear about what we mean be “Agile”.
Collective code ownership
This practice states that everybody on the team can contribute to any part of the code. There is no part of the code that is ‘owned’ by certain individuals and can only be changed by them. Of course, when the team and the codebase is sufficiently large, some people will have better knowledge of certain parts of the system than others. But that should never preclude anyone from contributing code to any part of the system. This encourages everyone to apply fixes or refactorings u003cemu003ewhereveru003c/emu003e they feel it is necessary, which improves the quality of the code base over time. It also helps to avoid knowledge silos, which can be a real problem when a knowledgeable developer suddenly leaves the team.rnrnIt helps to have a solid suite of automated unit tests and integration tests. You will be much more comfortable changing or refactoring a piece of code that you are not very familiar with if that code is covered by tests. That way, you can safely try out your changes and if they happen to break anything, the tests will tell you.rnrnHow does this practice improve agility? Since every member of the team can work on any new feature, work will not be held up because a particular team member is not available. And no individual developer will ever become a bottleneck in the work process because the work can be distributed to all team members.
Continuous integration / continuous deployment
This is a very broad topic, which has become a separate discipline in its own right (DevOps Engineer, anyone?). However, there are certain basic practices that everyone on the development team can follow. It all starts with checking in your code into a shared code repository, preferably multiple times per day. This is basic practice nowadays of course, but important, nonetheless. Next, you might want to run certain checks whenever the repository is updated. This can be as simple as checking that the code still compiles. But also as elaborate as spinning up an entire app ecosystem and running all kinds of automated integration tests. And everything in between. The goal of all this is to provide u003cstrongu003erapid feedbacku003c/strongu003e when something is wrong. The sooner you detect an issue in your code, the cheaper it is to fix. So having this kind of rapid feedback saves you time, money and potentially a lot of frustration.rnrnApart from continuous integration, you might want to set up continuous deployment as well. In most Agile software projects, you’ll want to release early and release often. Maybe not to the final “production” environment, but then at least to some test or staging area. And doing anything over and over again means that you’ll want to automate it! So a basic strategy would be to have a deployment script that you can run against your code repository. One click to run the script, and it will automatically grab the code, build the software, and deploy it to the appropriate environment. More advanced strategies might involve running tests, deploying automatically whenever anything changes, or deploying to multiple environments based on certain criteria. Again, rapid feedback is key here: the sooner your stakeholders can evaluate new features, the better. The sooner customers can use it (and pay for it!), the better.
Refactoring
Refactoring means to change the u003cemu003estructureu003c/emu003e of your code, without changing the u003cemu003ebehavioru003c/emu003e of your code. This practice is crucial to maintain a codebase that is simple and easy to work with. A project always starts out small and simple, and in the beginning, it takes little effort to understand everything. If you keep on adding features without any regard for the quality of the code, it quickly becomes a hard to maintain mess. You should continuously refactor to remove duplication and improve the structure of the code, so that it remains as simple as it can be.rnrnAs we have seen before, this practice ties in closely with that of Test-Driven Development. Having a good test suite gives you the confidence to refactor safely, without risk of breaking existing functionality.rnrnThis practice also closely relates to the practice of Simplicity. If you refactor complex code to make it simple, you make the code easier to understand, easier to change, so you improve your agility.
If you are a software developer, I hope these practices resonate with you, and perhaps inspire you to study some of these topics more deeply. Are there any practices I have missed that you feel should definitely be on this list?rnrnIf you are a Scrum Master or Agile Coach without a technical background, I hope this article gives you a better grasp on the technical side of Agile software development. I think it helps the entire team when techies have a good grasp of the basic of Agile methods, just as much as it helps when Scrum Masters or Agile Coaches understand the basic practices of software development.