In our previous blog, we saw how Lean Discovery practices help us narrow our focus on an MVP and ensure we are building the right thing. Agile Delivery practices help us build the thing right. Moreover, nothing beats having a feature released to a subset of our user base and measuring specific metrics to determine feasibility, viability, and usability.
To accomplish that, our requirements, design, development, test, and deploy cycles have to take days and not months.
Mary and Tom Poppendieck, authors of Implementing Lean Software Development, ask “How long would it take your organization to deploy a change that involves just one single line of code? Do you do this on a repeatable, reliable basis?” Many organizations do not know the exact steps to get code into production, let alone the amount of time it takes. Using Agile Delivery practices make this measurement in minutes instead of weeks or months.
Automated Testing
Automation is key to delivering high-quality products continuously on a repeatable and reliable basis. Manual testing is not sustainable and manual deployments are error prone.
We have to start with SOLID coding principles to ensure we are building applications that are loosely coupled making then easier to test, modify, and maintain.
Applying Test-Driven Development ensures that our code is following these principles. Testing becomes the responsibility of the developer. When the developer is done coding, they are also done testing because they have been testing along the way verifying that their code works as intended. This ensures the application works based on the developers understanding of the requirements.
Acceptance Test Driven Development uses the same technique developers applied to the unit, integration, and system tests and applies them to acceptance tests. Here, testers start writing automated acceptance tests from day 1 and developers wire their completed code to the acceptance tests to verify that the code works as per the requirements and acceptance criteria. This ensures the application works as expected from a business perspective. Testing is no longer a phase but an ongoing activity throughout the project.
Continuous Integration
Teams should have a continuous integration server constantly integrating the code and running our comprehensive automated test suite composed of the unit tests, integration tests, and acceptance tests. The majority of these automated tests are written by the developers using code following the xUnit pattern as opposed to fancy expensive vendor tools. Manual testing by QA teams should be reserved for important exploratory testing and showcases.
Our CI server also runs automated code quality checks ensuring that the code complies with coding best practices.
Deployments to any environment should also be fully automated and using the same script for each environment.
The cloud allows our infrastructure to be flexible and provisioned on demand. Scaling and disaster recovery are automatically handled based on real time events. Provisioning should also be scripted so that our infrastructure is code and no longer requires us to manage hardware manually. This should apply for all of our environments including dev, test, stage, and prod.
With our testing and deployments fully automated our requirements, design, development, test, and deploy cycles can now take days or even hours or minutes. More importantly, this cycle is now repeatable and reliable.
Lean Discovery & Agile Delivery
As mentioned in the previous post, Lean Discovery and Agile Delivery are not phases. They are ongoing activities which enable hypothesis-driven development to allow us to quickly build and deliver a feature and then validate its viability, feasibility, and usability. Our hypothesis provides potential features to build (HDD), our features have acceptance criteria to run acceptance tests against (ATDD), and our code has behavioral expectations to run out unit/integration tests against (TDD). Our TDD cycle gives us feedback on the quality of our design and code, our ATDD cycle gives us feedback on our feature and our HDD cycle provides us with validated learning on our hypothesis thus verifying that we are building the right thing and we are building the thing right.
In our next blog, we will look at the cultural and mindset shift that organizations have to apply to enable these practices.
Agile Delivery Practices is the sixth in an 8-part series “Succeeding with Digital Service Delivery” from Excella Software Development Lead Fadi Stephan.
Part 1: What is Digital Service Delivery
Part 2: Top 4 Challenges with Implementing Digital Service Delivery
Part 3: Is Agile the Answer?
Part 4: MVP vs. MMF – What’s the Difference?
Part 5: Lean Discovery Practices
Part 6: Agile Delivery Practices
Part 7: A DevOps Mindset
Part 8: 10 Essentials for Success with Digital Service Delivery