I would like to share with you a very simple and quite powerful technique for improving the rate at which work can be released, which was was introduced to me recently.

As I often stress, our goal as Agile practitioners should alway be to deliver the maximum value as early as possible for the lowest cost (maximise Return on Investment and minimise Cost of Delivery).

Colyn Forsyth, a DevOps and Agile SME, shared this explanation with me and kindly agreed that I could pass the information on.

RATS and CATS

Created by Colin FORSYTH

The Story of CATS and RATS:

Cats and Rats is a simple way for teams to look at each development request and identify if they can release the change as soon as the development has passed all integration stages and has been approved to be released by the Product Owner (Business Stakeholders).

RAT’s (Release Any Time Stories)

• Rats are small
• Rats don’t have dependencies
• Rats are well understood
• You know what Rats are going to do
• Because Rats don’t have dependencies you can keep Rats together without to much risk (though occassionally they will fight.)
• Cats and rats don’t get on, try to keep them apart.
• You don’t want to many Rats hanging around so get rid of them as soon as you can otherwise your Rats may become Cats.
• Low Risk
• No dependancies or dependencies you can control.
• Easy to identify who will test and approve.
• Testing requirements are understood and can be managed easily by the team.
• Easy to deploy. (Automatically)

CATS (Complex and Troublesome Stories)

• Cats are fickle, they are likely to do the unexpected
• You can never be sure about Cats
• You get Cats organised and then they go off and do their own thing.
• You cannot control a cat.
• The more cats you have the more complex it is to get things done.
• The more cats you have the more likely something will go wrong.
• Cats do not get on together.
• Medium to High Risk
• Dependencies means you may have issues releasing if dependencies not resolved.
• End user sign off may be complex to achieve.
• Stories requirements are complex, and the team maybe concerned about delivering the story on time because there is uncertainty that everything is not known.
• You may have E2E testing across multiple systems,
• Releasing is complex and may involve manual processes or co-ordination of releasing stories from different teams.

What you need to do

• Define what are RATS for your team.
• label your stores as RATS
• If your RAT has dependencies make sure you are able to manage them so they do not stop you from being able to deploy. If it does stop you the Stories a CAT.
• RATS must have clear requirements that are fully understood by all members of the team. If there is dubiety and uncertainty the RATS either a CAT or its not ready to work on.
• Define what are CATS for your team.
• label your stories as CATS
• Try to Keep your CATS apart deploy each CAT separately.
• Where you have dependencies you need to take more care and monitor your CATS closely.
• If your CAT has uncertainties, try breaking it down into smaller CATS, move the uncertainty into 1 CAT so you can start working on the other.(Maybe part of a CAT becomes a RAT!)

 

CATS and RATS Strategies

There are a variety of different strategies you can apply to working more effectively and these are defined below, adopt the ones you think will work best for your team.

Get Rid of RATS

• Automate your Pipeline so you can deploy RATS quickly and easily.
• You can start deploying RATS in batches, but keep the batches small, (to stop fights happening) .
• Don’t accept RATS that come along at the last moment that don’t meet your definition of done. The quality of what you deliver is vital.
• All RATS must be properly tested before being deployed.
• If a RATS fails a test in SIT or UAT raise a bug and link the BUG to the story.
• If RATS have BUGS in UAT they don’t get deployed. No exceptions.
• As soon as a RATS have passed all test get the Business to approve it for deployment.
• If RATS create BUGS on the production environment review and identify how to improve your process so it doesn’t happen again.
• Keep a constant flow of RATS being deployed, work at a sustainable pace.
• Goal to aim for: Deploy Rats Regularly – Number of Rats deployed to production per week increasing.
• Goal to aim for: Fewer Bugs found in UAT versus SIT. Overtime a downward trend in bugs found in SIT and UAT.
• Goal to aim for: Production Bugs linked to RATS to be flat and close to zero.
• Goal to aim for: :%age of Production bugs to RATS deployed falling.

 

A RAT a day keeps the CATS away

• Do not keep RATS hanging around and waiting to be deployed. The more RATS you gather the more likely something will go wrong.
• A gathering of RATS will eventually turn into CATS.
• If something goes wrong you only impact 1 or to changes if you are releasing fewer RATS at a time.
• Ask yourself why are you gathering RATS,
• is it a technical issue that you can’t deploy the RATS one by one because it takes too much time and you don’t have people available – look to automate
• Is it because the business don’t have the time to test and approve – work with the Product Owner to get closer business involvement, show them the advantages of releasing less but more often..
• You can’t release the change because of dependencies – you have CATS not RATS, have a look at the Changing CATS to RATS strategy,
• Goals to aim for: Increase release frequency, more releases with fewer RATS – Metric- trend of average number of RATS per release should be reducing and number of releases increasing..

 

Change CATS to RATS

You do not want CATS so identify ways of converting CATS into RATS:

• Remove dependencies work together and release in 1 process.
• Why is it a CAT? CAT is big and complex, so split it until it’s a collection of RATS and release these regularly.
• Business doesn’t want all the RATS until a future date – – work with the business to release the RATS that can be released early. (also: See Hide RATS strategy…)
• It’s a CAT because E2E testing needs to be done to make sure other applications don’t get broken – Improve testing competencies – set up testing contracts to reduce risk and improve early testing capabilities, invest in e2e environment availability, look at building synthetic data test repositories and automate e2e testing capabilities.
• e2e testing a small change is much easier to test than a big complex change. Work with the business to identify how to do incremental changes, introducing gradual changes.
• Goals to aim for: No of e2e tests run per week increasing
• Goals to aim for: No of e2e bugs found per week decreasing
• Goals to aim for : Ratio of CATS to RATS per month declining over time.

 

Hide RATS till you need them

• RATS can be hidden by designing them so they are not active when they are deployed or provided to a limited number of users.
• Deploy RATS but de-activate them till they are needed – They must be kept active on all DEV, SIT and UAT environments
• Deploy RATS but only give them to a limited number of users, and expand the user community slowly providing no issues found.
• Deploy RATS on a node where only selected users are directed and monitor for issues (mainly web based applications).

 

I hope you find this useful, as I did. I would like to thank Colin FORSYTH for allowing me to share this with you!

Wishing you a wonderful and Agile day 🙂

 

Christopher William Young
Managing Director
? finaplana AG
Maximizing business value through organizational agility
www.finaplana.ch

Upcoming courses: https://aegility.ch/courses/

Join our Zürich Meetup group: https://www.meetup.com/Agile-Die-nachste-Entwicklungsstufe/
Member of the Swiss Agile Association: http://www.swissagileassociation.org
XSCALE Alliance Steward – Switzerland: http://www.xscalealliance.org