A collection of experiences / best practices / habits to work more effectively (so to increase your velocity), from people like Henrik Kniberg, Stephen Covey, Robert C. Martin, Daniel Pink, Kent Beck, Alistair Cockburn and Martin Fowler. These best practices were turned into the opposite to trigger you to think!

1. 10 Tips to decrease your velocity
Talip Ozkeles
#jfall

2. Talip Ozkeles
IT Consultant @ GROUP9
Software Development (mostly Java) and (Enterprise) Architecture
Agile Coaching and Training (Scrum, XP and TDD)

3. What this presentation is about
▪ A collection of experiences / best practices / habits to work more effectively (so
to increase your velocity),
from people like Henrik Kniberg, Stephen Covey, Robert C. Martin, Daniel Pink,
Kent Beck, Alistair Cockburn and Martin Fowler
▪ These best practices were turned into the opposite to trigger you to think! (tips
to decrease your velocity J)

4. Disclaimer !!!
UNSAFE HARBOR STATEMENT
▪ This presentation is not intended for people who already know how
to increase their velocity
▪ You are allowed to make wrong business decisions on what will be
presented today

5. #1 Don’t use a Skills Matrix (Team Competency Matrix)
▪ Rate the needed skills within your project for all team members
▪ And then: do NOT train yourself and do NOT pair temporarily with people that
have the needed skills to fill the gaps
Team member
/ Skill
TypeScript Jasmine Selenium
John ** *
Mary *** ***** *
Vincent *** **

6. #2 Do not work as a team but as individuals towards non-
shared goals
▪ Do not work towards a shared goal or vision
▪ Just put more pressure on individuals to work harder
IndividualsTeam
Shared
goal

7. #2 Do not work as a team but as individuals towards non-
shared goals
▪ Do not work towards a shared goal or vision
▪ Just put more pressure on individuals to work harder
IndividualsTeam
Shared
goal

8. #3 Do not reduce technical debt
▪ Do not refactor to make it faster to
add new features
▪ Make very complex, unreadable,
tangled, fragile code, that breaks
some other part in your system
than the part that you change

9. #4 Make your delivery pipeline slow
▪ Do not run builds and tests in
parallel
▪ Let every build do unnecessary
work over and over again,
like generating documentation
▪ Make a tedious and labor intensive,
manual, error prone procedure to
deploy your system

10. #5 Make features that are rarely or never used
▪ Don’t ask what the value of a feature is to users
▪ Don’t ask how often they use a feature

11. #6 Integrate as late as possible
▪ Merge code as late as possible, so
that you get merge conflicts late.
This takes longer to fix.
▪ Test the integration of components
as late as possible. You’ll get late
feedback. Misunderstandings show
up late. It takes longer to get
aligned again.

12. ▪ Make flaky test. Let them fail randomly.
▪ If you cannot make flaky tests, make them slow. Every change takes forever to
give you feedback.
▪ If you still cannot make slow tests, test everything through the wrong interface,
like the UI. Repeat a lot of setup, like logging in for every individual test case.
#7 Do not automate tests effectively

13. #8 Do not try to change or improve
▪ Don’t argue the rules and ways of
working that your company has
made in the last century
▪ Just keep on doing everything the
same way and call it
▪ Agile
▪ Scrum
▪ XP
▪ Management 3.0
▪ SAFe
▪ Scrum@Scale
▪ Kanban
▪ Lean
▪ < Fill your own buzzword here >

14. #9 Don’t give responsibility, ownership and trust
▪ Call your line, team or project
manager: scrum master
▪ Do not facilitate, educate, or coach,
but MANAGE the work of team
members
▪ Make sure that YOU assign a task to
everybody. Nobody picks up tasks
by themselves. Because then you
trust them and they take
responsibility and ownership.

15. #10 Take no time for effective retrospectives
▪ Just skip them because you have better things to do
▪ If you insist on doing them, don’t try to find the root cause of issues
▪ If you find root causes of issues, don’t try to find effective actions to solve them
▪ If you still persist in finding actions, don’t execute and track them to see whether
they solved the issues

16. DON’T try this at home

17. DO this at WORK !!!

18. If you want the opposite, to get a team that
▪ Has an agile mindset and is self organized
▪ Understands and applies the Scrum Framework properly (the Values, Roles,
Events, and Artifacts)
▪ Gets rid of wasteful activities and only executes value adding activities
I can help you with my workshops and coach on
▪ Agile, Scrum, and XP
▪ Test Driven Development
▪ Clean Code and Architecture

19. “Please rate my talk in
the official J-Fall app”
#jfall