Prioritization across engineering

Get Started. It's Free
or sign up with your email address
Prioritization across engineering by Mind Map: Prioritization across engineering

1. Given WIP not enough resources to address challenges and complete planned work

1.1. Result

1.1.1. Uneccesary slow and complex development

1.1.2. Re-work

1.1.3. Train as fast as slowest team

1.1.4. Not making planned progress towards roadmap

1.1.5. Frustrated engineers

1.1.6. Strained relationships

1.1.7. Not improving as a collective

2. Emerging challenges / issues developers face

2.1. Examples

2.1.1. Service Bus Issue

2.1.2. Struggle with installers

2.1.3. TestArchitect ID issue

2.1.4. Nuget package dependencies and granularity

2.2. What are these ?

2.2.1. Risks - possible delay in planned work

2.2.2. Definite delay in planned work

2.2.3. Risk to program

2.2.4. treat as incidents

2.2.5. Risk - a situation involving exposure to danger.

2.2.6. Risking - expose (someone or something valued) to danger, harm, or loss.

2.2.7. Incident - an important topic or problem for debate or discussion.

2.2.7.1. No, need actions

3. Capture these challenges

3.1. Shared doc accessible to all SMs at a minimum

3.1.1. Scrum of scrums board?

3.1.2. Entries can be made when issue occurs

4. Traige and address challenges

4.1. Most if not all relates to and can be solved by these 3 groups :

4.1.1. Architecture

4.1.2. DevOps

4.1.3. SkyNet

4.2. Task force

4.2.1. Members MUST have experience in 1< of the 3 areas

4.2.2. SkyNET have 1 developer with this experience

4.2.3. Suggestion : take from development teams

4.2.4. Meet weekly and review challenges

4.2.5. Results, solutions, updates to feed back into SoS

4.2.6. Should overlap with what Brian is doing

4.3. Triage

4.3.1. Impartial decision required

4.3.2. Need common language to communicate urgency

4.3.2.1. Span technologies

4.3.2.2. Span teams

4.3.2.3. Generic language

4.3.2.4. Decision matrix

4.3.2.5. Idea came from having knowledge silos in DevOps but still need tom prioritise

4.3.2.6. A number, color to communicate urgency and impact to PO if need architecture for example

4.3.2.7. Use to make case for capacity across program

4.3.3. Decision Matrix

4.3.3.1. Severity

4.3.3.2. Treat as risks as they are to delivery

4.3.3.3. Impact

5. Weighted scoring model

5.1. COWS method : all the information you should come up with in order to make an impartial decision:

5.1.1. C = Criteria

5.1.1.1. Create hierarchy of decision criteria = decision model

5.1.2. O = Options

5.1.2.1. Identify options, also called solutions or alternatives.

5.1.3. W = Weight

5.1.3.1. Assign a weight to each criterion based on its importance in the final decision

5.1.4. S = Scores

5.1.4.1. Rate each option on a ratio scale by assigning it a score or rating against each criterion.