Your team, and your teams' goals are the central concepts which this product helps you to manage. Once the team is set up, you'll have the opportunity to identify and track goals as you go.

Setting up a team

	Pick a name for your team and choose a team logo. If you're using our free version, you'll need to use an external URL, or use something like https://websemantics.uk/tools/image-to-data-uri-converter/ to store your image as a data-URI. You can also add and remove team members on this screen.
Following the Score Menu link brings you to a screen where you can enter guidance about how different behaviours equate to points added or subtracted from someone's score. You can set this up now, or wait until you're thinking through what worked well and what could be improved together.

Recording metrics

Our team's home page shows a graph of metrics displayed as a series per team member, displayed over time. The graph is designed to highlight the scores of distinct team members changing over time, as well as the overall state of the team. As we meet to reflect on how things are going, perhaps during a retrospective meeting, we note the behaviours which have helped or hindered achieving our goals and we assign points (positive or negative) to team members responsible.
	When you meet as a team to think about what went well and what can be improved, it can be useful to pick out just one or two behaviours which you want to change over the next iteration. If a member of the team has set a strong example of how you want to behave - lets say "Only one item returned from QA", it's worth creating a Menu item for this behaviour and assigning the item's points to the person in question. You can choose an arbitrary number of points to allocate - choose something which reflects how important this behaviour is in relation to the others listed on your menu. Over time you can reduce the points allocated to a menu item without affecting the score already accrued by team members.

Aside: Points have no inherent meaning except in relation to each other, and are only useful to illustrate trends over time. If that sounds familiar, then you too may use Story Points (or T-shirt sizes) to estimate user stories for Agile iteration planning. For this reason, you can't directly compare one team's score against another (and to do so would be counter productive). Instead, you need to look at the rate of change over time, which illustrates if a team is improving (or not) over time.

When you pick a score from the menu, you get select team members to score negatively or positively against the particular behaviour. Note that there's no sliding scale - you can score the points agreed, or not at all. This is similar to the Agile concept of "Done" - a pre-agreed threshold which establishes a well understood goal.
	You can also approach the scoring process from the other perspective - scoring one team member against all the behaviours currently in the score menu.

Note: if you approach scoring from the perspective of the team member, don't fall into the trap of allocating the same number of menu items to each team member in an attempt to placate individuals.

Of course, not everyone likes to be structured about things. If establishing a menu of fixed behaviours seems overly draconian, you can simply allocate points with a custom description, unlinked to any menu item. This approach can be more effective when you're working with an experienced team who have a lower threshold for "mind-control" ; )

What if there's no change?

If you notice that a team isn't able to implement the changes needed to become high-performing, there are a number of places to look. The team itself is likely to identify circumstances which might be holding it back. Common examples include:

• We have no control over how we do our work, so we can change things for the better
• The business is placing us in an impossible situation - all we're doing is trying to survive

However, you may also hear things like:

• Some people need to be told to pull their weight

or even

• As long as X is on the team, nothing's going to change

Lets be honest for a minute - as software developers, we're often overconfident in our own analysis, especially when it comes to troubleshooting performance. We need to be open and honest about what our gut tells us, and then apply a reasonable level of skeptical analysis so that we identify the real issues which may be holding us back. And remember, we don't always share the same goals. Just because our particular goals aren't achieved doesn't mean the work has been a waste of time.