Jira Tickets

Assign additional cost for generating a 'bug' type ticket, such that users & testers will have to resort to writing them down in the comment section of a larger, but only tangentially related feature ticket that had the misfortune of being 'in progress' at the time of discovery. Writing a comment instead of creating a proper bug ticket has the additional benefit of not being able to define a template (Steps to Reproduce), ensuring the bug description stays sufficiently vague. Proceed to track the status of this minor bug by adjusting the status of before mentioned larger work item, which by now has already been implemented. This latter point is important to ensure maximal confusion and contextual load required by the developers during daily standups. This serves the dual purpose of extending the standup to 30+ minutes, and ensuring your developers are well and truly tired before the day has even started.

Jira Boards

Create a highly customized board layout that requires at least half an hour of onboarding even for people that are familiar with Jira. Add little energy barriers here and there that only make it into the muscle-memory of daily users. A good example of this is to create label or epic based swimlanes. Choose a title for this swimlane that’s only somewhat similar to the actual label/epic you are filtering on, and DO NOT specify a default value. This will ensure that even if casual users create new tickets and somehow manage to fish them out of the backlog, they still end on the bottom of the screen in the second or the third swimlane, effectively hiding them on on any laptop screen. The benefits of this are twofold:

• Casual users will end up frustrated with the ticket creation process, leaving the sole responsibility of synchronising the state of the board with actual work being performed on the shoulders of the PM or scrum-master.
• Tickets will go unnoticed, leading to PMs creating duplicate tickets.

Agile Coaches

Skilled agile coaches have the ability to pinpoint small or large inefficiencies in your team's workflow, which comes at the risk of undoing some of the hard fought gains described above. They are therefore to be avoided at all costs. This may seem difficult, but there is a surprisingly easy trick. All you need to do is convince them that "this week doesn't quite work" and provide them with random deadlines or absence of team members. Leverage the fact that they are most likely not part of your actual team (because this is cross-team position) to slightly exaggerate these points. The only downside of this approach is that you have to keep this up week after week, so: consistency is key here. If you absolutely must plan a so-called 'retrospective', defer talking about any actionables until the last 15 minutes of the meeting (this should be easy, there should be many problems to discuss by now), and make sure to have a hard stop at the end of the meeting. If you are located in Europe this can be as easy as planning the meeting right before lunch.