top of page
IMG_9020 - whitebalance.JPG

CI-CD-QA - How the game goes

CI-CD-QA is a game with cards, for 4 to 5 participants:

Paul.png
Debby.png
Dave.png
Steve.png
Rachel.png

A product owner

Paul

A Release Manager

Rachel

A Security Officer

Steve

1 or 2 developers

Dave and/or Debby

The participants are assigned to one of the above roles by blindly picking a persona card.

The goal of the game is to play all your cards as quickly as possible. You start with 7 cards. But... Each player has a specific type of cards to play, corresponding to their role. The product owner, release manager and ISO need to put their requirements on the table:

feature requirement could 1.png
bug report high 1.png

The Product owner plays features requirements and bug reports

quality requirement - final go-no go.png

The release manager plays quality requirements

Security requirement - PEN-test.png

The ISO plays security related requitements

The developers need to implement these requirements (the numbers on the cards have no meaning and there is no specific implementation card for each individual requirement, only per stakeholder):

The game starts with the PO that has to put a first requirement card on the table. The order of the other players does not matter. The developers need to put a corresponding implementation card on top of the requirement card to implement it.

 

If a player cannot play a card corresponding their role, they need to swap the cards they cannot use:

  • take all the cards from their hand they cannot use and put them at the bottom of the stack

  • take an equal number of new card from the stack

  • if you can play a card you picked from the stack, you can already do so, otherwise you need to wait for the next round to swap cards again

This is the board on TableTopia. The physical board looks similar but has slight differences.

The game ends when the first player has played all their cards. For the security officer this is preferably the penetration test, for the release manager the go/no go meeting. And then you see what has been delivered:

  • which features were implemented?

  • are there still unfixed bugs?

  • what security requirements are implemented?

  • what is the quality of the release?

Can you do better?

What is described above, is the first round, where participants experience what it is like when everyone sticks to their positions, firing requirements at the development team. When seeing it like this, it is quite confronting, but in larger organizations it is probably reality. So what can we do to improve the situation? That is exactly the goal of round 2:

  • The product owner remains responsible for putting feature requirements and bug reports on the table

  • The security and the release management responsibilities are now taken up by the development team themselves

    • Sanjiv will be added as security champion

    • Queenie will be QA engineer of the team

  • This means that these roles can put their requirements on the table, but at the same time, as developers, also contribute to implementing the requirements that are on the table

  • The last security requirement to be put on the table should still be the penetration test

  • The last quality requirement to be put on the table should still be the go/no go meeting

The end goal remains: creating value that is secure and of high quality. Now see what the difference is...

Steve.png
Rachel.png
right arrow.png
right arrow.png
bottom of page