The Complete Guide to Agile Technical Practices

Ready to build your own custom software with a team that cares about you and your processes? We’re not code monkeys, we care about you. 

Get in touch. We don't byte

What are Agile technical practices?

Agile technical practices do what they say on the tin: they’re a set of techniques and methodologies used during Agile development to help you structure and streamline the process. They keep your code clean and bug-free, shorten time-to-market, and ensure productivity and team engagement.

Not using the right Agile technical practices won’t trigger the end of days, but it will make your business slower and less adaptable to the market's ever-changing needs. That’s why we’ve come up with the following breakdown of the most useful practices below. 

7 Agile technical practices distilled

Whether you’re building an MVP from scratch or adding new features to an existing enterprise app, the following Agile technical practices will enable your team and business to be truly agile:

1. Test-driven development. This test-first approach helps pick up code smells earlier. It allows Agile teams to express their intent in the form of unit tests (testing user stories) until all that’s left is clean code.

2. Automated testing. Allows quality assurance (QA) testers to build test cases that run automatically every time they introduce new code. Rather than manually running these tests, automation allows them to be more time efficient and keep quality high.

3. Continuous integration. Enables developers to work on the source code and integrate changes at least once a day, ensuring everyone is working on the most updated version. It simplifies edits and bug fixes and sidesteps ‘merge hell’.

4. Technical debt. Not a technical practice per se, but rather something to be aware of and manage.Any work practice that makes future development more difficult incurs technical debt, which needs to be managed using the relevant technical practices.

5. Refactoring. Think of it as tuning (not souping) up your code. It’s the practice of making the existing source code of a program cleaner and easier to understand without changing its functionality.  

6. Pair programming. An Agile technical practice that sees developers working in pairs to produce higher quality code, develop new functions more easily, and tackle difficult problems. 

7. Code review. The process a team goes through to check that a piece of code is error-free and meets all the requirements outlined in the task acceptance criteria. Creating a code review process, with a clear review checklist, is well worth the effort it takes to set up.

Automated testing

Automated testing in Agile is the practice of taking previously manual test cases and automating them. It simplifies your development workflow by taking care of repetitive tests, reducing human error, and saving time. 

3 Types of automated tests

Although much of testing in an Agile environment should be automated, sadly not everything can be. Here we highlight the main three contenders for automation.

1. Automated regression testing. If regression cases are stable and repeatable you should automate them. This leaves testers free to focus on more manual test coverage, and combine complex cases.

2. Automated acceptance testing. Acceptance tests are run until all issues are resolved and the application meets requirements. As these tests are repeatedly performed they are ripe for automation, meaning you catch serious problems and ensure customer satisfaction.

3. Automated unit testing (or test-driven development). Automation makes unit testing more predictable and easy to repeat. It introduces an “assembly line” approach to testing that doesn't get in the way of the creativity of the design, and provides flexibility when it comes to making changes in existing code.

5 Benefits of automated testing

The main advantages of automating are as follows:

1. It increases the efficiency and speed of iterative development.

2. It reduces costs in the long run by decreasing manual labor.

3. Overall accuracy is improved by reducing human error.

4. It increases reusability as the test cases can easily be reused.

5. Test coverage is amplified and parallel testing is easier. 

How to set up Agile automated testing in 5 steps

One does not simply walk into Agile automated testing. But following these 5 steps makes it a lot easier to set up: 

1. Prepare an Agile framework. Establish and build a clear automation framework before development begins.

2. Choose which test cases to automate. Not all test cases are right for automation so knowing which to automate from the start is essential.

3. Conduct parallel testing. With automation, testers can conduct various tests on different devices, operating systems, and browsers all at the same time.

4. Find the right automation tools. Taking time to choose the right automation tools will help to avoid waste so make sure they meet your testing needs and add value. 

5. Map the process. Agile places less focus on planning and more on flexibility, but it’s still important to map out your approach. 

Use the Agile test pyramid to map your process

Whether you opt for a test matrix, Kanban board, or simple document to map your automation process we recommend keeping in mind the Agile test pyramid:

This graphical strategy guide divides types of testing into three layers based on the ROI offered by testing each one, and for how long. As such it offers a clear guide on what testing to automate and outlines the sequence and frequency of those tests.

Test-driven development (TDD)

