Managing Technical Debt and Professionalism @ CyberArk - Noam Zweig & Ran Deri
-
Upload
agilesparks -
Category
Documents
-
view
721 -
download
0
Transcript of Managing Technical Debt and Professionalism @ CyberArk - Noam Zweig & Ran Deri
1
Technical Debt Stewardship for Scaling Agile @ CyberArk
Noam Zweig, Head of Architecture, R&D Ran Deri, Group Manager, R&D
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
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
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
A concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall soluAon
-‐ Techopedia hZp://www.techopedia.com/defini>on/27913/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
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
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
And so we started
- Technical Agility assessment (© Gil Broza – 3PVantage -‐ hZp://www.3pvantage.com/ ) – Presented at AgileIsrael-‐2013 J
- Code Quality tool (Sonar)
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) - Structural\architectural debt (Separating coupled
components)
- Collected info + visualize - And back again…
14
It wasn’t so simple…
Business Level Show achievements to business\management
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
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
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
Lessons learned
To take ac>on you need
Managers engagement Close follow-‐up and consistent pushing