High performance teams - A quick guide
- 1. High performance teams A quick guide
- 3. DORA State of DevOps report DORA: DevOps Research and Assessment (link) Founders: Nicole Forsgren VP research & strategy GitHub Gene Kim Multiple award-winning CTO, researcher and author
- 4. DORA State of DevOps report DORA report measures the performance of teams based on, summarized: - Deliver frequency: - High performance: Once a day/week - Elite performance: Several times a day - Incidences frequency & time to restore - High performance: Less than 15% frequency, 1 day to restore - Elite performance: Less than 15% frequency, 1 hour to restore
- 8. Performance deterioration factors - Product ownership - Low research on next steps - Incomplete knowledge of the product - Wide and/or abstract stories - Dependencies - Department isolation - Poor prioritization - Interruptions - Indicences - Sudden prioritization changes - Meetings - Development process blocks - Dependencies - Knowledge silos - Branch-based development, PRs - QA in test environments
- 9. Performance improvement factors - Product ownership - Shared big picture of the past, present and future of the product - Deep knowledge of the product - Narrow scoped, well documented user stories - Transversal and fluid communication - Appropriate prioritization - Minimizing interruptions - Take actions to minimize incidences - Minimize meetings - Meetings have a specific scope and timebox - Development process - Shared ownership of the code - Trunk-based development - Testing in production environment - Continuous learning and application of best practices
- 11. Section: Project Contains the big picture of the whole project in the form of “Epic” stories. Backlog - Ideas under construction Accepted - Feasible Epics, in order of prioritization ToDo - Epics that have been splitted into User Stories Doing - Epics that are under development Done - Epics deployed in production
- 12. Section: Product Contains the User Stories that are caused by Epics. Backlog - Ideas under construction Accepted - Feasible User stories: After research and conversations among implied departments, the ideas become feasible User Stories. - The User Stories in this column are prioritized but will not be implemented immediately. ToDo - User Stories that will be implemented during the current sprint. - Ideally, the US in this column have been splitted into Technical Tasks. Doing - US under construction Done - US deployed in production - If there is a not-blocking incidence related to a deployed US, open an Issue related to the Epic. The Issue is prioritized and travels from left to right, just like any other US - It there is a blocking incidence related to a deployed US, open a Bug related to the Epic. Bugs have maximum priority over any other development, because they are interrupting the service. If the incidence is not interrupting the service, then it is an Issue, not a Bug.
- 13. Section: Development Contains the Technical Tasks that are caused by User Stories. Backlog - Technical Task that are being drafted. Accepted - Feasible Technical Tasks: The development team meets to split the US into concise steps that are described in very narrow scoped tasks. ToDo - Technical Tasks that will be implemented immediately. Doing - Technical Tasks under construction. Done - Technical Tasks that have been deployed to production.
- 14. Thank you!