Ever tried to run before learning to walk? It doesn’t work out so well. Instead of starting to write complete code at the beginning of the Agile software development cycle, TDD is a technical practice that takes on a test-first, iterative approach. 

Test-driven development in Agile guarantees the code developers write is valid and makes the overall development and maintenance process more cost-efficient.

The 5-step TDD cycle 

Undertaking TDD can easily be broken down into the following steps:

1. Write a unit testfor a specific functionality or intention.

2. Run the test and expect it to fail because you haven’t written code for that function/intention (red).

3. Write only the needed code to meet the functionality, test it, and expect it to pass (green).

4. Refactor code to make it simpler and easier to maintain.

5. Repeat until you finish all features or software functions.

Test-driven development vs. Behavior-driven development

First there was The Beatles vs. The Stones. Then, Will Smith vs. Chris Rock. Now, Test-driven development vs Behavior-driven development. 

So what’s the difference?

Test-driven development (TDD)

TDD, as a technical practice, focuses on creating unit tests for all software requirements before coding. It tests the smaller parts of software functionality to evaluate code in isolation. If the functionality requirements change, engineers will need to rewrite the test cases, meaning adaptability is key.

It takes a more traditional approach to software testing, only involving the development team. As a consequence, TDD’s outcome is only relevant and understandable by programmers and other members of the development team.

Behavior-driven development (BDD)

BDD, on the other hand, begins with a conversation about how this software is supposed to work and how people are going to use it. It focuses on testing the end-to-end behavior of the application from the perspective of the end-user, meaning individual tests create less of a  domino effect.

Unlike TDD, BDD Is a more collaborative approach to testing. It involves product owners and other members of the dev team—but also key stakeholders and therefore needs to be more accessible to non-techies, using plain English for documentation.

5 TDD tools for Agile teams 

We know that creating unit tests can take time. Luckily there are test-driven development tools out there to help your team members code better, and faster. Below we list some of the best examples out there.

1. JUnit. An open-source TDD framework designed for programming in Java that contains libraries that help developers define and execute unit tests. The platform also supports testing data from integrated development environments (IDE) or command lines.

2. Mockito. Another Java framework that helps developers write certain types of tests. It’s a particularly user-friendly tool that also allows developers to write tests that follow the “arrange/act/assert” approach.

3. Jest. This tool is used for any JavaScript or TypeScript project. We recommend Jest because it allows writing tests in an approachable way and it shares test results quicker as several tests can be run simultaneously.

4. MochaJS.  Runs on Node.js but is also accessible through a web browser. It can also run asynchronous tests, alerts you when tests are running slow, and provides test coverage reports.

5. Pytest. An open-source testing framework that allows you to improve the quality of your Python programs. It stands out for its support for test code from command lines and its experienced and active community for support.

So, is TDD right for your project?

For all the benefits it offers, TDD isn’t a one-size-fits-all solution, and doing it all the time can become draining. Here’s when doing TDD is the best way to configure your Agile software development lifecycle:

1. When you have a project with clear requirements.

2. When you don’t have a pressing deadline.

3. When you’re launching a new feature.

4. When you’re working on greenfield projects.

5. When practicing with code katas.

Continuous integration (CI) 

This DevOps practice enables developers to work on the source code and integrate changes at least once a day, making sure everyone is working on the most updated version. 

Instead of developers working on their local environment for days and merging changes later, CI ensures everyone is singing from the same hymn sheet.

6 Benefits of continuous integration 

These 6 benefits of continuous integration in Agile will help give you the upper hand:

1. Eliminate merge hell. Working on source code changes daily means developers won’t have to deal with long merge issues and compiling errors.

2. Increase in-team communication. CI encourages team collaboration and alignment as developers are updating each other and integrating changes on a daily basis, avoiding large codebase deviations. 

3. Reduce risk levels. By frequently testing and integrating code in the repository the project is less likely to run into problems further down the line.

4. Increased quality. Developers can easily identify errors or get alerted if features aren’t passing the quality standards, meaning the final software version will be of higher quality. 

5. Reduce costs. CI saves money by reducing the time spent identifying bugs and code issues. 

6. Increase code coverage. It casts a wider net by running all the tests automatically in an organized way.

How to use continuous integration successfully

To integrate CI successfully we’ve put together the following best practices:

