Managing Technical Debt - Scrum Day Bandung
•
0 likes•161 views
Present by Chris Oentojo, PM Core Product - Gojek at Scrum Day Bandung
Recommended
Recommended
More Related Content
What's hot
What's hot (10)
Similar to Managing Technical Debt - Scrum Day Bandung
Similar to Managing Technical Debt - Scrum Day Bandung (20)
More from Scrum Day Bandung
More from Scrum Day Bandung (19)
Recently uploaded
Recently uploaded (20)
Managing Technical Debt - Scrum Day Bandung
- 1. Managing Technical Debt A Product Manager’s Perspective Chris Oentojo
- 2. Hi. CS Theory @ UCLA Engineering @ ibeatyou Startup concepts @ CMU Startup concepts realized @ Poof! Engineering @ Zazzle Product @ Dropbox More Product @ GO-JEK
- 3. PM Driver App Rewrite PM Driver App PM Transport (consumer + backend) Release Manager PM Go-Fleet 2 years My time @ GO-JEK PM Mobile
- 4. Technical debt: cost of additional rework due to choosing an easy solution now instead of applying a better approach that might take longer
- 5. • Business pressure • Poorly planned product experiences • Lack of ownership • Poor testing practices • And more How does it accumulate?
- 6. It slows you down. Why does it matter?
- 7. Driver App - the state of things (May 2016) • 1.5 years of constant development • Continuously adding new features • “No time” to refactor • Added GO-CAR driver app to the mix
- 8. • Critical bugs -> production support -> hot fix releases • Slowed us down by adding unpredictability • Damaging to the team Driver App - the consequence of those things
- 9. • Rewrote and redesigned from scratch (7 months) + More ownership + Better test coverage + More modularity - Old driver app was still adding new features Driver App - the solution to those things
- 10. • 2 firebreaks over the course of 2.5+ years • Supports 3 types of transportation: bikes, cars, taxis • Feature full - History, search, notes, payment options, manual and auto-applied vouchers, discounts, ETAs, drivers on the map, clickstream tracking, surge pricing, contact options, ratings, live tracking, etc. Rider App - the state of things (May 2017)
- 11. • Took 2 weeks to pinpoint why an extra click- stream event was getting triggered • Took us a month to release the automatic application of a voucher • We pushed off some bigger features because we knew how complex it would get Rider App - the consequence of those things
- 12. • Rewrote and redesigned from scratch (~7 months) + More ownership + More modularity + Varying levels of engineering experience + Paused feature development Rider App - the solution to those things
- 13. The solution is not necessarily to just rewrite and pause everything
- 14. Tactic A Strategic Tactical Health
- 15. Tactic B Devote one iteration every X iterations to cleaning up tech debt.
- 17. Not all tech debt is bad Prototyping and testing concepts the desired way will result in tech debt, but that’s okay.
Editor's Notes
- = I’m from the california, LA specifically = Studied computer science at UCLA = Did my masters at CMU in software management = Worked on a startup for a year = Freelanced for a year = Product at dropbox - photos team = GO-JEK - transportation. Now the geo team
- = I’m from the california, LA specifically = Studied computer science at UCLA = Did my masters at CMU in software management = Worked on a startup for a year = Freelanced for a year = Product at dropbox - photos team = GO-JEK - transportation. Now the geo team
- = in short - accumulating debt that you will have to pay back later = whenever we execute, we make tradeoffs = 2+ years at gojek, it’s growth, I’ve experienced a lot about tech debt so will focus on the context of gojek for the remainder of the presentation
- = this is not an exhaustive list, it will vary depending on your organization = business pressure - sometimes, market dynamics change and your CEO says we absolutely need to do something e.g. - cash top-up for our drivers = Poorly planned - if a product experience is not well thought out, then you might jump into engineering too quickly and when requirements change you will have accumulated debt e.g. = Lack of ownership - when your engineering team does not feel ownership over their code, over the customer experience they are delivering e.g. = Poor testing practices - lack of simple unit tests can result in tech debt
- = it’s important to understand what it is and why it’s happening = you will be slowed down by it in the future, save yourself from that = will show you some examples of how it slowed us down at go-jek
- = Hundreds of thousands of drivers = 1 driver app = 2 junior engineers on the team = new features = 1-1 allocation = cash top up = driver service agreement = auto-bid functionality
- = hot fix releases are disruptive, highly stressful events = team morale gets affected
- = supports 1 million registered drivers = supports 4 skus of driver app
- = a few activities and presenters in android that were a few thousand lines of code
- = automatic application of a voucher logic happens on our most complicated screen, the booking screen = we had to alter our roadmap because of our tech debt
- = figure out what makes sense for your projects, products, and team composition = for us, rewriting was the way to go because we accumulated so much tech debt = next up are some tactics to prevent accumulation of debt
- = cycle planning, buckets of tasks
- = another simple tactic, perhaps 1 cycle every 4 makes sense = try it out = but shorter timescale makes sense, not like us once a year
- = if features are being used or provide little to no value then kill them = keeping features around is just more for you to maintain =
- = when testing new ideas you want to move fast to find product market fit = this means you might explicitly decide to take short cuts and hack, this accumulates tech debt just make sure to slot in time later to refactor