Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Extreme product development

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.

Peter Hilton

May 08, 2024

More Decks by Peter Hilton

Other Decks in Technology


  1. 4 @PeterHilton • Extreme programming has won. Even TDD and

    pair-programming aren’t extreme any more
  2. 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
  3. 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 •
  4. 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 •
  5. 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 •
  6. Life’s too short for to only work on your job.

    I’ve got side projects to work on 😅 13 @PeterHilton •
  7. 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 •
  8. 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 •
  9. working async means ‘less showing off, and more showing up

    for each other’ Juke Trabold, engineering leader 19
  10. 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 •
  11. 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 •
  12. Don’t waste time listing work you’ll never start Leave space

    to respond to opportunities 23 @PeterHilton •
  13. 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 •
  14. 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 •
  15. 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 •
  16. 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
  17. 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 •
  18. 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 •
  19. 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 •
  20. 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 •
  21. 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 •
  22. Just because you have fewer meetings doesn’t mean you don’t

    want to work as a group 41 @PeterHilton •
  23. 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 •
  24. 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 •
  25. 45 @PeterHilton • It feels uncomfortable at first, but actually

    working together depends on trustful relationships
  26. 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 •
  27. 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
  28. Psychological safety Dependencies 51 @PeterHilton • Remote- first Part-time Async

    Short backlog Quarterly OKRs Available PM Zero-bug policy Team coding
  29. 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 •
  30. @PeterHilton • 54 The No Asshole Rule Bob Sutton (2010)

  31. You don’t need an alternative to a bad practice, you

    just stop doing it 55 @PeterHilton •
  32. ‘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
  33. How to build psychological safety 1. Do the work to

    reduce the ‘noise’ 2. Do the work to achieve your goals 57 @PeterHilton •
  34. 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 •
  35. ‘People are amazing in their creativity when they realise they

    have the power to change things’ Juke Trabold, engineering leader 60