{"id":329,"date":"2008-02-10T14:46:43","date_gmt":"2008-02-10T18:46:43","guid":{"rendered":"http:\/\/judykat.com\/ken\/2008\/02\/10\/dont-justify-agile-based-on-productivity\/"},"modified":"2008-02-10T14:47:47","modified_gmt":"2008-02-10T18:47:47","slug":"dont-justify-agile-based-on-productivity","status":"publish","type":"post","link":"https:\/\/judykat.com\/ken-judy\/dont-justify-agile-based-on-productivity\/","title":{"rendered":"Don’t Justify Agile Based on Productivity"},"content":{"rendered":"

Iteration Burndown by kjudy<\/a>Did I measure “hard numbers” to demonstrate increased productivity with Scrum\/XP? No.<\/p>\n

…and that’s a good thing.<\/p>\n

The tyranny of metrics.<\/strong> <\/p>\n

Metrics have unintended consequences. Particularly when they justify incentives or affect people’s workplace. In the short term, performance improves regardless of what you measure. Over time, behavior distorts in ways you don’t want.<\/p>\n

What to measure?<\/strong> <\/p>\n

Lines of code<\/em>? What a terrible measure of productivity! Is “thethethethethe” 5x’s more valuable than “the”? I know it takes longer to copy edit.<\/p>\n

Function points<\/em>? Who has access to a qualified function point counter? Is 6 fp’s more productive than 10 fp’s? What if I only need 4 fp’s to get my job done?<\/p>\n

Velocity<\/em>? Too many agilists fall into the trap of thinking of velocity as something objective.<\/p>\n

Example: A team of three performs 40 story points in one sprint. A team of ten does 50. Which team is more productive? <\/p>\n

If the teams estimate in isolation, work on different types of projects or if the sprints were months apart the appropriate answer is, “who knows.” <\/p>\n

People will adjust their sense of how long things take over time and in response to change. That’s good. 1pt <> 1pt. 1hr <> 1hr.<\/p>\n

Velocity is a feedback mechanism for the team – a way of informing their own intrinsic motivators and refining gut estimation. Burndown is an early warning mechanism for iterations or releases. Leave it at that. <\/p>\n

What’s my baseline?<\/strong><\/p>\n

Rigorous tracking is a hard-won part of agile adoption itself. I have no “before” to compare to an “after”.<\/p>\n

Small businesses are volatile. Our team grew and our work changed dramatically during the course of our agile adoption. <\/p>\n

We have better things to do.<\/strong><\/p>\n

Measurement is an overhead. Tracking a backlog and velocity are enough.<\/p>\n

There are better reasons to adopt agile.<\/strong><\/p>\n

We sought improved customer satisfaction, reduced risk, improved quality, incremental delivery, and innovation. We obtained other benefits including: great recruiting and retention, rapid professional development, high employee engagement. [I’ll go over these benefits in a future post.]<\/p>\n

Be the change<\/strong><\/p>\n

I saw an XP experience report by a big BPM vendor. Even they didn’t have quantitative metrics to support their adoption. Why? Because the reasons above apply to big companies as well.<\/p>\n

If nothing else, agile practice should shorten our patience for doing things we know don’t add value. Re-frame the conversation.<\/p>\n","protected":false},"excerpt":{"rendered":"

Did I measure “hard numbers” to demonstrate increased productivity with Scrum\/XP? No. …and that’s a good thing. The tyranny of metrics. Metrics have unintended consequences. Particularly when they justify incentives or affect people’s workplace. In the short term, performance improves … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":2444,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[8],"tags":[19,492,878,22],"class_list":["post-329","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-scrum","tag-agile-software-development","tag-bpm","tag-scrum","tag-xp"],"aioseo_notices":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"https:\/\/judykat.com\/ken-judy\/wp-content\/uploads\/2011\/02\/agileadoption013.png","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/judykat.com\/ken-judy\/wp-json\/wp\/v2\/posts\/329","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/judykat.com\/ken-judy\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/judykat.com\/ken-judy\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/judykat.com\/ken-judy\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/judykat.com\/ken-judy\/wp-json\/wp\/v2\/comments?post=329"}],"version-history":[{"count":0,"href":"https:\/\/judykat.com\/ken-judy\/wp-json\/wp\/v2\/posts\/329\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/judykat.com\/ken-judy\/wp-json\/wp\/v2\/media\/2444"}],"wp:attachment":[{"href":"https:\/\/judykat.com\/ken-judy\/wp-json\/wp\/v2\/media?parent=329"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/judykat.com\/ken-judy\/wp-json\/wp\/v2\/categories?post=329"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/judykat.com\/ken-judy\/wp-json\/wp\/v2\/tags?post=329"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}