In a previous post, we discussed a number of differences between Agile and Waterfall in software development projects. In this article, we would like to expand upon the benefits of Agile by demonstrating how we apply Agile practices at East Agile and how they benefit our clients. 

The core engineering practices at East Agile are (1) Test Driven Development (TDD) and Behavior Driven Development (BDD), (2) pair programming, and (3) Iterative Development. These are explained in detail below. 

1. Test-driven Development/ Behavior-Driven Development

Test Driven Development (TDD) and Behavior Driven Development (BDD) represent a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to meet the acceptance standards.  

Having automated tests that run continuously is a well established practice in professional software engineering. These tests make it easy to regularly add new features to an application over the course of years, even in production and with many users, without much increase in difficulty, cost, and effort. When working with full test coverage, engineers can confidently experiment with new code while tests reveal side effects and confirm nothing has been broken in the process. New features can be deployed quickly knowing that they are unlikely to break other parts depended upon by users. Good test coverage typically means that 80% to 100% of an application’s features and capabilities are being validated. This includes the visible front end, and the back end that operates behind the scenes. 

East Agile’s engineering practices go beyond a commitment to very high test coverage. Our engineers build these tests before and during their software development process. They are a core part of our software development process. Often they represent half code that we develop.  The way we develop test coverage we save money, we speed up development, we reduce defects, and we increase resilience in production. Done the wrong way, test coverage is a bureaucratic “check box” executed by a QA department. It is a cost tacked onto the end of a project just to say it was done. It is done by less qualified engineers who were not involved in the development process. They are allowed limited understanding of how the underlying application works or where its risks of failure are.  That is not the East Agile way. XP turns this problem on its head and makes it part of the solution.

The benefits of TDD/BDD can be broken down into the following:

• Cost-saving and time-saving: The way we write a test is directly related to the way we write the associated feature. Therefore, when we put writing test as the first step, our feature development process would take less time to be completed. Also, because test coverage exists while the feature is being developed, failures of those tests can help avoid mistakes including unexpected interactions with other code. Without existing test coverage, it may take days to write a new feature, only for fatal flaws to be discovered during subsequent QA. With existing test coverage from TDD, these flaws may be detected early in the process, and development can adjust with less time spent following a failed path.
• Maintainable, Flexible, Easily Extensible: Since testing in TDD is integrated into the development process at the most granular level, it is guaranteed that every standalone piece of logic can be tested – and therefore changed – immediately. At the end of the application development, there will exist many test cases. When a change is made to the application, all we need to do is run the existing test cases to see if the change has adversely impacted any other piece of the application. This removes all roadblocks from updating legacy applications and making changes within the current development. This has clear benefits for start-ups seeking rapid growth, published corporations who need to update legacy systems or companies that want to iterate through new business models. Changes are not a problem!  
• TDD enables engineers to better understand the requirements: The act of deciding how to write a test forces developers to clearly understand the feature’s requirements and can also detect flaws in the requirements themselves which helps to improve their definition. In TDD, code is never written without first writing a test. This results in more complete test coverage. Furthermore, the refactoring process ensures written code is as economical as possible. Hence, the codebase is reviewed (for refactoring opportunities) at any stage of the development lifecycle. Together, test coverage and refactoring enhance the code quality.
• Refactoring Encourages Improvements: The refactoring process central to TDD, ensures that developers constantly strengthen the codebase. TDD encourages refactoring when the test coverage is high. This prevents applications from growing dated and monolithic.
• Clean Interface: Because programmers write the test first, the APIs they produce are naturally written from an API-user perspective. These APIs are far easier to use than those written by developers more concerned with the internal workings of their packages.
• Executable Documentation: Since TDD require a test specification to be created, other developers can view the tests specification as a usage examples of how the code is going to work. Furthermore, tools can be used to generate the system documentation from the tests for non-developer.

2. Pair Programming

Pair programming (also known as paired programming) is an agile practice in which two developers work together at one workstation. One, the Driver, writes code while the other, the Observer reviews each line of code as it is typed in. The two programmers switch roles frequently.

While reviewing, the observer also considers the "strategic" direction of the work, coming up with ideas for improvements and addressing future problems. This allows the Driver to fully focus on the "tactical" aspects of completing the current tasks while the Observer provides a safety net and guide.

The benefits of pair-programming include: 

