7 Engineering Practices to Adopt in an Agile Environment

Nowadays, there are so many engineering practices that a team could follow! As a Senior Scrum Master at PALO IT Hong Kong, I am writing this blog entry to name some of my favorites which we have implemented before (not in order):

1. Coding Standards

Setting a coding standard is very important to implement as soon as you start working with a project. Many teams and developers have neglected this part. We must always remember that a developer’s code will be treated most of the time as a requirements documentation. Imagine reading a document without a standard format. Hence, having a code as if it is only one person who coded would help the whole team to properly read the logic, thus reducing bugs and defects as well.

2. Unit Testing

It is a software development process in which the smallest testable parts of an application, called units, are individually and independently examined or checked for proper operation. We need to put a higher percentage on this than in GUI testing and Manual Testing. Unit testing is an integral part of the quality process.

3. Automated Testing

Another type of testing that most organizations would not want to invest in. Continuous delivery requires regular testing (regressions) that in turn requires a significant amount of time to complete. At first, automated testing would seem to require more time to build. This is the reality. But once you have set it, automated testing will make the team’s life easier and increase product confidence through rapid and measurable test executions. You can save money and time by investing into this practice.

4. Continuous Integration

This practice requires the developers to regularly check-in their codes at a common repository. Each code check-in is verified by an automatic build and unit/regression tests. It is highly recommended to check-in code on a daily basis. However, there are developers who do not want to do this, especially if they are working with scaled Agile teams or multiple teams. Based on my experience, developers are hesitant to check-in their codes having fear that it will affect and break others’ code. This practice is highly recommended for early detection of errors, rather than waiting when sprint is almost completed. By following this approach, developers will have more time to locate or find the cause. There is no guarantee that it will be solved immediately but at least, they will have more time to revert than waiting for the customer to see them. This practice also helps to ensure an up-to-date, working, and deployable product at all times.

5. Acceptance Testing

Is a type of test to ensure and confirm that business requirements are aligned with the output/deliverables.  In the traditional approach like in waterfall method, it is often performed on the latter part of the project on which usually issues are found late. Finding issues and bugs too late would usually require a lot of rework, worst there were cases that developers need to rewrite a big part of the code. In Agile, acceptance testing also requires acceptance criteria that will be used in determining whether the output meets the business requirements. However, in Agile, acceptance testing is being conducted more frequently than the traditional approach. It is usually performed every sprints and releases.

Based on my experience, which I believe a good practice, setting-up of the acceptance criteria is not only done by the Product Owners nor the Business Analysts. Usually, Product Owners will give the high-level overview and discuss them with the team. The team will then translate and may further elaborate or clarify the criteria, they will elaborate and write based on how they understand the requirements and must be re-validated by the Product Owners and/or Business Analysts (Note: it is highly recommended to be done prior software development). Each end of sprint, an acceptance test will be executed in line with the agreed criteria. Feedbacks will be gathered immediately. Issues that may have been found will be planned accordingly.  With this kind of approach, the team is closer to delivering what the stakeholders want. This approach doesn’t mean a 100% bug-free or issue-free but rather a good venue to know the issues quickly for faster resolution or for avoiding too much rework. Less rework means less expenses.

6. Short and small releases

Short and small releases means encouraging customers and stakeholders to have a rapid feedback loop. Having small releases allows us to manage the expectations of the customer more reliably. Customers can provide feedback ASAP, then the PO can plan it accordingly and the team can do the changes or fix it (if any) at an earlier stage. From personal experience, it is much quicker to develop and perform quality testing. However, implementing this approach is good as long as you have properly refined the epics and user stories. I strongly recommend the team to do an impact analysis to avoid repeated work caused by defects.

7. Time-boxing

It means allocating a fixed time period for each planned activities and/or Scrum ceremonies. Once time-boxing is strictly followed by the team, a good rhythm is being developed. It helps increase productivity of the team, reduce waste of time and promotes focus. Team should strictly follow the start and end of the schedule.



With over 8 years of experience in Agile field as a Scrum Master and around 7 years working as a Project Manager, Marivi is versatile in handling teams and projects, whichever methodology the client has chosen. She had a wide exposure in terms of client/customer interfacing, as well as handling issues at different levels. She managed to coach different groups and individuals, ensuring them to understand Agile and how to become a self-managing team.


Leave a Reply

Your email address will not be published. Required fields are marked *