This document provides advice on how to introduce new engineering practices and technologies to a team or business. It discusses several examples of proposed new practices and technologies such as test automation, continuous integration, refactoring, and DevOps. For each, it advises how to demonstrate the benefits through examples and metrics, how to gain buy-in from various stakeholders, and pitfalls to avoid such as claiming a practice is necessary just because a famous person recommends it. The overall message is that new practices must provide clear value and be introduced through demonstration and collaboration rather than dictates.

1. How engineering practices
help business
Andrei Rebrov

3. What is it about

5. Who is the target audience?

6. If you are…
• dev (qa, ops) or you want to
implement something
• manager who tired of “new
methodologies”
• coach/consultant who doesn’t know
how to implement certain practice
…then you are welcome!

7. Story time

8. Story# 1. Selenium
• Hey, Selenium is awesome! Let’s
write autotests using it!
• But we have almost finished
system on TestComplete.
• TestComplete - $#$&#!
• …

10. Don`t!
• Never say that current progress is
nothing
• Originality of technology is not a pros
• “It is used by XYZ” means nothing,
even if XYZ is Google

11. How it may work
• Attract manual testers – they are your
customers
• Show your progress and working demo as
often as possible – this is the best way to
show how simple and good is it
• Make demo positive – bring tea, coffee
and cookies
• Lear how to teach people to use your
framework

12. How to sell to business owners
• Tests make development
cheaper, because we find bugs
earlier
• We may not scale QA team for a
long time
• We can make more tasks during
iteration
• We can release faster and more

13. New techonologies are safe and give us
advantage

14. Story# 2. TDD
• Guys, you need TDD, it rocks!
• But we have to rewrite whole
out project, so we can test it!!!
• So what, you’ll have tests in
the end!
• …

16. Don`t!
• Using TDD just for tests and
TDD itself is stupid
• Using TDD for everyone’s
wealth is more stupid
• TDD is used by these guys
from XYZ… Well, I hope you
got it

17. How it works
• Just show video example
• Do it by yourself in everyday
job
• Coding Dojo

18. How to sell to business
owners
Guerilla TDD:
•Use it for 3-4 weeks
•Show to your business
improved results (metrics from
SLA, bugs, wtf/sec)
•Make an agreeement

19. TDD helps to write code
effectively

20. Story# 3. Refactoring
• Let’s refactor this module!
• Why we need this? It works!
• But it has millions of
violations inside!
• …

22. Don`t!
• When you talk about refactoring,
prepare yourself for resistance,
because it’s offence
• Rewrite code because this is what
book saying to you - that’s stupid
• Be patient, it may take months to
agree on refactoring

23. How it works
• Visualize code problems –
SonarQube is good on it, managers
are usually scared by numbers
• Explain what is technical debt and
how it affects project’s future
• Prepare refactoring plan with clear
explanation why and when we
should refactor something

24. How to sell to business owners
• Show them this chart
• Tell them what happens to debitors =)

25. Refactoring helps not to be afraid of
debts

26. Story #4. Automation
• Mike, how about test
automation?
• Why do we need it?
• Well, it’s going to be fun and
we can improve our CV!
• …

28. Don`t!
• Automation just for automation is just
like TDD for TDD and we already know
how bad is it
• Don’t tell to your team that automation
is free to implement
• Remember, there are no free tools, at
least they cost you your time
• Try first, recommend after

29. How it works
• Show working example
• You should know all pros and
cons
• Show different ways how this
tool could be used – more you
can offer is better

30. How to sell to business
owners
• Calculate automation ROI
• Compare automation support
cost to manual work cost
• Expose how expensive might
be the problem made by
manual work

31. Good robots will save us

32. Story #5. Feature Toggling and
Branching
• We need to stop feature
branching!
• Why?
• That’s what Martin Fowler
said!
• …

34. Don`t!
• Not everyone knows who is Mr.
Fowler
• Read Fowler first
• Don’t use tech terms like cherry
pick, feature branch and so on too
much, it’s hard to understand
• Saying «feature toggle is like if-
else statement, but not exactly» is

35. How it works
• We save time on branch merging
– there are no more branches
• Everyone have updated code and
see whole picture
• It’s much easier to configure
Continuous Integration

36. How to sell to business
owners
• Now we can always turn
on/off functionality on
production if we need it

37. Occama blade

38. Story# 6. Continuous
Integration
• We need Continuous Integration,
so everyone will know that code is
still working!
• Why don’t you test it on you
computed?
• Why do I need it?
• …

40. Don`t!
• Never say that CI fill find your
bugs, it sounds like you are a bad
developer
• CI is not just about running unit
tests, if you manager has tech
background, don’t say that

41. How it works
• CI helps us implement
regression testing, so we free
our QA
• We can automate our
processes

42. How to sell to business
owners
•See automation block
•It’s a way to Continuous
Delivery

43. CI cares about build stability

44. Story# 7. DevOps
• Let’s configure Nagios, Chef,
Graphite and Logstash and
become an awesome DevOps!
• How it will help us?
• Well, it is just about being
modern.
• …

46. Don`t!
• Don’t sell tools, they alone don’t
solve your problem
• Building DevOps culture takes
time, don’t make any week
estimates
• Don’t be offensive to sysadmins

47. How it works
• Visualization of your process is
the easiest way to show that
something is wrong
• Do some firefighting – quick win
gives you some points
• As always, demo works

48. How to sell to business
owners
• Delivery becomes simple and
manageable
• We can delivery in hours not in
days
• There is no more lost of sensible
data
• We can become feature factory

49. DevOps lets us release first on the
market

50. Twitter
@andrebrov
E-mail
arebrov@scrumtrek.ru
Skype
rebrov.andrey
Q&A