From 114cf000baad89324bd2965138ac8c38997179db Mon Sep 17 00:00:00 2001 From: "Gordon Beeming [SSW]" Date: Mon, 7 Aug 2023 21:34:52 +0200 Subject: [PATCH] Action points from review with Adam (#6250) --- rules/bench-master/rule.md | 78 +++++++++++++++++++++----------------- 1 file changed, 43 insertions(+), 35 deletions(-) diff --git a/rules/bench-master/rule.md b/rules/bench-master/rule.md index 47e5fdd1ccb..be8b01209c8 100644 --- a/rules/bench-master/rule.md +++ b/rules/bench-master/rule.md @@ -26,21 +26,24 @@ In any organization that juggles multiple projects, having clear coordination an A Bench Master's primary responsibility is to ensure that all developers know what they are working on when they are not on client projects. In order to accomplish this, the Bench Master has these responsibilities: -- Responsibility - Allocating a Scrum team to new employees or employees finished on a project - - The Bench Master should make the internal booking for the developer - - Developers should not be switched to new projects shorter than 4 weeks (excluding client bookings) - - Customer bookings would override any internal project bookings - - Customer bookings should be made at least a day in advance -- Responsibility - Maintaining a list of internal projects -- Responsibility - Scrum Master for the Small Projects Team -- Professional development - Allocating people projects based on what they want to learn -- Process - Across all internal projects at a high level -- Process - Knowing the priority of internal projects -- Process - Knowing what skills are required for each project -- Process - Bench Backup - Keep someone in the loop for when Bench Master is unavailable -- Process - Weekly meeting with important stakeholders to talk about priorities -- Process - Office specific morning meeting for anyone not on client work, - - This is for people not already assigned to an internal project or have finished work on an internal project +1. Responsibility - This role is a Bench Masters number 1 responsibility +2. Responsibility - Allocating new employees or employees finished on a project to a Scrum team + - The Bench Master should make the internal booking for the developer + - Tip: Starting on a new project is costly, try not move developers to frequently + - Customer bookings override any internal projects + - Customer bookings should not be last minute, they should ideally be 1 day in advance +3. Responsibility - Maintaining a list of internal projects in priority order +4. Responsibility - Scrum Master for the Small Projects Team +5. Professional development - Allocating people projects based on what they want to learn +6. Coaching - The Bench Master should coach Product Champions around the scrum ceremonies +7. Process - Across all internal projects at a high level +8. Process - Knowing the priority of internal projects +9. Process - Knowing what skills are required for each project +10. Process - Bench Backup - Keep someone in the loop for when Bench Master is unavailable +11. Process - Weekly meeting with important stakeholders to talk about priorities +12. Process - Morning meeting for anyone not on client work + - This is for people not already assigned to an internal project or have finished work on an internal project + - You should make sure this happens across all timezones Some other terms that are commonly used for this type of role are: @@ -53,34 +56,38 @@ Some other terms that are commonly used for this type of role are: ## How do developers know what to work on? -Developers don't like uncertainty, it's important for them to know what projects they'll be working on in-between client projects. Knowing in advance what projects they'll be working on minimizes the time it takes to get up to speed on a project as they could be looped into communications for the project before they start so they have some recent context when they join. +Developers love certainty, it's important for them to know what projects they'll be working on in-between client projects. Knowing in advance what projects they'll be working on minimizes the time it takes to get up to speed on a project as they could be looped into communications for the project before they start so they have some recent context when they join. -As you can imagine there is a lot of information that would be required for a Bench Master to be effective. The following is a list of information that would be useful for a Bench Master to have. +As you can imagine there is a lot of information that would be required for a Bench Master to be effective. The following would be useful for a Bench Master to have: -- **Developers and their skills** - Your CRM likely has this information already, see https://www.ssw.com.au/rules/search-employee-skills/ -- **Developer client bookings** - You can get this information from your staffing report, see https://www.ssw.com.au/rules/know-where-your-staff-are/ +- **Developers and their skills** - Your CRM likely has this information already + - see https://www.ssw.com.au/rules/search-employee-skills/ +- **Developer client bookings** - You can get this information from your staffing report, + - see https://www.ssw.com.au/rules/know-where-your-staff-are/ - **Internal projects** - It's important to know their priorities as well as tech stacks, if it's a big project, knowing the actively developed portions tech stack would be helpful + - see https://www.ssw.com.au/rules/report-bugs-and-suggestions/#tip-5-do-you-make-it-easy-to-find-all-the-backlog-in-your-company - **Developer bench bookings** - Your staffing should be able to tell you which developers are working on which internal projects -This covers the basics of what a Bench Master would need to know, there is other factors that would influence the Bench Master's decisions such as developer personal goals. For example, if a developer wants to learn react, the Bench Master could try place the developer on a project that uses react. +This covers the basics of what a Bench Master would need to know, there is other factors that would influence the Bench Master's decisions such as developer personal goals. For example, if a developer wants to learn React, the Bench Master could try place the developer on a project that uses React. -![Figure: Developers can add Keen to Learn skills in CRM to inform the Bench Master](keen-to-learn-skills.png) +![Figure: Developers can add Keen to Learn skills in CRM | Users | {{ User }} | Skills to inform the Bench Master](keen-to-learn-skills.png) -Here's some inputs the Bench Master would consider for each developer: +Here are some considerations the Bench Master would keep in mind for every developer: -- Client needs - Is there any client work that tentatively needs the developer? -- Internal Projects - What is most important? -- Internal Projects - What teams are looking for a Dev? -- Current skillset -- Time between now and next client? -- Inbox count? see https://www.ssw.com.au/rules/dones-is-your-inbox-a-task-list-only/ -- Check Long Term goal tracker e.g. Trello board, anything important? Anything doable in the time between now and next client? -- Personal Development Time - - e.g. Are there any languages you want to learn? "I want to learn Blazor please" (Bench Master puts person on Blazor project) +1. Client needs - Is there any client work that tentatively needs the developer? +2. Time between now and next client? +3. Inbox count? + - see https://www.ssw.com.au/rules/dones-is-your-inbox-a-task-list-only/ +4. Current skillset +5. Personal Development Time + - Check Long Term goal tracker e.g. Trello board, anything important? Anything doable in the time between now and next client? + - Are there any languages you want to learn? "I want to learn Blazor please" (Bench Master puts person on Blazor project) +6. Internal Projects - What is most important? +7. Internal Projects - What teams are looking for a Dev? ## What happens when the Bench Master is not available? -It's important to have a backup Bench Master in case the Bench Master is not available. +Ensuring seamless continuity of operations in the absence of the Bench Master is essential. - The backup Bench Master should be someone who is familiar with the internal projects and the skills of the developers. - A semi-regular catchup between the Bench Master and the backup Bench Master would be a good idea to ensure that the backup Bench Master is up to date with the current state of the bench. @@ -88,11 +95,12 @@ It's important to have a backup Bench Master in case the Bench Master is not ava - If the Bench Master knows they will be unavailable for a period of time they should ask the backup Bench Master to monitor the distribution list for any emails regarding the bench. ::: info -**Tip:** If you have multiple offices, consider having a local backup Bench Master in every office location +**Tip:** If you have multiple offices, consider having a backup Bench Master that covers each timezone you have an office location ::: ## Limiting the number of internal teams Projects should be broken down according to size and scope: -* Long projects (>4 weeks) with >3 active developers should be run as a separate team. Every standalone project should have a Product Champion. -* Other projects should form a single team. This team is Scrum Mastered by the Bench Master. This allows the developers to maintain adapted process ceremonies and while still working on different products, see [Do you ensure your client projects who don't use full Scrum, at least have a "Mini-Review"?](/who-dont-use-full-scrum-should-have-a-mini-review). This team should adapt the standard Scrum emails ([Do you create a Sprint Review/Retro email?](/do-you-create-a-sprint-review-retro-email)) to send a collective email to internal stakeholders after every sprint. This team should still do a retro as the nature of their more ad-hoc environment will help them be more effective. + +- Long projects (>4 weeks) with >3 active developers should be run as a separate team. Every standalone project should have a Product Champion. +- Other projects should form a single team. This team is Scrum Mastered by the Bench Master. This allows the developers to maintain adapted process ceremonies and while still working on different products, see [Do you ensure your client projects who don't use full Scrum, at least have a "Mini-Review"?](/who-dont-use-full-scrum-should-have-a-mini-review). This team should adapt the standard Scrum emails ([Do you create a Sprint Review/Retro email?](/do-you-create-a-sprint-review-retro-email)) to send a collective email to internal stakeholders after every sprint. This team should still do a retro as the nature of their more ad-hoc environment will help them be more effective.