Agile explainer

In a recent LinkedIn post, I talked about the use of “Agile” in software delivery, it is used by teams to deliver value incrementally, with features added or updated with each iteration. Done right, it increases development productivity and reduces the risk of finding issues in production – which can be damaging.

One of the biggest changes required to achieve agility is a change in mindset. Let me try to break it down, I’m going to remain framework and tool agnostic here.

In the context of this post:

• Change is the piece of work to be delivered.
• End user is a representative of your business for whom the change is being developed.
• DevOps is a term used to describe the processes used to automate the progress of a change from development to production.

Software quality becomes the responsibility of everyone in the team, they are expected to be self-sufficient, testing as soon as a change is ready. To do this successfully at the fast pace usually associated with Agile, is challenging but achievable.

The best place to start is breaking your requirements down into small, testable tasks, agreed by developers, testers and end users. It is important to include the latter as they will have the best idea of what is required, and are best placed to answer questions from other members of the team.

Developers can then write unit tests along with the code itself, these tests prove the new code does what is expected to do with defined inputs and expected outputs. Unit tests are run in isolation and do not test interactions with other components.

Using DevOps, the Unit tests can be automatically run when the developer commits their change to the repository, where all code is stored under version control. If the test fails then the developer, and potentially other team members will be alerted. It is very bad practice to leave a “broken commit” because it could easily impact other components.

Whilst the developer is writing the code and unit tests, a Quality Engineer can create tests for the change running along with other components. These might be (not an exhaustive list):

• Regression tests that check existing functionality is not impacted by the change.
• User interface tests that check new UI changes. These do not need to test all data permutations, just functionality. Unit tests should cover these.
• Integration testing, that checks where a change passes data to or receives data from another component. Again, these tests do not need to be exhaustive, they merely confirm that all expected data is passed between components.

DevOps processes can automatically run each of the above tests, building test environments and creating data as appropriate, and “tearing down” or removing them once finished with.

When enough changes have completed testing by Developers and QA, DevOps can spin up a test environment for Acceptance Testing. This is where your End user and other stakeholders determine whether the change is fit for purpose.

The final step in the journey of a change is deployment to your production environment. All achieved using Agile orchestrated by DevOps.

I may have over-simplified things here, and the roles of Quality & DevOps engineers are very skill, but hopefully I have demonstrated that done right, Agility is available to everyone.

Contact us and we can discuss how to you can implement Agile in your org. You’re never too small or too early to do this, in fact the earlier you are on your development journey, the easier it will be.

If you want to learn more about Agile, the visit the Agile Manifesto page and read about the 4 values and 12 principles that were agreed in 2001.

#agile #devops #softwarequality