• Design Quality: Paired programming provides continuous collaboration. Every decision is validated by at least one other person – the other member of the pair. And two is better than one, we believe! A system with two developers can offer more diverse solutions to problems for two reasons: (1) each developer has their own experience to apply to the project; (2) they may assess information in different ways. In the attempt to share goals and plans, the programmers must overtly negotiate a shared course of action when a conflict arises between them. By doing so, they come up with more ways to solve a problem than one single programmer alone might do. This significantly improves the design quality of the program as it reduces the chances of a poor method being selected.
• Greater Scalability: It is easy to instantly double the size of the development team by splitting existing pair and adding new people to those pairs. This can be done with no disruption in development velocity. Even after doubling overall team size, each pair can always have a member with experience and knowledge of the existing code, allowing the new member to actively contribute to new feature development while learning all necessary details of the application without any delay to the project.
• Code Portability: Paired programming provides constant code review. We always have more than one person involved in every single line of code, and different combinations of people over time. This ensures that all code has been reviewed in terms of ease of understanding, clarity, transparency and adherence to best practices and standards. There should be no occurrences of code that only one single developer can understand.
• Reduced HR Risk. The “Bus Count” for every line of code is high. Because more than one person, and sometimes several people, have been involved in writing every line of code, there are fewer dependencies on the availability of any given developer. Developers can leave for vacation, illness, or to work on other projects, or even quit, and development can continue with others who were involved with writing any given feature. Bus Count is a simple way of assessing risk in a project, it asks “how many people are there whose loss would completely devastate a project if they were unexpectedly and completely removed from a project (i.e. hit by a bus).” With paired programming there should be no one person whose loss would be devastating to the software development process.
• Technology Pivots. Discrete shifts in technology can be accomplished without loss in productivity by swapping out one member of a pair with a new member with expertise in a newly required technology. For example, a project can move from a Python web development phase to an iOS tablet development phase by swapping in an iOS developer into a pair. There is no loss of understanding of the existing system, allowing more effective integration and avoiding loss of development continuity. Such pivots in technology can occur frequently depending on development and business priorities.
• Satisfaction: In an online survey of pair programmers, 96% of them stated that they enjoyed their work more than when they programmed alone. Additionally, 95% of the surveyed programmers stated that they were more confident in their solutions when they pair programmed. A correlation exists between satisfaction among developers and their confidence in the code i.e., pairs enjoy their work more because they are more confident in it.
• Learning: Knowledge is constantly shared between pair programmers, from tips on programming language rules to overall design skill. In "promiscuous pairing", each programmer communicates and works with all the other developers on the team rather than pairing only with one partner, which causes knowledge of the system to spread throughout the whole team. Pair programming allows the developers to examine their partner's code and provide feedback which is necessary to increase their own ability to develop monitoring mechanisms for their own learning activities.
• Team Building and communication: Pair programming allows team members to share problems and solutions quickly making them more likely to be more aligned with each other. This helps pair programmers to learn to communicate more easily. “This raises the communication bandwidth and frequency within the project, increasing overall information flow within the team.”
• Better Training: Pair programming provides a good opportunity to train new developers or new skills to a developer. Training can be achieved by pairing the trainee with a trainer. The trainee will easily pick up the needed skill set and knowledge while working in a real project. It would take additional resources to mentor a new developer in the single programmer mode.
• Flexible Project Allocation: The developers enjoy a flexible working environment where they can easily request to swap around projects without affecting the overall schedule. This would reduce the risk of a developer being stuck in a project for a long time and getting bored with his/her daily work.
• Compliance and Risk Management: Code is safer when it is developed in pairs. There are fewer opportunities for lazy or malicious actions. Rules about how code should be created, what sources or licenses may be used, or not used, are less easily broken. Inevitably agile methodologies require trust among all members of a team. But paired programming does add an element of trust but verify. This can be very important in highly sensitive or mission critical applications.

3. Iterative Development

Business Prioritized Emergent Development is the third pillar of East Agile’s software engineering practices. It does not require or even benefit from long preliminary plans or specification documents. It delivers business value and results quickly, and continuously. It adapts to changing circumstances and feedback effortlessly. It ensures transparency about progress or misunderstandings. It instills trust and confidence in clients. Pressure and anxiety can actually decline as a project moves closer to a release date.

We break up our development objectives into discrete user stories and features. For example, “As an enterprise user I want to be able to log in using SSO.” These are created during ideation phases, such as when an application is initially specified, when Product Owners or clients contemplate new ideas, and during weekly iteration planning sessions.  

We develop applications in repeated iterations that last about a week. They run from midweek to midweek, often with a deployment of features at the end of the iteration. We avoid deployments before non-work days so problems can be addressed during regular working hours. At the beginning of each week, the East Agile engineering team discusses what needs to be done with a client side Product Owner. The Product Owner is empowered to make decisions about what should be done and when, and importantly, can make business decisions about priorities. The engineering team provides an engineering estimation of the amount of relative effort required by each proposed feature. Armed with this estimation, the Product Owner decides what features to implement first (subject to the sequence being feasible from an engineering perspective). The key decision for the Product Owner is to decide what adds the greatest immediate business value. That should be done first. The engineering team might identify what will be the most challenging, what has the greatest engineering risk, and propose that that be done first, or soon, and definitely not last.

Engineering estimates are not done in terms of hours or days, but points which are deliberately abstract. This allows the estimates to focus on relative effort. This is the minimum information needed by a Product Owner to decide whether a feature is worth doing, or worth doing now, instead of something else that might be easier while adding as much or more business value.  Over time, the number of points delivered during each iteration can be measured. Indeed, this velocity of work can be precisely measured. Its standard deviation calculated. And it can be used to produce automatic forecasts in Pivotal Tracker of what can be done when from a calendar perspective. These estimates tend to be much more reliable than traditional estimates of person days because they are based on a metric, velocity, calculated over a few weeks, that reflects reality in all its complexity: the team’s actual ability in the specific circumstances and technology, group dynamics, and communication delays. These are not just well meaning promises. Armed with this velocity measurement, Product Owners can more reliably know the real dollar cost of features being discussed, the range of uncertainty that is likely, and be able to make the best possible financial forecasts.

Done this way, over time, anxiety declines. Because the riskiest features are done early. Because the features adding the greatest business value are implemented already. All that is left as work progresses are increasingly mundane features. They might take time, but no one has much concern that they can be done. They might be useful, but they are dispensable from a business perspective. As a deployment date approaches, the tasks are not challenging, and they can even be cut out if necessary to ensure a release happens on time. No worries.

Agile is a powerful tool for software development, not only providing benefits to the development team but also providing a number of important business benefits to the client. Agile helps our development team deal with many of the common project pitfalls in a more controlled manner. 

Are you convinced to work with an agile software development company now? Are you interested to learn more about Agile practices applied at our company? 

To learn more about the services and solutions that East Agile has for you, don’t hesitate to contact us here.