CAJ 012-Bob Woods
Meeting Facts
Speaker: Bob Woods
Topic: Agile Metrics That Mean Something
Date: 6/5/17 4-5 EST
Description:
Many organizations start out their Agile Journey in the same way. They get some education, dip their toes in the water, and then see if it’s going to work out. But, knowing whether or not it’s working out can often be the challenge. Traditional Waterfall measurements don’t apply, and so often we don’t know how to determine whether or not our efforts are being wasted or we are actually improving in our solution delivery. We are being asked to quantify results but we also hear metrics are frowned upon in Agile environments. So how do you know what metrics really matter? Join Robert Woods, National Agile Practice Director for MATRIX, for a deep dive into:
Practical Agile metrics and when to use them
Who is the appropriate audience for various metrics
What methods are available to measure initial successes and failures
How different levels of metrics are used at different Agile maturity stages
Bio:
Robert Woods serves as National Agile Practice Director at MATRIX. Robert began his career in IT Infrastructure as a Sr Engineer and has spent years working with organizations on collaborative Lean development, Agile testing techniques, requirements analysis, project envisioning, and relationship management, Agile within ITSM and Agile leadership. Robert is the creator of the CLEAR (Collaborative, Lean, Evolving, Adaptable, Reportable) Portfolio Management concept and is an author on Agile, Business Process Management, Shared Services, serves as a track chair for Agile2017 and is a regular speaker in the Agile community.
Possible future topics:
How to get executive level engagement and support in agile transformation
Holistic agile (application to agile in the entire business)
Quotes:
“Every team, every company is unique. There is no single metric that fits everyone”
“The more information you give someone, the less likely they are to look at it.”
“I would argue the primary measure of progress is value delivered”
“Being in an agile environment is more about being in continual reflection and improvement than it is about working software” (mindset over process)
“It is inherent that we have this desire to not be measured.”
“I can give people visibility all day long, but that doesn’t mean I’m being transparent”
“When you burn hours, you can have the best looking burndown chat in the world, but it doesn’t mean you have delivered anything… If you are burning points, something actually got accepted and we created some sort of value.”
“With great information comes great responsibility.”
Questions:
What happens if tracking hours and equating them to velocity by management will lead to inflated estimates by the developers? (How do you handle someone looking for the SP=HR formula?)
Answered in meeting
How do you recommend measuring team morale?
This might be the easiest one…just ask. I find retrospectives good for this. As people walk into the room, hand everyone a dry erase marker. On a white board or easel pad, have a chart of some sort (heat chart, line chart, anything) and simply have them place a dot where they feel they are from an overall morale perspective. Talk about it during retro to find out if its true or not and do this on a reoccurring basis to gauge morale over time.
What do you do if a manager/leader is used to viewing a standard set of reports that tell the wrong story?
Show them some reports that tell the truth, the whole truth and nothing but the truth. They will stop believing in the previous reports.
How do you convince leadership that they don’t need the level of detail needed to micromanage/project manage/command & control?
This is something that happens over time. As much as we would like to be trusted from the beginning, trust is generally earned. That’s what a micromanager lacks. So, give them the info they want initially, but over time, see how much can be peeled back based on trust earned.
How do you measure the value of metrics and if they are worth generating/presenting?
This is something that happens over time. As much as we would like to be trusted from the beginning, trust is generally earned. That’s what a micromanager lacks. So, give them the info they want initially, but over time, see how much can be peeled back based on trust earned.
What do you do if the team is trying to game their metrics, not deliver value?
Scale back on the metrics and focus on value delivered as a primary metric. Its hard to game how much value we have delivered from a business perspective. Once they see they are delivering value regularly, introduce more of the nuance based metrics to continue the concepts around continual improvement.
Notes:
Once an agile transformation has been started and the investment is made, the question is asked, “are we better?”
Ask what a person’s personality is, what they want to see and what they need to see so they can understand and value the information you present to them.
Use the hunting concept, “aim small, miss small.”
Don’t create confusion more than sharing great information that will enable the right questions
2 sides to the argument:
We are agile and all that matters is working software
We are a business and we need PNL and ROI that can be measured
If you can’t measure something, then measure it. If you are still unable to measure, try again.
We have to balance between being able to deliver software and value without being burdened with the metrics, but measuring improvement going forward.
Where were you previously, where are you right now, and where do you want to go?
Many failures don’t look at where they were, and therefore if they are improving. If it is rough, then they won’t recognize any improvement (hedgehog concept)
Everyone wants to say that we are an Agile environment… But you can’t do a sniff test. You need to measure your progress
We need to know:
When should we start measuring?
What should we measure?
Who do we share the information with?
Many organizations don’t have cultures that are ok with sharing their mistakes without repercussions
GREAT METRICS
Facilitate conversation
We are only going to look at 2-3 metrics. Don’t try to move the needle on everything all at once
Keep it simple
Make sure you see the value of doing metrics
Use the data for the right reasons
Show on a sprint by sprint basis that you are improving your process and creating a high quality product
Measurements that allow the team to be empowered, accountable and promote constructive self-reflection without fear of retribution
Avoid measurements with no action items
Avoid purely numbers based measurements
Avoid measurements that create work but not conversation
CLEAR
Collaborative
Lean
E
A
R
Keep it simple