– Back to the Agile Practice Guide (all) –

The Agile Core Practices

There are certain core Agile practices within Agile that can be used regardless of whether you call yourself an Agile team or not.  Knowing these core practices is also a great way to get a deeper understanding of Agile as an approach.

One of the best places to update your skills in Agile is from the Agile Practice Guide, by the Project Management Institute and Agile Alliance. This one in particular is Continuous Integration and other execution practices.

Check it out!

Continuous Integration and other execution practices

As we’ve seen, Agile is the combination of an iterative approach – where we’re iterating and improving our product – and also an incremental approach where we’re delivering something at the end of those iterations.

We’re delivering something that a customer can see, feel, and touch and just to check whether we’re on the right track or not, and that the requirements are being met. Delivery of a product increment or a feature that is usable requires reliable, working integrated software at the end of each of these sprints of between two to four weeks. Continuous integration addresses this challenge by merging all of the changes made to the software and integrating all changed components regularly, at least once a day. That means configuration management, compilation, software build, deployment and testing are all wrapped into a single automated and repeatable process.

Since developers integrate their work constantly and build constantly and test constantly, defects in the code are detected much more quickly. And that’s the real key, we’re gaining that feedback on whether everything is working in the way that we want it to be working by integrating all of the different changes that we’ve made and putting them into the the one test environment or the one working environment, and then running an automated test just to see if nothing has broken by combining all of these changes.

By doing it daily we’re getting fast feedback on a regular basis so by the time the end of the the sprint or the iteration rolls around, we’ve been doing this every day so we really know if something is going to be working for the end of that sprint.

Other Execution Practices

Now there are other execution practices as well. First of all we’ve got “testing at all levels“, which is where we apply end-to-end testing and unit testing. Unit testing is testing an individual story or feature – a small piece. You develop the code and then you unit test that particular feature. End-to-end is where we have many different features and we want to make sure that the overall result is tested, usually by one of the users as well.

In an agile team we have a preference for automated tests, so can we automate those unit tests using Selenium or in the code itself, or can we automate those regression tests and run them daily as part of our continuous integration when we’re putting all of our changes up into the one environment.

We also have acceptance test-driven development which is where we’re creating end-to-end user acceptance tests by feature as a team. That means everyone gets together – the Business Owner for example (this is the whole team approach), we’ve got the developer, we’ve got the tester and they all have an input into the acceptance criteria so that we know what the definition of done for that particular feature is.

Then we’re creating these reusable regression tests once that goes in at the end of the Sprint or the end of the iteration. We can reuse those tests and make sure that nothing is broken in the future as well.

We’ve also got test-driven development or TDD, and Behavior Driven Development which is BDD.

Behavior driven development is your “Given, When, Then” scenarios. This is usually part of an automated test framework such as Cucumber when you’re doing automated tests but given a certain scenario – “when this happens”, “then I want that to happen”. It’s just a way of writing that test from a business or a customer point of view so that you’re really clear on that acceptance criteria.

Test-driven development is where we write the test first, then we write the code, and then ultimately the test should pass after that. When we test first obviously the test should fail because there’s no code to support it – then we actually write the code to do what we want it to do and then when we test again it should pass. That’s test-driven development.

Lastly we have spikes as well. Spikes are time-boxed research or experiments. This is where we need to estimate more on a card, figure out the acceptance criteria definition, learning some critical technical information or functional element. Really doing that research where maybe just the normal work day is not enough, we need to set aside some time, gather the resources and delve into a problem and problem solve and that’s where a spike comes in.

And that is Continuous Integration and other execution practices.

– David McLachlan

– Back to the Agile Practice Guide (all) –

Get the Leadership Card Deck or the Five Minute Lean Book:

View All The Leadership Cards (48)

- or - Have the Leadership Cards delivered for your next meeting

 

Want to learn about Lean? Get the book "Five Minute Lean", by David McLachlan - a wonderful book that blends teaching of the tools, culture and philosophy of traditional Lean with a modern-day Lean parable. You can get the whole book on Amazon here and enjoy your own copy.