{"id":251,"date":"2012-12-10T17:47:56","date_gmt":"2012-12-11T01:47:56","guid":{"rendered":"http:\/\/zuill.us\/WoodyZuill\/?p=251"},"modified":"2019-09-03T13:09:28","modified_gmt":"2019-09-03T21:09:28","slug":"no-estimate-programming-series-intro-post","status":"publish","type":"post","link":"https:\/\/zuill.us\/WoodyZuill\/2012\/12\/10\/no-estimate-programming-series-intro-post\/","title":{"rendered":"No Estimate Programming Series &#8211; Intro Post"},"content":{"rendered":"<p>One little blog post cannot even begin to explore this complex subject.\u00a0 Here is a start at beginning the first part. Or perhaps, a pre-beginning.<\/p>\n<p>If you really want to figure this out quickly\u00a0don&#8217;t wait for me to figure out how to write about this.\u00a0 Just come and visit me sometime and I can quickly show you the whole thing.\u00a0 It really isn&#8217;t hard.\u00a0 Or, even easier, read the Agile Manifesto Values and Principles.\u00a0 It&#8217;s all there.<\/p>\n<h4>A Few Paragraphs You Don&#8217;t Need To Read<\/h4>\n<p>It&#8217;s obviously not my job to tell you (teach you, show you,\u00a0 guide you, coach you, whatever) how to be effective at software development.\u00a0 My job is to write software, and coach and work on\u00a0a team that is writing software &#8211; and to deploy that working software so people can use it.<\/p>\n<p>I don&#8217;t write books, sell certifications, do trainings, or provide workshops for a living. I have nothing to sell you. [I&#8217;ve occasionally done introductory sessions about Agile stuff for a company or two.\u00a0 I love doing that, but it is not my living or my job.\u00a0]<\/p>\n<p>The\u00a0company we work for makes irrigation products. Great company, great team, great product.\u00a0 I truly love being able to come in to work every day to be with my team and do the work we do.\u00a0 Point is: I make software for a living.<\/p>\n<h4>Estimates are NOT a deliverable<\/h4>\n<p>Regardless of how we define &#8220;estimate&#8221;*, it is not a deliverable in the world of software development.\u00a0 I&#8217;ll write another post about that if you don&#8217;t agree .\u00a0 (That&#8217;ll show you!)<\/p>\n<h4>The Basic &#8220;No Estimates&#8221; Approach<\/h4>\n<p>Here are the basics &#8211; in very simplified form told as a mini\u00a0&#8220;case study&#8221;, based on a real situation from a long while back\u00a0 (not my current job) &#8211; but I&#8217;ve changed the details so no one will get mad.<\/p>\n<h4>Players:<\/h4>\n<ul>\n<li><strong>Boss<\/strong> &#8211; you can think of Boss as the &#8220;Product Owner&#8221;, &#8220;Customer&#8221;, or &#8220;User&#8221; or some <strong>combination<\/strong> of these.\u00a0 In any case,\u00a0Boss is a &#8220;person(s)&#8221; who knows enough about the purpose of the software\u00a0(or some part)\u00a0to make reasonable decisions, and who is responsible and has authority\u00a0for making those decisions.<\/li>\n<li><strong>Woody<\/strong> &#8211; you can think of Woody as the person who guides the software development process &#8211; could be a devleoper on the team, or some other person who understands software development better than I do.\u00a0We&#8217;ll call him Woody.<\/li>\n<li><strong>Team<\/strong> &#8211; everyone else working on this &#8220;project&#8221;.<\/li>\n<\/ul>\n<h4>History:<\/h4>\n<ul>\n<li>This was a\u00a0while back, but\u00a0Woody was already capable at\u00a0&#8220;No Estimates\u00a0Software Development&#8221;.<\/li>\n<li>This project was a new &#8220;internal&#8221;\u00a0application.<\/li>\n<li>Project accessed existing databases, but also would likely need it&#8217;s own database.<\/li>\n<li>Boss\u00a0had never worked with No-Estimate Software Development.<\/li>\n<li>There was a lengthy &#8220;requirements document&#8221;. It was believed that everything in the requirements doc was necessary. [Note: It was a mess, and if I had any influence I would have abandoned it].<\/li>\n<li>Team had all necessary skills and knowledge to do this work.<\/li>\n<\/ul>\n<h4>Approach for day one:<\/h4>\n<ul>\n<li>Start with\u00a0the huge list of way too much stuff that Boss says needs to get done (the original requirements doc, so to speak).<\/li>\n<li>\n<div style=\"text-align: left;\">Ask Boss to select one &#8220;small&#8221; thing that she felt was very important.<\/div>\n<\/li>\n<li>\n<div style=\"text-align: left;\">That &#8220;small&#8221; thing becomes the &#8220;thing we are working on right now&#8221;: We&#8217;ll call it a &#8220;Story&#8221;, but on this job we didn&#8217;t use words like story.\u00a0 We called them features.<\/div>\n<\/li>\n<li>\n<div style=\"text-align: left;\">Team starts work on the Story.<\/div>\n<\/li>\n<\/ul>\n<h4 style=\"text-align: left;\">Approach for day two and each day after that:<\/h4>\n<ul>\n<li>\n<div style=\"text-align: left;\">Team works on the thing we are working on right now.\u00a0 Nothing else.<\/div>\n<\/li>\n<li>\n<div style=\"text-align: left;\">Team constantly assesses the work we are doing, and splits the current Story if it is not easy to understand or it is not clear how to start on it.\u00a0 We check with Boss, but have no issue breaking things down.<\/div>\n<\/li>\n<li>\n<div style=\"text-align: left;\">Team asks questions as soon as they come up, and get the\u00a0answers right away.\u00a0 Without this, projects drag on through endless muck.<\/div>\n<\/li>\n<li>\n<div style=\"text-align: left;\">Team completes the Story we are working on right now\u00a0(or the part of the Story that we split off)<\/div>\n<\/li>\n<li>\n<div style=\"text-align: left;\">Team deploys the Story\u00a0if it is deployable, and if it is not deployable then Team works with\u00a0Boss to understand what needs to be added to it to make it deployable, does that, and then deploys.<\/div>\n<\/li>\n<li>\n<div style=\"text-align: left;\">Team asks Boss to pick the next thing she thinks is very important.\u00a0\u00a0It can be the other part of the previous story, or any other thing she thinks is important.<\/div>\n<\/li>\n<\/ul>\n<h4 style=\"text-align: left;\">Result:<\/h4>\n<ul>\n<li>\n<div style=\"text-align: left;\">First deployment happened in a little over a week.<\/div>\n<\/li>\n<li>\n<div style=\"text-align: left;\">Project was deemed &#8220;done&#8221; in about a month and a week.<\/div>\n<\/li>\n<li>\n<div style=\"text-align: left;\">As we started delivering usable software, the users and Boss started asking for different things than had been described in the requirements document.\u00a0 The users and Boss started fine tuning what we had delievered &#8211; noting things that they wanted to be done differently.\u00a0 This is a valuable and wonderful thing.\u00a0 This is how requirements emerge.<\/div>\n<\/li>\n<li>\n<div style=\"text-align: left;\">After about one quarter of the &#8220;features&#8221; described in the requirements list\/document (including\u00a0the additions the users and Boss had asked for),\u00a0Boss decided the project was &#8220;done enough&#8221;.\u00a0 The users were doing most of what they needed, and the rest wasn&#8217;t important enough to do, at least for the time being. There were other more important things to get done on another project.\u00a0 The users were happy. Boss was happy. Team was happy. Woody was happy.<\/div>\n<\/li>\n<li>\n<div style=\"text-align: left;\">Team was iterating (but not time-boxed), and incrementally delivering.<\/div>\n<\/li>\n<\/ul>\n<h4 style=\"text-align: left;\">Observations:<\/h4>\n<ul>\n<li>\n<div style=\"text-align: left;\">Boss wanted estimates, and also wanted the work done as quickly as possible.\u00a0 I made the case that we could try to get some critical feature into production ASAP, and then revisit the idea of estimates later.\u00a0After the first deployment, no requests were made for\u00a0estimates.<\/div>\n<\/li>\n<li>\n<div style=\"text-align: left;\">Estimates are part of the &#8220;comprehensive documentation&#8221; that we value less than &#8220;working software&#8221;.\u00a0 If you don&#8217;t see that &#8211; please let me know.<\/div>\n<\/li>\n<li>\n<div style=\"text-align: left;\"><strong>I am sure you saw the big win, right?<\/strong>\u00a0We discovered the needed features.\u00a0Most of what was thought to be needed was not actually needed.\u00a0 Doing the work of writing the code in small pieces and getting it into real use made it possible to steer the work.\u00a0 This is the &#8220;requirements emerge&#8221; concept.\u00a0 I urge you and encourage you to think about it and experiment with it.\u00a0 It is GOLDEN.<\/div>\n<\/li>\n<li>\n<div style=\"text-align: left;\">Even if estimates were not liars, we just simply did not need them.<\/div>\n<\/li>\n<\/ul>\n<h4 style=\"text-align: left;\">Well, that might be a little help.\u00a0 It&#8217;s just one very basic example.\u00a0 But it&#8217;s real.<\/h4>\n<p style=\"text-align: left;\">This all just seems like <strong>&#8220;plain old Agile&#8221;<\/strong> to me.\u00a0 Many people tell me I&#8217;m wrong.\u00a0 What do I know?\u00a0 I&#8217;d rather be wrong about what to call this and be getting a lot of work done than the other way around.\u00a0Let me live in my delusions.<\/p>\n<p>NOTES:<\/p>\n<p>* For the purpose of this article, the sort of estimates I am discussing are the estimates typically asked for on many software development projects where a project, a feature, or a function, or a bug fix (or where a list of features or functions) are described and people are asked to come up with an approximate cost in time, money, or effort to do the work that will be required to provide the feature(s)\/function(s)\/capability(ies)\/bug fix(es) being requested.<\/p>\n<p>Disclaimer: There are many situations where estimates can be meaningful and useful. \u00a0This article is about situations where I don&#8217;t think they are typically meaningful or useful, and only in the realm of software development.<\/p>\n<div style=\"text-align: left;\"><\/div>\n<div style=\"text-align: left;\"><\/div>\n<div style=\"text-align: left;\"><\/div>\n<div style=\"text-align: left;\"><\/div>\n","protected":false},"excerpt":{"rendered":"<p>One little blog post cannot even begin to explore this complex subject.\u00a0 Here is a start at beginning the first part. Or perhaps, a pre-beginning. If you really want to figure this out quickly\u00a0don&#8217;t wait for me to figure out how to write about this.\u00a0 Just come and visit me sometime and I can quickly [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,21,22,24],"tags":[],"class_list":["post-251","post","type-post","status-publish","format-standard","hentry","category-agile-stuff","category-estimating","category-no-estimating","category-noestimates"],"_links":{"self":[{"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/posts\/251","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/comments?post=251"}],"version-history":[{"count":22,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/posts\/251\/revisions"}],"predecessor-version":[{"id":1117,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/posts\/251\/revisions\/1117"}],"wp:attachment":[{"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/media?parent=251"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/categories?post=251"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/zuill.us\/WoodyZuill\/wp-json\/wp\/v2\/tags?post=251"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}