Workstream process update

--- robots: noindex, nofollow tags: process, in-review --- # Workstream process update ## Summary This process draws inspiration from [Shape Up](https://basecamp.com/shapeup) by basecamp. In particular it draws on the ideas of ["Shaping"](https://basecamp.com/shapeup/1.1-chapter-02) a project before work begins. This is not a proposal to fully adopt the Shape Up process, but instead to draw inspiration from it and apply it to solve some challenges we face. ## Motivation * Workstreams are too vague and ongoing * There is no clear start and end * Features have to be "fit" into Workstreams * Sometimes features span multiple Workstreams * Ongoing areas encourage further investment and time even if it isn't warrented * We desire more clarity * Need to know what work is on going and who is working on it * Need more scoping and consistency on proposed work * Too many workstreams * Makes it feel like all 9 need to be active, which they don't * Sometimes we need to focus on something specific instead ### Organize work primarily around **Projects** - Engineers will no longer join unbounded, long-running **Workstreams** - Engineers will join clear, scoped, time-bound **Projects** - Typically 1-3 engineers per project - Typically 1-3 weeks per project - In ADO - Projects === Features - Can be grouped by Epics in ADO if necessary :::warning OPEN ISSUE: Can we just use GitHub for tracking work? Still open, we can look into this more later. TODO: Setup discussion next week (consider windows terminal, consider typescript, consider vscode, WinUI). If we do sync between both, what is the source of truth? ::: Pulling from the [Big Picture Product Process](/fzE2jx1HSVCy3GNOyS-c9w?both), **Projects** are the way we organize work that will help us meet our quarterly goals (OKRs). Conceptually work is motivated as follows: ```flow ps=>operation: Product Strategy (2-5 years) pr=>operation: Product Roadmap (1 year) okr=>operation: OKRs (3 Months) proj=>end: Projects (3 Weeks) ps->pr->okr->proj ``` ## Details ### What are projects? Projects are (quotes pulled directly from [Shape Up](https://basecamp.com/shapeup/1.1-chapter-02#property-1-its-rough)) - Problems Projects are problem focused. It is clear from the Project description what the problem being solved is and why we need to solve. Any relavent customers are called out. - Rough >Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. - Solved >Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. The work isn’t specified down to individual tasks, but the overall solution is spelled out. While surprises might still happen and icebergs could still emerge, there is clear direction showing what to do. Any open questions or rabbit holes we could see up front have been removed to reduce the project’s risk. - Bounded >Lastly, shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out. > Taken together, the roughness leaves room for the team to resolve all the details, while the solution and boundaries act like guard rails. They reduce risk and channel the team’s efforts, making sure they don’t build too much, wander around, or get stuck. For more information on actually shaping projects see this document: - [Shaping a Project](/kX02SXVbS6KzMOQd56i6Cg) Template for Projects can be found here: - [Pitch template](/GAUYjmVZSNibiTOhxOiQ_w) ### Example Projects - Single react-focus package - Upgrade path w/ codemods - Converge the repos - Dual screen support - Bundle size PR gate - Render time PR gate ## Rhythm of the business ### Background Below are some constraints, desires, history, and examples to help inspire and motivate our rhythm. #### Constraints: - Need to fit within Quarterly OKR cycle - Need to provide status update to Teams bi-weekly sprint cycle - Everyother thursday Teams has a review of what was completed this sprint and what is scheduled for next sprint - Need to fit in within 2 week sprints - Need to provide updates to the Monthly MBR long-running KPIs - Need to publish regular (monthly/bi-weekly?) AOLs #### Desires: - Monthly update to community - Sprint planning meeting for Fluent UI #### History: - We used to send Quarterly communication to Fabric community (newsletter) #### Examples: - [Typescript 3.7 Iteration plan](https://github.com/microsoft/TypeScript/issues/33352) - [VSCode February Iteration](https://github.com/microsoft/vscode/issues/90371) #### ROB Proposal As background, the Shape Up proposes a [6 weeks work 2 weeks catch up](https://basecamp.com/shapeup/2.2-chapter-08#six-week-cycles) cycle. We can't really fit into that schedule as this would make our cycles 2 months long causing issues with the Office Quarterly cycle. Also 6 week long projects would likely cause grief for the Teams 2 week sprints. In order to meet our constraints above and also leverage the Shape Up model, we can: - Use a **3 week focus 1 week catch up** cyle. - Have a **2 week planning meeting** that acts both - An initial meeting to plan and decide on Projects for a cycle - A check-point half way through the cycle to check in on whether Projects are converging as expected The 4 week cycle fits nicely within a month, which is 2 sprints. It also fits cleanly into Quarter for our OKRs and works with the MBR rhythm. The 2 week planning meeting helps us integrate with bi-weekly/sprint cadence that Teams and other folks in Office use. Setup: - **Prior to the first week** - We review pitches for shaped Projects and decide what to focus on for the next cycle - Engineers are fit to Projects depending on needs and thier interests - Planned work is enumerated and communicated to partners The weeks of the cycle: 1. **First week** - Work starts on Projects assigned to this cycle - Engineers are able to focus on work, interuptions are kept to a minimuim - Progress and status is tracked in a single HackMD per project 1. **Second week** - Sprint planning meeting happens - Project leads come report on Project progress - [Shape Up: Show Progress](https://basecamp.com/shapeup/3.4-chapter-12) - Work continues, still heads down 1. **Third week** - Projects complete and area merged/released - Ideally projects complete early this week - If you aren't going to finish early, you're going to finish late - If Projects do go long - There is a week of buffer to finish out - Work to reduce long running projects over time - Discuss why it went over in retrospective 1. **Fourth week** - Hold retrospectives for Projects - Engineers switch to task such as: - Clean up and Refactoring - Bug fixes and code review - Shaping future Projects - Send out an AOL / Communication annoucing the work that was completed - Plan the next cycle - Breathe. ## Drawbacks Potential issues: - Any change has cost. Is introducing this change worth it? - ~~If a project ends very early, or projects do not end at the same time it will be difficult for folks to move to another project~~ (solved by fixed schedule) - Without requiring tasks it will be harder to measure the incremental progress of projects - Partners won't have sprints or task burndown to predict progress - Goal: find a better and more accurate way to provide status