Productise your project's technical quality

We have successfully applied product principles to developing, well, products; listening to users, delivering the highest value features first, measuring success. What if the same principles apply to the “non-user facing” aspects of the software your team writes; architecture, codebase health and technical debt? In other words, what if your product’s technical quality...is a product?

In this talk, I’ll go through a framework that you can use as a reference when deciding what aspects of tech debt to address, in what order, and in what way. You can adjust that to match your team’s special context and challenges, but I’ll also take you through some implementations that I’ve seen in engineering teams as examples. By the end of the session, you’ll have tools that will help you choose the most effective way towards engineering setup and decision making that works for your team, but also grow your team’s muscles towards identifying these areas in the future.

Transcript

1. Productise your project's technical quality Maria Ntalla LeadDev London Meetup, October 2019
2. Applying product thinking to your product and process quality * by which I mean:
3. With many thanks to: Emmanouil Kiagias, Zoe Vance, Maya Rosecrance, Tom Godkin, Jack Newberry, Josh Hill
4. Hello! • Maria Ntalla ( @ntallaki) • Work: Engineering Manager at Pivotal R&D • Outside work:
5. Up next • Lessons & Takeaways • The story • The idea • The framework
6. Lessons & Takeaways
7. 1. Tech & process quality has a direct line to your user’s experience. It very much is part of the product you ship. 2. Build-measure-learn 3. Balance small iterations with starting fresh Could what you’ve iteratively built no longer be fit for purpose? 4. Progress over perfection Don’t let “solve the root problem” become “solve no problem”
8. The story
9. • Some context ◦ Redis team - around for a while ◦ Part of a bigger cloud platform ◦ ...but with human end users ◦ strong testing culture
10. • Story starts before I even joined the team • As an engineer and then the anchor of the team I started noticing ◦ Day to day ◦ Planning meetings ◦ Weekly retrospectives ◦ Iterative improvements not making a dent
11. The idea
12. Let’s think productly(?) for a moment • Assumption ◦ In our case: we’re not as productive as we could be, we’re duplicating • Early validation / invalidation • Discover the problem space • Frame the solution • Build-measure-learn
13. The framework See if you can count how many times I say “Everyone gets a pen and stack of stickies”
14. Step 0: Inspiration & Homework • Move from qualitative to quantitative • Resist the temptation to start solving • Plan a team meeting - include product owner • Ask one of your teammates to facilitate, and support them in preparing • Give team notice, encourage reflection
15. Step 1: Definitions, Goals, Anti-Goals, Risks • Everyone gets a pen and stack of stickies • Spend a good chunk of time ◦ getting clear on the problem ◦ vocabulary ◦ risks ◦ what’s in and out of scope • Beware of: wordsmithing
17. Step 2: Brainstorm problems • Start with: Quiet brainstorming ◦ Give everyone a sharpie and pile of post-its ◦ For 10’ people list what problems they see with the quality of the software you ship, and the process you follow to ship it ◦ No filters, no scopes, no constraints
18. Step 3: Individual stack rank • Each person takes 1’-2’ min to rank their own stickies • Once everyone is done, people keep their top 3 (or 5) • Tear up the rest ◦ Do so confidently; if something is important it will come up again
19. Step 4: Share • Put everything in a shared place ◦ A table, a whiteboard, a miro board, a google doc even • Discuss • Group into themes
20. (optional) Step 5: Dot vote & group stack rank • Yet another prioritisation filter • Everyone gets 3 votes • Stack rank according to total votes • Keep the top <number-that-makes-sense>
22. (we took a break here) (of a few days)
23. Step 6: Brainstorm & share solutions • Quick summary of the problem space you’re tackling • Everyone gets a pen & pile of post-its
24. Step 7: 2x2 • Using <marking-material> draw a cross in shared area ◦ I recommend something editable ;) • Axes could be “big/small impact” VS “easy/hard to implement” • For each of your finalists, have a short conversation about where it lands
25. Start here lower impact higher impact easy hard Distractions (for now) Don’t do or, “how can we reduce complexity?” Continue here
27. Beware... • Everything turning up as very easy, very impactful ◦ Remember: it’s relative. Move the axes if needed. • Ideas “on the line” ◦ Make a decision by breaking it down further, or “demoting” • Signing up to automate all the things ◦ Remember: impact first. Yes, we absolutely can automate anything. But should we? What’s the value?
28. Step 7: Write and prioritise work on the backlog • Translate into stories • Break down complexity even further as needed • Decide how to prioritise against other work that’s happening • Work with your product manager/owner on this!
29. Step 8: Continuously iterate • Keep your definitions current • First session already brought difference • Months after the team was tackling the “higher hanging fruit”
31. Twist: Cloud Foundry container team battles flaky tests • For the full story: “The night is dark and full of flakes” ( Ed King) • Set up a workflow to pinpoint which tests flaked at what rate • Experimented with how to document and prioritise work on resolving them • Looked at the bigger picture - carve out categories • Converted flake solutions to product features (e.g. logging, healthchecks)
32. Thank you!