One of the key selling points of Agile is its built-in support for continuous improvement. Furthermore, within the Agile community, it is recognised that the best people to drive improvement for a team is the team itself. This is one of the reasons retrospectives are crucially important. As a matter of fact, plenty of Agile professionals would claim that retrospectives are THE most important element of Agile.
Over time, we have worked with a large number of teams across a range of organisations. In some cases, retrospectives have been working very well, whilst in others, little or no value come out from the retrospectives. Besides the shape, form and follow-up of the retrospectives themselves, we have realised that some element is missing. The missing element is Agile Metrics. How do you know that your team has improved? Properly used, metrics provide both the driver and evidence for improvement.
When the term Agile Metrics is mentioned, most people would immediately think of things like velocity, burn-down and burn-up charts, bug counts and so on. Furthermore, most team members would probably see metrics as something imposed on them from senior management so that the latter can get visibility and/or control over the teams. Unfortunately, this sometimes means that the metrics provided are not totally truthful, and therefore the value of the metrics becomes deflated.
We work with a range of teams and organisations in turning Agile Metrics into an invaluable tool in the continuous improvement process. Besides changing the perception of metrics, we work with teams in creatively defining metrics that are relevant for the team and the areas in which the team wants to improve.
We typically work with a couple of teams at a time within an organisation. The initial step is to run a workshop with each of the teams with the goal to change the perception of metrics into something very positive and useful. The workshop is highly interactive and we focus on the actual circumstances of the team rather than any theoretic model.
The next step is to work alongside the team in one iteration, helping them define and track some key metrics that are relevant for the team. This may also involve finding ways of tracking the metrics in their existing project tracking system (JIRA, Rally, etc.). At the end of the iteration, we facilitate the retrospective, which will use the metrics as a focal point.
We then work with the team in the subsequent iteration and help them find improvements in terms of engineering and Agile practices, tracking the same metrics that was previously defined. The goal is to be able to show evidence of improvement through the metrics. Again, we facilitate the retrospective and focus on the metrics, comparing the two iterations.
For more information or to schedule a demo please contact usContact us
dsp attended the UK Oracle User Group Partner of the Year Awards last week, and we came away with awards for both categories in which we were nominatedRead more
Join us for lunch and to hear some war stories from staff and customers with experience of Oracle Database Cloud Service. We'll also understand more about the Autonomous Database and how Oracle will compete with AWS.Read more
I’ve seen this question raised about all Cloud providers: you migrate and then WHAM they hike the prices and there isn’t anything you can do about it. We seem to be living in a state of fear!Read more