SlideShare a Scribd company logo

Shipping code is not the problem, deciding what to ship it is!

•Download as PPTX, PDF•
•
Mauro Servienti
Mauro Servienti

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.

Related slideshows

Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...
Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...
Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...
 
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019
 
No Projects - Beyond Projects (Refreshed version)
No Projects - Beyond Projects (Refreshed version)No Projects - Beyond Projects (Refreshed version)
No Projects - Beyond Projects (Refreshed version)
 
1 of 34
Shipping code is not the problem 29 marzo 2018 Sponsored by Deciding what to ship, it is!
More than 95% of your organization's problems derive from your systems, processes and methods, not from individual workers. Peter Scholtes
There is no such a thing as “wrong people”. It’s only “right people in the wrong place” Udi Dahan
What do we do? A brief introduction
A product, not really. A framework • We must be reliable • Our customers are not end users • They count on us to build things
We’re quality driven
We’re quality driven Move fast and break things lowers, or might lower, the quality barrier
We have no deadlines
We have no deadlines It'll be shipped when it'll meet the quality bar, no earlier
We have no estimates
We have no estimates money overlooks everything else, making you blind
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…
Apples and Oranges
Apples and Oranges Agile processes address execution problems not backlog prioritization ones
Backlog prioritization …a nightmare that comes true
the larger the backlog the nicer the graveyard
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
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
Hold on! What’s a squad?
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
We have an obsession...
Do not build on singletons • Traditionally structured companies are managers driven • Remove a manager and things might fall apart
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
Purpose is the key
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)?
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
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.
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
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
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
Definition of Done There is no definition of done. The PoA is. A retrospective is expected, though. Done
“Best teams spend 50% of their time working, and the remaining 50% deciding how to work” Conor Ward
Mauro Servienti Solution Architect @ Particular Software mauro.servienti@particular.net //milestone.topics.it @mauroservienti
Thank You!

More Related Content

Shipping code is not the problem, deciding what to ship it is!

  • 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
  • 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…
  • 14. Apples and Oranges Agile processes address execution problems not backlog prioritization ones
  • 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
  • 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

Editor's Notes

  1. It works very well for end user facing companies Facebook, Flickr, part of Google, Twitter, etc…
  2. It works very well for end user facing companies Facebook, Flickr, part of Google, Twitter, etc…
  3. they are clueless if your goal is quality only
  4. they are clueless if your goal is quality only
  5. estimates as a way to compare things brings money on the table, and money overlooks everything else, making you blind
  6. estimates as a way to compare things brings money on the table, and money overlooks everything else, making you blind
  7. Do you remember the queue length one?