1. Challenges:
1.1. Squad
1.1.1. C1: Squad is able to articulate their capacity for capacity planning purposes and estimates lie within reasonable tolerances
1.1.1.1. Why important?
1.1.1.1.1. Better forecasting and capacity planning
1.1.1.1.2. Increased trust with customers
1.1.1.1.3. Better comms and visibility of progress and timeframes
1.1.1.2. Awesome looks like:
1.1.1.2.1. Squad is able to predict how many user stories it can deliver in an 'average' Iteration
1.1.1.2.2. Actuals match predictions
1.1.1.3. Current state looks like:
1.1.1.3.1. no squad has a clear view of their capacity?
1.1.1.4. Success measures:
1.1.1.4.1. Squad is able to:
1.1.1.4.2. 3/4 of epics and user stories are completed within time estimation including risk factor
1.1.1.5. Possible actions:
1.1.1.5.1. Each squad:
1.1.2. C2: Squad can clearly define daily progress against customer outcomes and goals
1.1.2.1. Why important?
1.1.2.1.1. builds trust with customer
1.1.2.1.2. allows us to understand who we should be looking to help
1.1.2.1.3. helps provide direction and focus
1.1.2.1.4. goals provide a sense of achievement
1.1.2.2. Awesome looks like:
1.1.2.2.1. Squad focuses on delivering one user story at a time
1.1.2.2.2. Squad works on a user story (end-to-end) for a single Iteration only
1.1.2.2.3. A user story is clearly aligned to a customer outcome
1.1.2.3. Current state looks like:
1.1.2.3.1. many different variations
1.1.2.3.2. user story tend to span multiple Iterations?
1.1.2.4. Success measures:
1.1.2.4.1. All interested stakeholders can quickly assess and understand:
1.1.2.4.2. Customer is able to articulate the outcome for each user story
1.1.2.4.3. Squad has no more than two user stories in progress at any one time
1.1.2.5. Possible actions:
1.1.2.5.1. Weekly cadence towards: planning, daily standup, review, retro
1.1.3. C3: Squad has an excellent knowledge of Codebots capabilities
1.1.3.1. Why important?
1.1.3.2. Awesome looks like:
1.1.3.2.1. Each squad member understand codebots platform a-z
1.1.3.3. Current state looks like:
1.1.3.3.1. mixed understanding
1.1.3.4. Success measures:
1.1.3.4.1. Each squad member is able to train newcomers on all codebots capabilities
1.1.3.5. Possible actions:
1.1.3.5.1. fortnightly training sessions focused on a single codebots capability ran by a different person each time
1.1.4. C4: Squad contributes to Codebots platform
1.1.4.1. Why important?
1.1.4.2. Awesome looks like:
1.1.4.2.1. Squads are contributing to the Codebots platform every Iteration
1.1.4.3. Current state looks like:
1.1.4.3.1. some squads contributing, some less
1.1.4.4. Success measures:
1.1.4.4.1. Each squad contributes at least once to Codebots platform
1.1.4.4.2. Each squad has an explicit Codebots target for each Iteration
1.1.4.5. Possible actions:
1.1.4.5.1. put in place a Codebots target goal for each squad per Iteration
1.1.5. C5: Squad can interact easily with the customer/users
1.1.5.1. Why important?
1.1.5.2. Awesome looks like:
1.1.5.2.1. Squad has easy access to experts and users from partner
1.1.5.2.2. Person provided by partner has a Product Manager profile
1.1.5.3. Current state looks like:
1.1.5.3.1. mixed bag
1.1.5.4. Success measures:
1.1.5.4.1. Squad can get their questions answered in seconds and minutes
1.1.5.5. Possible actions:
1.1.5.5.1. Look to collocate squads with customers once or twice a week where possible
1.1.5.5.2. Look to promote user testing early
1.1.5.5.3. Clearly set an expectation for a Product Manager with partner
1.1.6. C6: Squad has the capability to deliver early and often
1.1.6.1. Why important?
1.1.6.2. Awesome looks like:
1.1.6.2.1. Squad has capability to deliver to production daily
1.1.6.3. Current state looks like:
1.1.6.3.1. would be interesting to see deployment stats
1.1.6.4. Success measures:
1.1.6.4.1. positive trends for 2 metrics
1.1.6.5. Possible actions:
1.1.6.5.1. put in place those 2 metrics for each squad
1.1.7. C7: Squad has sufficient resilience to meet the 2 bus rule
1.1.7.1. Why important?
1.1.7.2. Awesome looks like:
1.1.7.2.1. Two members of squad are incapacitated (e.g., get hit by a bus) and squad is still able to deliver it's Iteration commitment
1.1.7.3. Current state looks like:
1.1.7.3.1. Matt and squad X mitigate the buses
1.1.7.4. Success measures:
1.1.7.4.1. No squad misses a Iteration commitment due to absentees over a reasonable period
1.1.7.5. Possible actions:
1.1.7.5.1. metrics on Matty and squad X usage
1.1.7.5.2. expertise matrix
1.1.8. C8: Squad builds quality in
1.1.8.1. Why important?
1.1.8.2. Awesome looks like:
1.1.8.2.1. issues are addressed as soon as they arise (while they are still small)
1.1.8.2.2. root cause analysis is performed on problems (where appriopriate)
1.1.8.2.3. particular focus is given to bridging the gap with the customer expectations
1.1.8.3. Current state looks like:
1.1.8.3.1. it would be nice to see any quality metrics/plan already in place
1.1.8.4. Success measures:
1.1.8.4.1. positive trends for 2 metrics
1.1.8.5. Possible actions:
1.1.8.5.1. put in place those 2 metrics for each squad
1.1.8.5.2. define a quality plan for each squad
1.2. Squad Member
1.2.1. C9: Squad member has a development plan that matches his/her need for expertise uplift and aspiration
1.2.1.1. Why important?
1.2.1.2. Awesome looks like:
1.2.1.2.1. Everyone has a development plan that energises them and allows them to grow
1.2.1.3. Current state looks like:
1.2.1.3.1. Everyone has a scorecard, which can be also be used as a dev plan
1.2.1.4. Success measures:
1.2.1.4.1. Everyone fully buys into their dev plan
1.2.1.5. Possible actions:
1.2.1.5.1. 1-to-1 sessions to build dev plans for each person
1.2.2. C10: Squad member has a consistent understanding of the WorkingMouse way of working, processes, procedures and systems
1.2.2.1. Why important?
1.2.2.2. Awesome looks like:
1.2.2.2.1. Everyone has fully internalised the WM way of working
1.2.2.3. Current state looks like:
1.2.2.4. Success measures:
1.2.2.5. Possible actions:
1.2.2.5.1. showcase our way of working
1.2.2.5.2. handbook
1.2.2.5.3. standard operating procedures
1.2.3. C16: Squad member has pain points removed over time
1.2.3.1. Why important?
1.2.3.2. Awesome looks like:
1.2.3.3. Current state looks like:
1.2.3.4. Success measures:
1.2.3.5. Possible actions:
1.3. Customer
1.3.1. C11: Customer understands the cost of not validating assumptions early and blindly following a wish list and initial plan
1.3.1.1. Why important?
1.3.1.2. Awesome looks like:
1.3.1.3. Current state looks like:
1.3.1.4. Success measures:
1.3.1.5. Possible actions:
1.3.1.5.1. sell advantages
1.3.2. C12: Customer does NOT like either Fixed Price nor T & Ms options
1.3.2.1. Why important?
1.3.2.1.1. Hypothesis:
1.3.2.2. Awesome looks like:
1.3.2.2.1. Customers are given a sliding scale according to their risk appetite
1.3.2.3. Current state looks like:
1.3.2.3.1. T&M or Fixed Price options only
1.3.2.4. Success measures:
1.3.2.4.1. Increased customer satisfaction around pricing model
1.3.2.5. Possible actions:
1.3.2.5.1. Introduce shared risk pricing model
1.3.3. C13: We have a shared understanding of our value proposition (customer + squads)
1.3.3.1. Why important?
1.3.3.2. Awesome looks like:
1.3.3.2.1. Customers are able to articulate how much faster, better and cheaper we can deliver solutions compared to our competitors
1.3.3.3. Current state looks like:
1.3.3.4. Success measures:
1.3.3.5. Possible actions:
1.4. Operating Model
1.4.1. C14: There is minimal re-learning over the life of a project
1.4.1.1. Why important?
1.4.1.2. Awesome looks like:
1.4.1.2.1. Same people involved throughout project
1.4.1.3. Current state looks like:
1.4.1.3.1. Potentially different people involved during brief, scope and development
1.4.1.4. Success measures:
1.4.1.5. Possible actions:
1.4.1.5.1. Remove Scope stage for T&M model
1.4.2. C15: We can onboard new members and squads at a high rate
1.4.2.1. Why important?
1.4.2.2. Awesome looks like:
1.4.2.3. Current state looks like:
1.4.2.4. Success measures:
1.4.2.5. Possible actions: