In the Lean Discovery blog we saw how these 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 true validated learning than 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.
Marry 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?”
Marry and Tom Poppendieck
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.
Automation is key for 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 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.
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.
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 it’s 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 our 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 features 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.
Also check out the Lean Discovery, Agile Delivery, and DevOps Mindset presentation slides here as well as the entire Digital Service Delivery blog series:
