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…
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
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
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
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