CI-CD-QA - How the game goes
CI-CD-QA is a game with cards, for 4 to 5 participants:
A product owner
A Release Manager
A Security Officer
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:
The Product owner plays features requirements and bug reports
The release manager plays quality requirements
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...