{"id":393,"date":"2011-07-13T05:34:19","date_gmt":"2011-07-13T12:34:19","guid":{"rendered":"http:\/\/10kdev.ivystreetinc.com\/?p=393"},"modified":"2011-07-13T05:55:41","modified_gmt":"2011-07-13T12:55:41","slug":"iterative-death-march","status":"publish","type":"post","link":"http:\/\/10kdev.net\/?p=393","title":{"rendered":"Iterative Death March"},"content":{"rendered":"<p>I was watching some of my buddies on a project and they have been living in the bowels of hell.\u00a0 They are on an Iterative Death March project.<\/p>\n<p>A Death March Project classically defined is a nightmarish high risk, huge overtime\/grueling work, looming deadline project. Oh, the horror.\u00a0 You can read about it in wikipedia (<a href=\"http:\/\/en.wikipedia.org\/wiki\/Death_march_%28project_management%29\">Death March<\/a>)\u00a0 or in the book that I first remember telling me about this methodology &#8212; <em>Death March <\/em>by Edwartd Yourdon.<em><br \/>\n<\/em><\/p>\n<p>Iterative Death March is the agile version, but repeats itself every sprint <em>and<\/em> for the whole release.\u00a0 The poor participants are doomed to live in hell over and over week by week with more mission critical deadlines.\u00a0 It is much much worse than classic Death March technique, like having your head held underwater repeatedly.<\/p>\n<p>I&#8217;ve been on a few myself.<\/p>\n<p><strong>The Problem<\/strong><\/p>\n<p>Iterative Death March is an agile style that is very common today.\u00a0\u00a0 If you read my post Agile Steamship Part 1, then you can see some of the causes.\u00a0 But basically, for a developer, the experience is like this:<\/p>\n<ul>\n<li>The project is at mission critical according to some higher-up and time is running out towards the deadline.<\/li>\n<li>Hardly any requirements have been fleshed after months, MONTHS, have went by.<\/li>\n<li>Technical expertise was never consulted, and there is no cross-team technical vision or architecture.\u00a0 The same work gets repeated over and over.<\/li>\n<li>There are plenty, PLENTY of PM&#8217;s who partake in daily blamestorming meetings.\u00a0 In fact, before the actual work is done the framework for whom to blame (developers) is well architected and set into place.<\/li>\n<li>Agile is dropped into place so that developers can be blamed more efficiently.\u00a0 By making them put their names on tasks, they are now accountable.\u00a0 But, none of the poor planning and inaction is tracked up to that point.<\/li>\n<li>Bodies all over.\u00a0 Tons of them.\u00a0 People brought in off of projects.\u00a0\u00a0 People with knowledge are reassigned though.\u00a0 new faces with no domain knowledge are brought in.<\/li>\n<li>Due to the bodies the effective people&#8217;s productivity is reduce so they can train them, contributing to blown deadlines.<\/li>\n<li>Bugs are logged on unfinished software before its released creating a faux backlog of yet more work in the way of actually accomplishing something.<\/li>\n<li>Repeat.\u00a0 Iterate in short sprints.<\/li>\n<li>Meeting hell.\u00a0\u00a0 Developers never get more than 20 minutes of contiguous time to actually make the software.<\/li>\n<li>Weekends, holidays, and evenings bled from peoples&#8217; lives on short notice with the classic huge pre-release work spike common to many poorly executed waterfall projects.\u00a0 Just on a nice, short time frame.<\/li>\n<li>Scope on the agreed sprint work is changed mid-sprint making code bad and work lag even more.\u00a0 The about face exerted on development efforts for multitasking like that is well documented and results in 30-60% inefficiency, depending on the circumstances (daily interruptions vs. multitasking on several things.<\/li>\n<li>Attrition and apathy.<\/li>\n<li>Less software.\u00a0 Poorer quality.\u00a0 Higher cost.<\/li>\n<\/ul>\n<p>I have been there.\u00a0 No thanks.\u00a0 Al this crap is in the old Mythical man Month book (from 40 years ago) and still there are teams that don&#8217;t listen.<\/p>\n<p><strong>My Solution<\/strong><\/p>\n<p>Alleviating a management team that will do this to developers has made me no friends, because of a lot of reasons, but mostly because there are other forces like promotions and political power struggles going on outside of the project.\u00a0 Frankly, its annoying.\u00a0\u00a0 But it can be alleviated by taking thee steps:<\/p>\n<ul>\n<li>Make an accountability trail for everyone, this is the trust framework.\u00a0 Culturally this is a huge move.\u00a0\u00a0 Trackable sharepoint for the BA&#8217;s and the PM deliverables WITH tech team signoff.<\/li>\n<li>Bring tech leads in at the start<\/li>\n<li>Plan to the point of paranoia.<\/li>\n<li>Tech team makes a plan to build, and the PM does not control what&#8217;s in it at the tech level as long as it lines up with the business stories and the agreed time-boxed schedule.<\/li>\n<li>If the dates can&#8217;t be hit, don&#8217;t hit them.\u00a0 Nothing in the world is important enough to do a crappy job that does absolutely nothing good for the company while people&#8217;s lives are trashed.<\/li>\n<li>Smaller, more expert tech strike teams.<\/li>\n<li>No new faces during building unless absolutely agreed upon.<\/li>\n<li>NO scope changes mid-sprint.\u00a0\u00a0 The sprint is an agreed contract between the coordinators (PM&#8217;s, business) and the people who know how to build the software (which the PMs and business do not).\u00a0 Changing scope changes outcome, causes attrition.<\/li>\n<li>Ruthless focus on the task at hand.<\/li>\n<li>A well planned, sustainable pace.<\/li>\n<\/ul>\n<p><strong>Last Thoughts<\/strong><\/p>\n<p>I thought about my buddies on that Iterative Death March team, and some of the other personnel and the business unit and realized that the reason these types of projects come about isn&#8217;t because of the project itself, its because of the people.\u00a0\u00a0 That&#8217;s right &#8212; its PEOPLE who create a good or bad atmosphere.\u00a0 We are the ones who fail or succeed at the planning, or the builds, or the scope management.<\/p>\n<p>And that&#8217;s why my best jobs in my career, it was the people who made it great and not the work.\u00a0 If the people are great the work becomes creative, inventive, and effective.<\/p>\n<p>Hmmm.\u00a0 Interesting.<\/p>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>I was watching some of my buddies on a project and they have been living in the bowels of hell.\u00a0 They are on an Iterative Death March project. A Death March Project classically defined is a nightmarish high risk, huge overtime\/grueling work, looming deadline project. Oh, the horror.\u00a0 You can read about it in wikipedia [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts\/393"}],"collection":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=393"}],"version-history":[{"count":4,"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts\/393\/revisions"}],"predecessor-version":[{"id":396,"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts\/393\/revisions\/396"}],"wp:attachment":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=393"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=393"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=393"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}