How do you measure team’s performance and each person’s productivity in an Agile workflow? Questions such as these were asked during our Agile Metrics Webinar few weeks back. XBOSoft and GripQA answers these….
The People Dimension
Q: Can you shed some light on the people dimension? Are you measuring if people are happy? If yes, with what? The product? The quality? The project?
GripQA: The people dimension is usually considered the start of the cycle, the best processes and tools cannot make unhappy people perform well or excellent developers that are highly skilled make any process work. So it often starts with the people, and the most common way to look at people is from a satisfaction perspective, something that is often held are company yearly employee satisfaction questionnaires, the people dimension as implemented in Grip is a bit broader than just employee it’s more organisational aspect where we also look at the health like profitability of a department to make sure there is adequate budget and funds available to put into development, or if profitability is low that might mean that department or the people are under higher levels of stress that you want to avoid.
We also look into people dimension at the stability of a team, so if a lot of people join the team or leave the team or switch departments that might have a negative influence on overall productivity output and maybe even happiness of the team, so a lot of different ways to look at people but it is often regarded as one of the most important ways to improve the team and I think the agile manifesto even starts with the importance of people in an agile development process, so that’s why is the first one in a Grip cycle as well.
Q: how can we prevent team members from gaming metrics, as many companies base yearly raises and bonuses on metrics?
GripQA: Whether to tie metrics to bonuses or not is a Webinar on it’s own! There will always be people gaming the system, and that’s why it’s really important to not design metrics that are focused around being busy, but focus around their specific results that actually contribute to your goal. So for instance if people game the system by delivering higher quality code by all means game the system, because you are delivering higher quality code with less defects! This will get you a better end result in the long term. So as long as you have a combination of well designed metrics and common sense that’s a big part of agile, to have those brief few steps where people talk to each other and evaluate how things are going.
XBOSoft: There’s always going to be people that are trying to game the system so the main point is to really have a balanced approach to metrics and to have a framework that evaluates the different parts of the process and the people. So if somebody’s bonus is on certain metrics we like to have a more overall view of the result rather than particular piece of measuring as Kamiel said on what their doing…’busyness’.