From the very first time I saw Michael (Doc) Norton present “Let’s Start an Epidemic” at ThatConference, I knew I wanted to get him to come to Chicago to speak at my group. His overall messaging about community, teamwork, and influence was one that needed to be shared with my local community. Timing was on my side, and in December Doc Norton spoke at the Chicago ALM user group, and it was phenomenal! It was the week before Christmas and I had some SERIOUS piles of Microsoft and TFS swag at home to share as well. Including some great, re-sable Visual Studio shopping bags. Check it out, I was a busy elf!
Now, on to the main event. Doc’s talk was on agile metrics, and it was a FULL house. Even snapped a little selfie to prove it :)
You might be thinking “Wait, AGILE metrics??” Did you just shudder in fear, because most agile metrics evoke feelings of big brother and bring back bad memories associated with “earned value management”, and pitting teams against each other. That was NOT what this talk was about. As a matter of fact, the title of his talk was “Velocity is NOT the goal” and I swear I heard a giant sigh of relief when that title went up!
This also may have been one of the first meetings where I saw not a single person on email or YouTube the whole time. The only apps running were OneNote and notepad because people were taking down all kinds of tips and tricks on how to do agile metrics the right way. And this was no small mom and pop shop where you’d think to yourself “of COURSE it was easy for them!” You see, Doc works for Groupon, you may have heard of them. They have gone through exponential growth over their short lifespan, and Doc has been largely in charge of making sure they do not implode culturally along their journey. Some of my favorite ideas from this talk were the Hawthorn Effect/Goodwin’s Law connection,360 reviews, joy meters, and too much work in progress.
The Hawthorn effect is pretty brilliant and absolutely true in my experience. The idea is simple, once people know they are being measured based on a specific behavior, or on their improvement on a specific metric, they will do everything they can (for a time anyway) to continue performing in whatever way they need to in order to hit those measurements. Goodwin’s Law “when a measure becomes a target, it ceases to become a good measure”. Some might call this the “I’m going to code myself a minivan” effect. In other words, metrics can often be gamed, so again, be careful what you wish for when it comes to metrics and reporting.
360 reviews is something we sort of did when I was at Microsoft. Part of your end-of-year review process allowed you to request anonymous feedback from up to 10 people that you worked with throughout the past year, looking for overall ratings as well as personalized feedback. I honestly found it far more valuable to my professional and personal growth than all of the canned metrics we were graded on. 360s allow people to get feedback from a variety of angles, not ONLY from your boss. I also found that it made me feel more personally accountable for being a good team member, knowing that every year I’d be hearing back from my team as to whether or not I had a positive impact on them.
Joy meters provide even more interesting data, though that data can be tricky to collect. essentially, you are asking people to give fairly regular feedback on the joy they receive from doing their job, whether it be team meetings, checking in code, running tests, whatever. Docs example was a bit easier to collect and “enforce”, because a joy rating was required with every code check-in. As a TFS user I can already picture ways of handling that for code check-ins, but collecting it for other types of activities is not as straightforward. As a start, I want to look at adding a joy meter check-in policy to our own internal TFS instance and start crunching numbers!
And this last one is not only a great point, a really GREAT point, but it references one of my favorite “I love Lucy” episodes! But seriously, I can’t tell you how many times I’ve been in a standup near the end of the sprint, where every task is active and very few things are done. But everyone was productive and busy! And yet, the team rarely made it’s sprint goals and their velocity was all over the map.
So, don’t want to steal any more thunder, and Doc said it so much better than I could. If you’re completely kicking yourself for missing the talk, lucky for you it is posted on Vimeo and Doc was more than happy to share it with us. Check it out, it’s well worth your time!