This document discusses an organization's approach to prioritizing work and developing software. It emphasizes focusing on solving clear problems rather than executing on estimates or deadlines. Work is organized into buckets or strategies, each with a dedicated squad prioritizing issues. Issues go through an intake process to clearly define the problem before being selected for a cross-functional task force to implement a solution. The goal is for squads to proactively address problems rather than reactively execute work.

1. Shipping code is not the problem 29 marzo
2018
Sponsored by
Deciding what to ship, it is!

2. More than 95% of your organization's
problems derive from your systems,
processes and methods, not from
individual workers.
Peter Scholtes

3. There is no such a thing as
“wrong people”. It’s only
“right people in the wrong place”
Udi Dahan

4. What do we do?
A brief introduction

5. A product, not really. A framework
• We must be reliable
• Our customers are not end users
• They count on us to build things

6. We’re quality driven

7. We’re quality driven
Move fast and break things lowers,
or might lower, the quality barrier

8. We have no deadlines

9. We have no deadlines
It'll be shipped when it'll meet the
quality bar, no earlier

10. We have no estimates

11. We have no estimates
money overlooks everything else,
making you blind

12. Execution is not the problem
• We're very good at it
• and it's quite easy to be good at it
• There are tons of well established practices that we apply
• Pairing
• Testing
• Writing documentation in advance
• Automated builds
• CI/CD
• (internal) Very short feedback cycles
• Etc…

13. Apples and Oranges

14. Apples and Oranges
Agile processes
address execution problems
not backlog prioritization ones

15. Backlog prioritization
…a nightmare that comes true

16. the larger the backlog
the nicer the graveyard

17. The seed of life
• Inbox will contain all newly created issues (yes we use GitHub)
• Issues has to be defined as problems we want to solve
• Fix ABC or ABC is broken are not problems
• ABC is causing pain to customer because of its design is a good problem
• Should not be limited to product related issues
• Process improvements are valid problems
Inbox

18. When problems are not clear enough
• It’s a bug, ok, but what problem does it cause?
• That’s what the issue opener was observing:
• Is there anything more to that?
• A squad member will work with the issue opener
• To get the issue in good enough shape
ProblemDefinition

19. Hold on! What’s a squad?

20. What’s a squad?
• Squads own processes
• Long lasting, but not set in stone
• Diverse skills set
• Backlog owners
• We have a squad per strategy
• There is more to this

21. We have an obsession...

22. Do not build on singletons
• Traditionally structured companies are managers driven
• Remove a manager and things might fall apart

23. What would it take to create a company that lasts 100 years?
1. Mission
2. Values
3. Purpose
4. Processes
5. People
• that first come together to define and agree on the above

24. Purpose is the key

25. Allows to decide between apples and oranges
• We were running in circle, like dogs eating their own tails.
• We looked back at our mission
• make organizations better at building, maintaining and running complex
software systems
• What does it mean from a single strategy perspective?
• Why do we do what we do as engineers (for example)?

26. Why(s) we do what we do
• to keep the lights on
• so that we’re reliable
• to make the platform easier to maintain
• by improving the way we work and by fixing technical debt we inherently improve
the overall quality
• to make it easier for developers to be successful with the platform
• by removing adoption barriers and providing guidance
• to allow developers spend more of their time delivering business value
• we write the infrastructure that’s missing to them
• to react to a shifting marketplace
• to stay on top of new things and thus we maintain a tech radar

27. Why buckets squads
• There is a squad owning each bucket
• 1 WIP slot each (at the moment)
• Squads have to be proactive and not reactive
• They are less process owners and much more POs, to some extent
• They still define their own internal process
• Each bucket now has
• a completely different and independent speed
• release cadence
• and most importantly different intent.

28. Backlog triage and prioritization
• The initial triage (Inbox + Problem Definition) assigns a bucket
• Bucket squads are free to reject an issue because reasons
• It’s not based on technical details only, if at all
• Looking at a small subset of the issues makes it easier
• The backlog is groomed regularly multiple times a week
• Zoom calls
• Slack dedicated channel
• Discussions on GitHub issues
ProblemDefined

29. Finally we can tackle a problem
• Given 1 WIP slot a problem is selected to be addressed
• Not necessarily in its entirety
• Squad extracts the first solution item, another issue
• Defines required skills
• The goal, typically, is to
• investigate/propose solutions
• define PoA
• Apply a Needs Taskforce label
• Announce it in Slack
NextinLine

30. A Task Force is formed
• Short lifecycle, single responsibility principle.
• Ad hoc skills set
• Might include people willing to learn
• Takes care of everything
• Pick up a solution
• Implement it
• Decide how and when to ship
• How to market it
• They have one or more reviewer, with deep topic knowledge
• RFC is used to gather feedback
• Not only by TFs, every decision is RFCed
InProgress

31. Definition of Done
There is no definition of done. The PoA is.
A retrospective is expected, though.
Done

32. “Best teams spend 50% of their time working,
and the remaining 50% deciding how to work”
Conor Ward

33. Mauro Servienti
Solution Architect @ Particular Software
mauro.servienti@particular.net
//milestone.topics.it
@mauroservienti

34. Thank You!