• Use a source code management (SCM) system. Multiple, disorganized files saved on different servers can cause merge hell, among many other problems. To avoid this, use an SCM system such as Git.

• Incorporate feature branches into the daily workflow. It creates copies of the code source where developers can test new features before adding them to the code base.

• Develop with pair programming. Allowing developers to work on big features together while integrating their code several times a day in a feature branch.

• Simplify communication and source code access. This is the beating heart of CI so make sure developers have an easy, open way to communicate and access source code. 

• Automate deployments to different environments. It’s a good idea to test your new features or changes before they get to a production environment. If this is automated and linked to your CI process, you’ll save on costs and benefit from running your entire test suite on each environment deployment.  

• Get help. If CI sounds too complex, you don’t have time to implement it, get help. Book consultation hours with experts or augment your team to help you find solutions.

Technical debt 

Whilst strictly speaking not a technical practice, technical debt is still something you need to keep an eye on. Just like a credit card, software development quickly accumulates technical debt over time, that you need to 'pay' back as you make improvements or changes to your code.

For example, if you rush code out the door to meet a deadline, it might create technical debt because the code isn’t quite up to quality. Once you’ve met the deadline, you'll need to go back and clean up the code, this work is the "interest" on your technical debt.

Challenges caused by technical debt

If technical debt in Agile projects gets out of control, it might lead to:

• Low-quality code. When developers cut corners to meet deadlines, they might not have time to write high-quality, well-organized code. Poor code design leads to a long list of technical debt that quickly snowballs into a bigger problem like making your developer team slower.

• Progress blockers and product backlog. If your team has to spend time fixing old code instead of working on new features, a large bottleneck of technical debt can halt progress.

• Poor user experience (caused by defects). You reap what you sow: if technical debt isn’t managed properly, it can lead to defects buried in the code. This results in a subpar product, leading to a poor user experience.

• Low team morale. If your team is constantly trying to stay on top of fixing defects instead of working on new features, it can lead to low morale. 

5 Ways to manage (and reduce) technical debt

Don’t worry, none of the challenges caused by technical debt are inevitable. Follow these steps to keep your project on track:

1. Refactor the source code. Clean up your code by refactoring it to prevent technical debt from building up.

2. Stay on top of technical debt metrics. Track your technical debt via metrics such as code quality, new bugs vs. old bugs, or code ownership.

3. Implement Agile practices. Using other technical practices in this guide, like TDD or pair programming, can help manage technical debt by making it easier to identify and fix issues early on.

4. Automate code reviews. This helps ensure that code meets the standards set by the team, and that it doesn't introduce any new bugs, thus limiting technical debt.

5. Follow the Agile Boy Scout Rule. Which says, "Always leave the code better than you found it." In other words, you should try to clean up any existing technical debt.

Refactoring 

Refactoring in Agile is like giving your code a spring clean, making the existing code of a program cleaner and more understandable, without changing its functionality. This allows the program to scale, and reduces further maintenance costs. 

5 Reasons to refactor

There are several reasons to apply refactoring as a technical practice in Agile, as it: 

1. Makes your code easier to modify and understand.

2. Reduces technical debt.

3. Saves time and money in the future.

4. Improves the performance of the application.

5. Improves your dev team velocity. 

4 refactoring techniques for Agile teams

Now you know the ‘why’, let’s look at the ‘how’. Here are 4 refactoring techniques we recommend you consider using:

1. Red-Green-Refactor. You say Red-Green-Refactor, I say TDD cycle. This is essentially another name for the TDD cycle detailed above.

2. Extract Method. This technique aims to reduce code duplications and increase readability. It allows you to “extract” a code fragment that can be grouped, move it into a separate function, and replace it with a new call to method.

3. Simplifying Methods. Focuses on simplifying the existing code and involves adjusting the interaction between classes.

4. Abstraction. Tries to remove repetitions and redundancies and is perfect for bigger projects. Changes and adjustments happen on a gradual basis, making it easy for programming to continue.

Pair programming 

In pair programming, two developers work together to tackle difficult problems and share knowledge across the team. Two heads are better than one, resulting in higher quality code, a more well-knit team, and faster product delivery rates.

Pair programming consists of two developers:

1. The driver shares the screen and writes the code.

2. The navigator provides direction and double-checks the work.

3 Benefits of pair programming 

Working together in this way brings about several benefits, such as: 

