Extreme product development

Extreme programming won. What seemed extreme in 1999 went mainstream: user stories, solution spikes, pair programming, unit tests, and frequent incremental releases. Today, software development is shifting from projects to products, and from outputs to outcomes, and we’re discovering better ways to work.

Today’s extreme product development happens in a small but growing number of companies. This presentation will reveal how they have figured out how to truly work remote-first, with no offices, and support part-time and flexible working. Their development teams don’t make estimates, manage huge backlogs, or waste time in meetings. They even skip daily stand-ups. The resulting product development is less wasteful, and it is also more human.

Transcript

1. @PeterHilton http://hilton.org.uk/ Extreme product development
2. Kamil Pietrzak Fonsi Fernández Lorenzo Lamonica Sebastian Staines
3. www.smosh.com www.madmaxz.com www.harrogateironing.co.uk www.slappedham.com www.urbasm.com
4. 4 @PeterHilton • Extreme programming has won. Even TDD and pair-programming aren’t extreme any more
5. How many of these practices are extreme? 5 @PeterHilton • User stories Frequent small releases Iterations Sustainable pace Dedicated team work area Daily stand up meeting Fix process when it breaks Design for simplicity Use spikes to reduce risk No functionality added early Refactor when possible Code to agreed standards Pair programming Collective ownership Commit code changes o ft en Test-driven development
6. 1. Remote-first
7. Experience in remote-first companies Two remote-first start-ups, both founded in 2018 All internal processes happen remote, starting with hiring Everyone works to do them well, if not better than in-person No exceptions for ‘when we next meet in person’ I met my colleagues in person for the first time months later (and we were rubbish at using a physical whiteboard 😭) 7 @PeterHilton •
8. Remote work is more flexible, and it’s humane 8 @PeterHilton •
9. How to work remote-first Start the company without an o ff ice 😅 (can an o ff ice-based company ever become remote-first? 🤔) Make everything explicit Master asynchronous work Don’t rely on seeing people to believe that they’re working 9 @PeterHilton •
10. @PeterHilton • Work Together Anywhere Lisette Sutherland (2018) 10 https://lisettesutherland.com/book/
11. 2. Part-time employment
12. Experience working part-time Working 4 or 4½ days a week since 2015 Normal where I live (the Netherlands) & in some companies I usually take Friday (a ft ernoons) o ff or a mid-week break, or a Friday-Monday long weekend … but I remain flexible 12 @PeterHilton •
13. Life’s too short for to only work on your job. I’ve got side projects to work on 😅 13 @PeterHilton •
14. How to Prioritise - focus on the work that matters most Asynchronous work Figure out how to make it work for your role Find an employer that will: stop pretending that the company owns employees’ lives, understand that flexibility works two ways 14 @PeterHilton •
15. 3. Asynchronous work
16. https://nohello.net/
17. Experience with asynchronous work The remote-first companies do more work asynchronously e.g. (hour-long) Slack threads instead of meetings, Notion page documentation, and meeting pre-reads Most meetings are 15-30 minutes long More 1-1 meetings, fewer team meetings 17 @PeterHilton •
18. More thinking, fewer meetings, more inclusive, less of a performance 18 @PeterHilton •
19. working async means ‘less showing off, and more showing up for each other’ Juke Trabold, engineering leader 19
20. How to work asynchronously Don’t rely on meetings to get things done Value explicit written communication over showing o ff Don’t assume that everything is better face-to-face Learn to communicate honestly in chat 20 @PeterHilton •
21. 4. Short backlog
22. Experience with a short development backlog An Up next backlog of fewer than 10 user stories or tasks A weekly check that everyone knows what to work on next Responding to an opportunity doesn’t change any plans Short lead time becomes possible https://hilton.org.uk/blog/infinite-backlog 22 @PeterHilton •
23. Don’t waste time listing work you’ll never start Leave space to respond to opportunities 23 @PeterHilton •
24. How to work with a short backlog Establish quarterly goals, not a feature backlog You probably need a product manager for this Find a way to connect daily work to larger goals Make sure everyone understands where you’re going and why! 24 @PeterHilton •
25. 5. Quarterly OKRs
26. Experience with objectives and key results (OKRs) We focused on one or two short-term goals at a time 2-3 objectives per quarter 1-3 quarters per objective OKRs co-created with the whole team, starting together Owned by the product manager, who discovers options 26 @PeterHilton •
27. Reframe work around problems worth solving Focus: limit what you’re working on right now 27 @PeterHilton •
28. How to adopt OKRs Align product strategy on customer problems, not features Let designers and developers figure out the features Reduce stakeholders’ need to know ‘what we’re going to get’ 28 @PeterHilton •
29. @PeterHilton • Radical Focus Christina Wodtke (2021) 29 https://hilton.org.uk/blog/radical-focus
30. 6. Available product manager
31. POs are required to answer any question that comes up during development within two minutes. This takes precedence over all meetings, etc., and the PO must be available electronically if not physically. Allen Holub @allenholub 31 https://twitter.com/allenholub/status/984840408260751360
32. Experience as an available product manager Prioritised team member questions (a developer o ft en should interrupt a meeting I’m in) Used Slack to consistently welcome and answer questions This is the killer application for reaction emoji 👍 https://hilton.org.uk/blog/two-minute-rule 32 @PeterHilton •
33. 33 @PeterHilton • Availability enables continuous collaboration Without this alignment you get lower quality and expensive rework
34. How to have an available product manager Make decision-making during development visible Make rework visible Become the product manager 😬 Align on day-to-day priorities, instead of hiding in meetings Maybe add an #emoji-language Slack channel 🚀 34 @PeterHilton •
35. 7. Zero bug policy
36. Experience with zero-bug policies Announced a policy to fix bugs first by default Starting and transition is the hardest part, especially distracting ‘what if’ discussions Usually had 0-2 open bugs (zero is a target) Discussed what’s happening for more than 5 open bugs https://hilton.org.uk/blog/zero-bug-policy 36 @PeterHilton •
37. Open bugs waste time and they break product management 37 @PeterHilton •
38. How to adopt a zero-bug policy Discuss why there are bugs Talk about bugs case-by-case, one at a time Discuss why you aren’t fixing them Discuss the cost of managing bugs Be honest about what a zero-bug policy would require 38 @PeterHilton •
39. 8. Team programming
40. Experience with team programming Developers who like pairing sometimes like a bigger group We started with a weekly team programming session FOMO for non-attendees, fun for attendees As a product manager, it lets me see the actual work ‘I came to answer questions; I stayed for the banter’ 40 @PeterHilton •
41. Just because you have fewer meetings doesn’t mean you don’t want to work as a group 41 @PeterHilton •
42. How to adopt team programming Try it out, starting with one hour per week Invite the designer and product manager Use team programming to address urgent critical issues Create an environment where everyone wants to work together, instead of only working by themselves 42 @PeterHilton •
43. 9. Trustful relationships
44. Experience building trustful relationships Leadership in building and sharing trust made a di ff erence Delegated decision-making Team-level work on communication and feedback There are limits - you’re still not a family (trustful relationships don’t prevent layo ff s) 44 @PeterHilton •
45. 45 @PeterHilton • It feels uncomfortable at first, but actually working together depends on trustful relationships
46. How to establish trustful relationships Start at the top, but expect work from everyone Create an environment for addressing problems Create a system for adopting ideas, e.g. Holocracy proposals Recognise the importance of e ff ective feedback Recognise and address its di ff iculty 46 @PeterHilton •
47. @PeterHilton • The Culture Code Daniel Coyle (2018) 47 https://danielcoyle.com/the-culture-code/
48. @PeterHilton • Radical Candor Kim Scott (2019) 48 https://kimmalonescott.com/radical-candor
49. My boss told me if I wanted a pay rise I needed to dress for the job I wanted. Currently sat in a disciplinary in a Batman outfit. Ian Six @RSiansix 49 https://twitter.com/RSiansix/status/1759653651629453718
50. 10. Psychological safety
51. Psychological safety Dependencies 51 @PeterHilton • Remote- first Part-time Async Short backlog Quarterly OKRs Available PM Zero-bug policy Team coding
52. Experience with building psychological safety Facilitated retrospectives that don’t let the team get lazy O ft en spent a whole retro on a single serious topic Retros about people and relationships, not process ‘Doing the work’ requires actual work People may need help to learn how https://en.wikipedia.org/wiki/Psychological_safety 52 @PeterHilton •
53. Extreme product development depends on psychological safety 53 @PeterHilton •
54. @PeterHilton • 54 The No Asshole Rule Bob Sutton (2010) https://www.bobsutton.net/book/no-asshole-rule/
55. You don’t need an alternative to a bad practice, you just stop doing it 55 @PeterHilton •
56. ‘Encourage teams to bond through day-to-day tasks… the very act of being productive— just doing the work together— becomes a feedback loop that can bond a team and help create the conditions for psychological safety’ 56 https://hbswk.hbs.edu/item/four-steps-to-build-the-psychological-safety-that-high-performing-teams-need-today
57. How to build psychological safety 1. Do the work to reduce the ‘noise’ 2. Do the work to achieve your goals 57 @PeterHilton •
58. Extreme product development
59. Pursue psychological safety! When have you experienced amazing teamwork? When have you felt safe to talk about what’s going wrong? Have more conversations about all of this! Reflect on the dependencies between extreme practices And explore what other people think is extreme 59 @PeterHilton •
60. ‘People are amazing in their creativity when they realise they have the power to change things’ Juke Trabold, engineering leader 60
61. @PeterHilton http://hilton.org.uk/blog/