Extreme Programming (Part Two): Test-Driven Development and Small-Batch Development
By: Jeffrey Lin
Welcome back to a three-part series on Extreme Programming (XP), where different members of Symbiont’s mortgage team discuss our development methodology from distinct perspectives: business owner, product manager and engineer. In part one, my colleague Alex Bennett shares his perspective on leading an XP team, the economics of pair/mob programming, and how XP practices can foster accountability across a team.
As a product manager on Symbiont’s mortgage team, I will provide my perspective on XP engineering principles in the second installment of the series. My goal is to cover two core tenants of XP: test-driven development (TDD) and small-batch development. More notably, I will discuss how these tenants have brought about more effective ways to gather requirements and project plan for our team.
Test-driven development
Test-driven development (TDD) is a results-based method of development, where engineers write software to test the outcomes of an implementation as the first step of developing any feature. Tests are meant to be simple and establish a clear scope for the development ahead. Aside from being a well-defined goalpost, tests can be executed against the code implementation at any time to validate if the success criteria have been met.
Requirements can be test-driven and exist as true living documentation
Our team has extended test-driven practices beyond engineers and further upstream into requirements gathering with subject matter experts (SMEs) and business analysts. Entrusting SMEs to define requirements eliminates room for interpreting the software’s expected outcome. Once they’re defined, requirements can be written in the form of executable tests rather than as unactionable abstracts. Tests, unlike written documentation, can be run to confirm the validity of code. The results of each test represent the true state of the application at that given point in time. These tests become true, living documentation. This practice is known in behavior-driven design as ‘specification by example.’ Although not endorsed directly by XP, ‘specification by example’ is a natural extension of test-driven development.
Overcoming the hurdle of coding with non-technical SMEs and business analysts
While our team believes it is essential to include SMEs and business analysts in the process of defining requirements, there is a high barrier to entry for writing tests with code. To overcome this hurdle and simplify the process, Symbiont uses FitNesse, an open-source software that abstracts code away and allows non-technical people to specify requirements in the form of tests. Built as a wiki, FitNesse is a repository of documentation where each page can also be made into an automated test script. Writing tests is an intuitive process, where users express requirements as inputs and outputs in tables. Here are two simple examples:
The engineering team starts with a “failing” FitNesse test. Their goal is to pass the test for feature completion, similar to the way unit tests are structured in TDD. Each time new code is deployed, the entire test suite is run automatically, and any failed tests will cause the breaking change to rollback.
Our team uses FitNesse as the single source of truth for requirement specifications. This commitment extends to the SMEs on our project. The benefits of ‘specification by example’ are diminished if the SMEs do not ensure requirements are reliable and up-to-date. So far, we have mapped out our application’s taxonomy and created hundreds of tests. FitNesse acts as the medium of communication for day-to-day collaboration between engineers, product and SMEs. During a cross-functional working session, SMEs can view the current state of the application and provide requirements changes directly in the tests without needing to dig into code or perform manual tests. Immediately after, engineers can leverage these tests for development without needing to interpret requirements from written specifications.
Small-Batch Development
Using team experimentation to validate complex products
The objective of small-batch development is splitting features into digestible pieces, which then allows for quicker development and feedback loops. Our product demands a highly collaborative environment across disciplines to fully utilize the properties of a blockchain and solve business needs within the mortgage space. The XP model provides a framework where features are kept lightweight to ensure more user engagement. The constant interaction with the business domain equips the engineering team to identify new ways of leveraging our blockchain platform. Earlier this year, our team created a lightweight demo with three end-to-end user journeys to validate with prospective clients and partners. Instead of building fully featured user journeys, we built just enough to meet our objective. Each user journey was pared down with SMEs to the minimum fidelity required for a demo. This allowed us to validate our value proposition without a fully functional application.
Developing to inform planning
Beyond the demo, Symbiont has extended small-batch development to guide long-term project planning by mapping out the rest of the application. Building small and across features has helped surface blindspots and previously unknown complexities. Where there are known uncertainties, the team uses development spikes, or time-boxed research efforts to help gain understanding. As the team gains expertise throughout the application, we can plan longer-term and make more informed decisions. This experimental process of small-batch development may seem counterintuitive, especially when working on a project with a fixed deadline. Instead of investing heavily in upfront planning, project plans following XP evolve to address newly identified priorities and delivery risks based on prior development efforts. Product development and planning become interwoven and are done throughout the project.
Research-based approach
You might be asking yourself: Why does Symbiont practice XP? Critics of XP point to the infrastructure and cultural investments required to sustain an XP team. Put simply, we use this methodology because it works. The synergies of small batch development and results-based development primes our team for solving complex multi-party workflows. Our decision is also grounded in evidence. Recent research , conducted between 2013 and 2017 and spanning 2,000 organizations, showed that practicing lean product management (i.e small-batch development, short client feedback loops, and authorized engineering engagement) improved software delivery. Nicole Forsgren, Jez Humble and Gene Kim, the authors of “Accelerate: Building and Scaling High Performing Technology Organization,” observed that these lean practices predicted higher organizational performance as measured by customer satisfaction, profitability and market share.
XP can be used as a starting point and framework to address projects with conditions of uncertainty. The framework, which promotes collective experimentation, requires deep commitment and trust from the entire team. Everyone, including SMEs and users, provide feedback on your application. To reap benefits from XP, it is essential to cultivate a very specific environment and culture. By adopting XP’s engineering principles, we have established new practices in gathering requirements and planning. This allows us to best solve the problems that exist within the mortgage market with Symbiont’s enterprise blockchain technology.
Originally published at https://symbiont.io on December 5, 2019.