1. Improved code quality. Two engineers thinking about and working on the same issue means cleaner code and a more consistent codebase. 

2. Increased knowledge sharing and skill transfer. Knowledge and skills are continuously shared between programmers to better understand each other's thought processes.

3. Established common practices. Switching roles regularly helps establish a standard collection of practices across departments, and increases team cohesion. 

How does pair programming work?

When two developers work together, it should feel like Batman and Robin, not Tom and Jerry. Follow these steps to get the most out of pair programming in Agile: 

1. Plan for the session. Set an achievable goal, define the tasks, limit the duration of the session, and decide how often you’ll switch roles.

2. Track time. Set an alarm to remind you of when you need to switch or stop the session.

3. Engage in active discussion. The driver should talk the navigator through each step and ensure they’re engaged, while the navigator should make sure they stick to the plan.

4. Ask questions. When in doubt, ask and be open to creative solutions to learn and facilitate continuous improvement.

5. Review the session. This will enable you to establish what went right and what went wrong, improving future sessions.

Code review 

Think of code review as the beachcombing of Agile technical practices: it’s the process a team goes through to check that a piece of code is error-free and meets all the requirements outlined in the task acceptance criteria.

Beachcombing might sound dry but If code review processes aren’t in place, developers tend to do as they please, making the team less efficient and taking more time to launch features and fixes on the product. 

8 Benefits of code review

Code review in Agile is a highly beneficial technical practice because it:

1. Fixes bugs.

2. Improves code quality.

3. Sets the foundations for continuous improvement.

4. Reduces readability issues.

5. Shares knowledge within the team.

6. Produces a more cohesive and maintainable codebase.

7. Enhances security.

8. Prevents the final product from being delivered with unstable code.

How does code review work? 

Here at NaNLABS we always include code review in our projects, and that’s why we developed the following code review checklist:

• Apply Git practices (commit messages, squashed commits, feature branches, etc).

• Detect code bad smells.

• Ensure codebase reutilization.

• Detect dead or commented code. Avoid warnings.

• Make sure Pull Requests have test coverage.

• Smoke test the main flow of the proposed changes.

• Create a comment for each recommendation or change request.

• For duplicate change requests, repeat the comment in all places.

Which technical practice is right for your software design project?

Picking which technical practices to use for your next project is far from a red blue/blue pill situation. Each practice comes with its own set of specific qualities and whether they’ll be of benefit to the team depends on your budget, deadlines, and their experience working with them.

You also need to think about the requirements of the particular project and whether factors such as clean code, streamlined testing, or developing new features are a priority or not.

Once you’ve established the above, take a look at this chart and make an educated choice:

Agile software development case studies

If you’re still unsure about which Agile technical practices best suit your project, or you need help implementing them, it’s time to partner up with a software development agency. 

At NaNLABS, we’ve been developing in an Agile way for over 9 years. We’ve transformed the way our clients build software, and we can do that for your business too.

Here are two case studies where we assisted in Agile technical practice implementation.

An online retailer in need of team augmentation

This client reached out to NaNLABS because they had a small engineering team that couldn’t take any more work. They spent all of their time solving customer-facing problems that were caused by messy code and they didn’t have enough tech talent.

We used the following technical practices to solve these problems:

• Automation. We automated certain tasks to reduce the amount of manual and repetitive work when configuring new products or designs.

• Refactoring. We refactored their legacy e-commerce platform which was causing faulty orders and team burnout.

• Technical Debt. We paid off technical debt that our client’s engineering team didn’t have time to fix, and were constantly patching.

How we helped a security firm scale its enterprise software

Another client of ours is a Device Context-driven security firm traversing the IT/OT space across wired, wireless, and RF spectrum. 

It needed to improve and scale its platform to handle the large amounts of data required to detect, prevent, and remediate security issues. 

To help achieve this we implemented:

• Refactoring. The company wanted to create a new microservice architecture deployed in AWS infrastructure and orchestrated with Kubernetes. We refactored several modules to make sure the platform would function in the new architecture and ecosystem.  

• Continuous Integration. We used this DevOps technical practice for building and testing environment support throughout the project, increasing code coverage and making sure everyone was on the same page.
  

Ready to build your own custom software with a team that cares about you and your processes? We’re not code monkeys, we care about you. 

Get in touch. We don't byte