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 firmly established itself as one of the UK’s fastest growing proactive Database MSPs during 2016, signing £2.1m of new contracts and making its second acquisition, the Oracle DBA support division of IT Services provider ITSB.Read more
A main goal... how to future proof your applications environment through Oracle while becoming more efficient in terms of costs and productivity.
As well as the option of developing the fundamental steps you need to take to get ...Read more
In the age of big data, public cloud, private cloud it’s easy to be pushed into constantly thinking about the future... What should you optimise though and how can you be sure it’ll make a difference? Would knowing it could give you a competitive edge be worth considering?Read more