A Team Cut Story

At upday we challenge ourselves to achieve technical excellence and a strong understanding of business needs. Due to external and internal circumstances we have quite a volatile team setup. At least each quarter we change either the team members, the PO or the whole structure of our teams - from horizontal to cross-functional to fluent and back again. However our goal is to have stable teams with a clear business orientation while also enabling team members to grow technically and to support each other (eg. reviews, testing, tech discussions).

It is the challenge for each team member to adapt quickly to new teams, different skill sets and goals. I would like to share how we approach building stronger teams and to have a checklist for myself when a new team is set up:

As a Product Owner I want to set up teams quickly and efficiently in order to get them up ‘n’ running fast and deliver the highest business value.

Acceptance Criteria:

• Project goals are set for the next quarter
• Team set up is agreed with agile coach / scrum master / team-cut captain
• Team alignment canvas session defines:
  • communication tools (Slack, Skype, email etc.)
  • planning and progress meetings (Jira, Trello)
  • roles, component owner, facilitator, lead
  • team agreement
• Depict the process the team is improving on a story map
  • map projects
• Calculate the CD3 (cost of delay divided by duration) and WSJF (weighted short jobs first) with the team.
• PO-team choose projects based on CD3 and/or WSJF
• Feedback from stakeholders is collected on a confluence page
• Epics for projects define clearly user/business value and metrics, objectives and key results (OKRs) to measure the success of an epic.
• External team members are invited to groomings to make upcoming changes transparent early on and to final reviews to identify potential follow up stories

We already made several experiments with the team setup without really being able to measure the outcomes. We also realised that not all our needs are covered by the existing experiments. We decided to measure the success of teams via following KPIs (introduced by Martin Fowler DevOps state of report 2014):

• Cycle time
  • How often do we deploy to production?
  • How much time does it take for a feature from done to production?
• Team happiness

It’s also interesting to visualise the amount of meetings we have, to see how effectively we communicate and how much ‘focus time’ is left for each sprint.

In the next article about team cut we will follow up on our latest experiment (running for 3 months) - particularly on the initialisation of the team work and how exactly we measure our experiment KPIs.

What are your experiences in terms of team cuts and measuring team performance?