1. 1
Technical Debt Stewardship for Scaling
Agile @ CyberArk
Noam Zweig, Head of Architecture, R&D
Ran Deri, Group Manager, R&D

2. 2
CyberArk Snapshot
▪ Specializes in protecting the heart of the enterprise against advanced-cyber attacks
▪ Fast Growing, Market Leader in Privileged Account Security
▪ 2nd largest Israeli Information Security Company
▪ Proven successful continuous innovation
▪ Organized processes of continuous improvement
▪ Mature, but acts fast and dynamically

3. 3
Trusted by Customers Worldwide
Over 1,800 Global Customers
40% of Fortune 100
18% of Global 2000

4. 4
Agile@CyberArk at a glance
2011
–
something
need
to
change

5. 5
2011
–
something
need
to
change
2012
-­‐
Explore
and
experiment
Managers
training
Kanban
Cross
Func>onal
Team
experiment
2013
-­‐
R&D
organiza>onal
change
Cross
func>onal
teams
Self
managed
groups
New
roles
(TL,
FA,
Architect,
QA)
Professional
bodies
2014
-­‐
Inspect
and
adopt
CI
(Velocity,
Cycle
>me,
WIP…)
Ops
Review
New
trainings
Technical
Debt
Project
2015
–
prepare
for
next
phase
of
scaling
3m
a3er
the
change
-­‐
survey
Achievements
-­‐ Reduce
overhead
of
planning
and
re-­‐planning
-­‐ BeZer
cope
with
changes
-­‐ BeZer
handle
large
product
requirements
-­‐ Visibility
to
customers
and
business
goals
-­‐ Product
perspec>ve
were
strengthened
and
beZer
sync
between
the
groups
Agile@CyberArk at a glance

6. 6
What are we talking about?
▪ Technical Debt
A
liZle
debt
speeds
development
so
long
as
it
is
paid
back
promptly
with
a
rewrite...
The
danger
occurs
when
the
debt
is
not
repaid.
Every
minute
spent
on
not-­‐quite-­‐right
code
counts
as
interest
on
that
debt.
En>re
engineering
organiza>ons
can
be
brought
to
a
stand-­‐s>ll
under
the
debt
load
of
an
unconsolidated
implementa>on,
object-­‐
oriented
or
otherwise
-­‐
Ward
Cunningham
hZp://c2.com/cgi/wiki?WardExplainsDebtMetaphor
Eventual
consequences
of
poor
system
design,
so3ware
architecture
or
so3ware
development
within
a
codebase
-­‐
wikipedia
hZp://en.wikipedia.org/wiki/Technical_debt
Like
a
financial
debt,
the
technical
debt
incurs
interest
payments,
which
come
in
the
form
of
the
extra
effort
that
we
have
to
do
in
future
development
because
of
the
quick
and
dirty
design
choice
-­‐
Mar>n
Fowler
hZp://mar>nfowler.com/bliki/TechnicalDebt.html
Con>nuous
aZen>on
to
technical
excellence
and
good
design
enhances
agility
-­‐
Principles
behind
agile
manifesto
hZp://www.agilemanifesto.org/principles.html

7. 7
Let’s return the debt!
▪ After learning the area, we found out that the
regular “Housekeeping” mechanism is
not satisfying for proper return of
Technical Debt
▪ So why not extending the
mechanism/invest in it?
PSHHH…
That’s not easy to perform cross R&D

8. 8
Let’s return the debt!

9. 9
Drifting into the comfort zone…
▪ Housekeeping time we can choose to improve:
▪ “do it fast” and
“do it on time” ->
Immediate and tangible value
“do it right”
and “keep doing it” ->
Long term and intangible
Do
it
fast
Do
it
right
Do
it
on
>me
Keep
doing
it

10. 10
And so we started
- Technical Agility assessment (©
Gil
Broza
–
3PVantage
-­‐
hZp://www.3pvantage.com/
)
–
Presented
at
AgileIsrael-­‐2013
J
- Code Quality tool (Sonar)

11. 11
And so we started
- Results analysis with teams

12. 12
And so we started
- Meetings with Business People (PM,
management)

13. 13
And so we started
0
5
10
15
20
Alpha
Beta
Gamma
Delta
Debt
Alloca>on
- Pre quarter – time allocations
- Allocations are correlative to debt
- Focus on “do it right”
- Code debt (Refactor complex areas, Upgrading
infrastructures)
- Documentation debt
- Test debt (UT infrastructures)
- Structuralarchitectural debt (Separating coupled
components)
- Collected info + visualize
- And back again…

14. 14
It wasn’t so simple…
Business
Level
Show
achievements
to
businessmanagement
Team
Level
Trying
to
return
large
debt
at
once
fails
“Technical
Debt”
term
was
interpreted
differently
by
different
teams
R&D
management
level
Team
Leaders
&
Group
Managers
engagement

15. 15
What happens now?
Code Debt
Test Debt
Achievement
OrientedArchitectural
structural debt

16. 16
Are we agile?
▪ Yes!
▪ More confident in code
▪ Better code, leads to faster development
▪ Technical Debt mindset is in the minds of all people

17. 17
Lessons learned
Enhance
and
groom
the
non-­‐funcAonal
areas
of
the
products
require
long
and
permanent
work
(Especially
when
the
need
is
“burning”)
Convince
levels
(“Get
buy-­‐in:
“This
is
valuable”
ó
I
will
choose
this
over
other
things”)
Measurement
helps!

18. 18
Lessons learned
To
take
ac>on
you
need
Managers
engagement
Close
follow-­‐up
and
consistent
pushing

19. 19
Lessons learned
AcAons
changes
mindset

20. 20
Questions?
noam.zweig@cyberark.com
Noam Zweig@CyberArk
ran.deri@cyberark.com
Ran Deri@CyberArk