tag:blogger.com,1999:blog-3811295271462580022024-03-15T22:48:56.153-07:00Agile Otter BlogTim Ottinger's thoughts on Software Development.Agileotterhttp://www.blogger.com/profile/10773578598860454277noreply@blogger.comBlogger451125tag:blogger.com,1999:blog-381129527146258002.post-88235304440417958182024-02-27T03:58:00.000-08:002024-02-27T04:11:55.503-08:00Definition-by-Dysfunction<p> I've done it. You've seen me.</p><p>You've done it. I watched you do it.<br /></p><p>We've probably argued about it.</p><h2 style="text-align: left;">The Defining Dysfunctions</h2><p>I published a <a href="https://www.industriallogic.com/blog/programming-under-surveillance/">blog post some time ago on the Industrial Logic website </a>about programming together vs programming under surveillance. It's a relatively simple piece, and it identifies a problem we have in the world when it comes to just about any technique or discipline.</p><blockquote><p><span face="Poppins, sans-serif" style="background-color: white; color: #333333; font-size: 18px;">When I suggested that people mistake group programming for working under surveillance, an incredulous reader exclaimed </span><em style="background-color: white; box-sizing: border-box; color: #333333; font-family: Poppins, sans-serif; font-size: 18px;">“How could it possibly be anything else!?”</em></p></blockquote><p>So here's the thing: a person had a bad experience where instead of actually researching what pair programming is and how it works, they just sat down at a keyboard with another person and tried "doing pair programming" without any pre-study or preparation. They ended with one person bored, watching the other program. </p><p>This is a widely-known dysfunction or "failure pattern" known as "Worker/Watcher." It's not how pair programming is done. </p><p>The two people who had this one unpleasant, uninformed, wasteful experience came into it with little more than a sound bite ("two people coding together"), guessed at how it was done ("one person types"), and had a poor experience. </p><p>Since they didn't start with a good definition of pair programming, that experience became the <i>definition </i>of pair programming. </p><p>They had a <i>defining dysfunction.</i> </p><p>Unless something new happens, they will forever see pair programming as wasteful and pointless practice.<br /><br />Is that the real definition of pair programming? </p><p>Is that what it's about and how it's done? </p><p>Not remotely. but it is the one touch-point they have -- the one experience that they have had of it, and "pair programming" is the name of that experience now.</p><p>Do they want to try it again? Clearly not. They <i>know</i> what it is, and it's nonsense. </p><p>They will likely take to social media to decry the BS that is pair programming and save everyone else from this wasteful and unprofitable behavior.</p><p>You and I have likely done the same. </p><p>Give those complainers some credit, because at least they tried it (or something that they imagined was it) first.</p><h2 style="text-align: left;">Some Examples Might Be Useful Here</h2><p>I ranted against scrum™for years, because I let the dysfunctions I routinely see become the definition of the process for me. If anyone were to actually try doing scrum™it would be a pretty good way of working, but nobody does.</p><p>Sadly, a lot of people in that space have adopted the defining dysfunctions. As far as they are concerned the "right way" to do scrum™ is to have a titled person assign individual work tickets to developers, who strive to serve the maximum number of tickets per fortnight to raise the velocity of the team -- striving to do "twice the work in half the time" (a soundbite). This isn't remotely what the defining document of the scrum™ method describes but it is what is often taught as "doing scrum."</p><p>Are you an agile hater because it's all Jira tickets, meetings, estimation, and work crammed in to meet artificial deadlines? I'd hate that too. I do hate that. It's just not agile. it's not even scrum™.</p><p>Do you hate agile because agile is "no documentation," "no design," and "no estimates"? Well, that's a worthy distaste. It's also a mischaracterization.</p><p>Do you hate TDD because you have to write all the tests first, and you don't even know what shape the answer is going to take, so it's impossible? Well, that's a bad process, and it's not TDD. It's not the definition of TDD, it's just a failure mode.</p><h2 style="text-align: left;">Why Bother Trying?</h2><p>Sometimes people don't even have to have a bad experience to adopt a defining dysfunction. They hear a sound bite or title and <i>imagine</i> dysfunctions. They (efficiently) go straight to disdaining the practice based on their <i>imagined</i> defining dysfunctions.<br /><br />Do you think that Psychological Safety means you can't ever say anything that might possibly upset someone? Does Radical Candor mean that you can say whatever you want without consequence? Wrong, and wrong. Those are defining <i>guesses</i> at <i>dysfunction</i>. </p><p>If we only guess at a discipline or a philosophy or a behavior and don't actually bother to investigate what it's intended to be, what it really means, and how people actually perform it then we don't have the basis for an honest opinion. If we have only experienced it as a bad attempt at a good idea we haven't formed a valid opinion. </p><h2 style="text-align: left;">We're Too Smart For That!</h2><p>Have you jumped to conclusions based on naive attempts or imagination alone?</p><p>I'm betting we both have. It's a human thing, and we're all human. It doesn't much matter how smart or experienced you are -- you've done this. I might just be projecting, but I've seen too many examples to believe it to be less than universal. Please prove me wrong!</p><p>I'm willing to bet that you've done so this week. Let's both look out for these mistakes, because I'm betting that we could be more successful at many things if we took the time to understand them.</p><p><br /><br /></p>Agileotterhttp://www.blogger.com/profile/10773578598860454277noreply@blogger.com0tag:blogger.com,1999:blog-381129527146258002.post-41683823395629454362024-02-27T02:46:00.000-08:002024-02-27T02:46:41.392-08:00Listicle on Flow and Teamwork<p>Some article links related to solo vs group, flow, productivity, and predictability.</p><p></p><ul style="text-align: left;"><li><a href="https://www.industriallogic.com/blog/stop-per-person-swimlanes">Stop using Per-Person Swimlanes</a></li><li><a href="https://www.industriallogic.com/blog/swarm-programming-with-the-swarm-board">Swarming</a></li><li><a href="https://www.industriallogic.com/blog/pitfalls-of-solo-work">Pitfalls of solo work</a></li><li><a href="https://www.industriallogic.com/blog/programming-under-surveillance">Programming Under Surveillance</a>, or in groups?</li><li><a href="https://www.industriallogic.com/blog/faster-and-more-predictable">Faster and More Predictable</a></li><li><a href="https://www.industriallogic.com/blog/managing-interruptions">Managing Interruption</a>s</li><li><a href="https://www.industriallogic.com/blog/work-to-be-interruptible">Work To Be Interruptible</a></li><li><a href="https://www.industriallogic.com/blog/scatter-gather">Scatter-Gather</a> software development</li><li>What is your <a href="https://www.industriallogic.com/blog/first-time-through">First Time Through</a> ratio?</li><li><a href="https://www.industriallogic.com/blog/squeezing-or-slicing">Squeezing Vs Slicing</a></li><li><a href="https://www.industriallogic.com/blog/managing-programmers">Managing Programmer Productivity</a></li><li><a href="https://www.industriallogic.com/blog/over-starting-and-under-finishing">Over-Starting and Under-finishing</a></li></ul><p></p>Agileotterhttp://www.blogger.com/profile/10773578598860454277noreply@blogger.com0tag:blogger.com,1999:blog-381129527146258002.post-5300851627278057852024-01-15T06:12:00.000-08:002024-01-15T11:37:15.568-08:00Fundamentally Wrong<p>The Problem</p><p>An <a href="https://hackernoon.com/test-driven-development-is-fundamentally-wrong-hor3z4d">article</a> has been shared with me by several friends and also by some critics, and some people who are both, describing how TDD is fundamentally wrong, and doing test-after-development is better.</p><p>To be fair, the process described here is fundamentally wrong:</p><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEgLKxdyfKJv3deqCM8-LTXeznNrsp2HfEnKNPag4c7-9_CZd3PywIXZhvp3scdEtnFRKqeeJC7VcBQ38mJBdxPaGlHTDlabXk21ss-vbbLP1WyfBoodM_I7Q2-6M4nuHNqk7GzLX22gdRQ55E7V1iGKKq81UULSHnfcfXlyecJN81a1fvGu8Cvexovkez4" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="936" data-original-width="1744" height="172" src="https://blogger.googleusercontent.com/img/a/AVvXsEgLKxdyfKJv3deqCM8-LTXeznNrsp2HfEnKNPag4c7-9_CZd3PywIXZhvp3scdEtnFRKqeeJC7VcBQ38mJBdxPaGlHTDlabXk21ss-vbbLP1WyfBoodM_I7Q2-6M4nuHNqk7GzLX22gdRQ55E7V1iGKKq81UULSHnfcfXlyecJN81a1fvGu8Cvexovkez4" width="320" /></a></div><div class="separator" style="clear: both; text-align: center;"><br /></div><div class="separator" style="clear: both; text-align: center;"><br /></div>The problems with step #1 would indeed lead to the wasteful problems described below it. The recommendation here would certainly be better than the process described above:<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEhOHbII-oSbSMC4jBIBoLL4n-oGT_Cx28RLNVaWIWhBmchFbUuN25JgmOpMgxuaJYRqKKNtLPP6yrabjNAcVUJDE5AOQJ03_xX8BT0BySvgZIMPVAPQ7fQ1ulAdPjiLwGjDcaYhHmPOthT4brW4scTDXtSpw7o5XsglJptwNTQqxKr_I94jPVoq_7i5xVY" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="688" data-original-width="1894" height="116" src="https://blogger.googleusercontent.com/img/a/AVvXsEhOHbII-oSbSMC4jBIBoLL4n-oGT_Cx28RLNVaWIWhBmchFbUuN25JgmOpMgxuaJYRqKKNtLPP6yrabjNAcVUJDE5AOQJ03_xX8BT0BySvgZIMPVAPQ7fQ1ulAdPjiLwGjDcaYhHmPOthT4brW4scTDXtSpw7o5XsglJptwNTQqxKr_I94jPVoq_7i5xVY" width="320" /></a></div><div class="separator" style="clear: both; text-align: center;"><br /></div><div><br /></div><h3 style="text-align: left;">TDD Is Fundamentally Wrong is Fundamentally Wrong</h3><br />Now, the problem with this article is more fundamental than the problem being described.<p></p><div style="text-align: center;"><b><span style="font-size: large;">TDD does not mean "<i>Write all the tests then all the code</i>"</span></b></div><div style="text-align: center;"><b><span style="font-size: x-large;"><br /></span></b></div><div style="text-align: center;"><b>It has never meant that.</b></div><div style="text-align: center;"><b><br /></b></div><div style="text-align: center;"><b><span style="font-size: x-large;"><i>That is not TDD.</i></span></b></div><div style="text-align: center;"><b><span style="font-size: x-large;"><br /></span></b></div><div style="text-align: center;"><b>That is some other misbegotten travesty that has no name.</b></div><div><br /></div><div><br /></div><div>This is the fifth or sixth time I've heard anyone describe TDD as writing <i>all</i> the tests first. In all cases except one, it has been described by people who self-describe as being anti-TDD, and who write articles decrying the foolishness that they identify as TDD (which is not TDD).</div><div><br /></div><div>I have never seen anyone do TDD that way -- even unsuccessfully. I have never seen anyone even try to do TDD that way. I would never sit by while someone tried to do that and called it TDD. That's simply not the process.</div><div><br /></div><div>The one time that I read an article that actually recommended doing that, it was from a Microsoft publication early in the XP/Agile days. The public outcry was great and sudden, and the article was retracted. I don't think I've ever seen anyone else recommend that approach, <i>because that approach is so obviously flawed and was never the process used by original XP teams.</i></div><h3 style="text-align: left;">So What Is TDD?</h3><div><br class="Apple-interchange-newline" />TDD was originally described as a three-step dance that repeats over and over as one develops code.</div><div><br /></div><div>You can take that <a href="https://tidyfirst.substack.com/p/canon-tdd">straight from the horse's mouth </a>(so to speak):<br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEhsMnhgobsOo2-OMOba0xZP7XPzd2lfdCrHG1JAuJecO7Ze4qlbBTZrZLgbTWpSxhjxURQEbIi9GSsUrTofuqV9Bk-knL8Wye2MCIzCJvYi-oYXr7XEy9-ev40GT58Ks4Nxc2UZhvLt2tq2MK7juRoYC-qg_65cTVIZ78pkEttdLuaJh_kk-pne8o8369U" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="480" data-original-width="857" height="204" src="https://blogger.googleusercontent.com/img/a/AVvXsEhsMnhgobsOo2-OMOba0xZP7XPzd2lfdCrHG1JAuJecO7Ze4qlbBTZrZLgbTWpSxhjxURQEbIi9GSsUrTofuqV9Bk-knL8Wye2MCIzCJvYi-oYXr7XEy9-ev40GT58Ks4Nxc2UZhvLt2tq2MK7juRoYC-qg_65cTVIZ78pkEttdLuaJh_kk-pne8o8369U=w365-h204" width="365" /></a></div><br /><br /></div><div><br /></div><div>To these three steps, we (at Industrial Logic) added a fourth and final step. Others may also have independently added this 4th step, I don't know.</div><div><br /><ol style="text-align: left;"><li><b>Write a test that does not pass,</b> and in fact cannot pass, because the functionality it describes does not exist. This failing test is the <span style="color: #990000;">RED</span> step, so-called because test-running programs generally produce the results of a failed test run colored red.</li><li><b>Write the code that passes the test.</b> When the test passes, it is typical that the test-running program will present the results colored green, so this is often called the <span style="color: #38761d;">GREEN</span> step. The code may not be optimal or beautiful, but it does (only) the thing the test(s) require it to do.</li><li><b>Refactor the code and test </b>so that both are readable, well-structured, clean, simple, and basically full of <a href="https://www.industriallogic.com/blog/code-virtues-explained/">virtue</a> (so far). Refactoring requires the presence of tests, so this way we can refactor as soon as the code passes the tests, rather than waiting until after all the code for our feature/story/task is finished. We refactor very frequently.</li><li><b>Integrate</b> with the code base. This will include <i>at least</i> making a local commit. Most likely it will be a local comment and also a pull from the main branch (preferably <span style="font-family: courier;">git pull -r</span>). More than half the time, it also includes a push to the shared branch so everyone else can benefit from our changes and detect any integration issues early.</li></ol><div><br /></div><div><br /></div> We repeat this cycle for the next test. The whole cycle may repeat 4-10 times an hour.</div><div><br /></div><div><br /></div><div>We do 1-2-3-4-1-2-3-1-2-3-4, we do not do 111111111-222222222-44444-(maybe someday)333. These are not batched.</div><div><br /></div><h3 style="text-align: left;">Was It A Misunderstanding of the List Method?</h3><div>Some people misunderstood Kent Beck's <i>List Method</i>, in which you begin with a step 0 of writing down a list of the tests you think you will need to pass for your change to be successful (see the screen shot and link to Kent Beck's article). </div><div><br /></div><div>Note that you only make a list of tests. You do not write them all in code.</div><div><br /></div><div>As you enter the TDD cycle, you take a test from the list. That may be the first test, the easiest test, the most essential test, or the most architecturally significant test. You follow the 4-step (or 3-step) dance as above. </div><div><br /></div><div>If you realize a test is unnecessary, you scratch it off the list. Don't write tests if the functionality they describe is already covered by an existing test.</div><div><br /></div><div>As you make discoveries, you add new tests to the list. That discovery may lead you to scratch some unwritten tests off the list. That's normal.</div><div><br /></div><div>Eventually, you will note that all the tests on your list have been scratched out. Either you implemented them, or you realized they're unnecessary. This applies to the tests you discovered as well as the original list.</div><div><br /></div><div>You've done everything you can think of doing that is relevant to this task, so you must be done. This is doubly true if you have a partner also thinking with you, or even more certain if you have a whole ensemble cast working with you.</div><div><br /></div><div>You never had to predict the full implementation of the features and write tests against that speculative future state.</div><div><br /></div><div>It's a tight inner cycle, not a series of batches.</div><div><br /></div><h3 style="text-align: left;">Do I disagree with the article, then?</h3><div><br /></div><div>Indeed, the "write all tests first" would only work for the most trivial and contrived practice example. It would never suffice in real work where <a href="https://agileotter.blogspot.com/2014/09/programming-is-mostly-thinking.html">11/12ths of what we do is learning</a>, reading, and thinking.</div><div><br /></div><div>As far as the process being unworkable, I totally agree.</div><div><br /></div><div>As far as that process being TDD, I totally disagree. <br /><br />That characterization of TDD is fundamentally wrong.</div><div><br /></div><div><br /></div>Agileotterhttp://www.blogger.com/profile/10773578598860454277noreply@blogger.com1tag:blogger.com,1999:blog-381129527146258002.post-41527417750171878152024-01-05T07:35:00.000-08:002024-01-08T06:02:00.736-08:00Python Listicle!<div>People often ask me (directly, or just generally posting to some social site) how they can learn Python quickly. </div><div><br /></div><div>Learning Python is one of those things where one can begin quite easily and quickly, but there is some depth to the language that one will want to understand and use once one gets past the most elementary early uses. </div><div><br /></div><div><div>If you are learning from tutorials, you might want to follow along in a REPL. You can try running Python locally (see <a href="https://en.wikipedia.org/wiki/IPython">ipython</a> and/or <a href="https://bpython-interpreter.org/">bpython</a>), as a <a href="https://jupyter.org/">Jupyter</a> notebook, or in <a href="https://replit.com/">Repl.it</a> if you want to keep your local machine Python-free for the time being).</div><div><br /></div></div><div style="text-align: left;">You will probably want to install an IDE, though. There are many<a href="https://www.simplilearn.com/tutorials/python-tutorial/python-ide"> <span>Python IDEs and Editors</span></a> in the world, but <a href="https://www.jetbrains.com/pycharm/">PyCharm</a> is the king of them all. Nothing else even comes close.</div><div><br /></div><div>So, here are some great places to start:</div><div><ul style="text-align: left;"><li><a href="https://learnxinyminutes.com/docs/python/">Learn X In Y Minutes</a> is great for <b>experienced</b> developers who are unfamiliar with the syntax and idioms of Python. It's all learn-by-example and is highly recommended for programmers who are exploring Python for the first time.</li><li>For <b>less experienced</b> developers, consider the official <a href="https://wiki.python.org/moin/BeginnersGuide">Beginner's Guide</a> or the <a href="https://www.w3schools.com/python/default.asp">W3 Schools</a> tutorial first.</li><li>Regardless of your level, you will want to bookmark the <a href="https://docs.python.org/3/index.html">Official Docs</a> which include r<b>eference material and tutorial material.</b></li><li>You will get a lot of <b>good tips and deeper lessons</b> from <a href="https://www.youtube.com/@ArjanCodes">Arjan Codes</a> on YouTube, or the many excellent lessons at <a href="https://realpython.com/">Real Python</a>. This is true whether you are an expert, intermediate, or beginner. There is a lot of content to explore, so don't try to take it all in over the course of a weekday.</li><li>A language without a great <b>standard library</b> is just a syntax. The Python <a href="https://pymotw.com/3/">Module of the Week</a> gives some of the best in-depth exposition you can find. Definitely spend time there!</li><li>The Python community has created so many<b> additional libraries </b>at <a href="https://pypi.org/">The Python Package Index</a>. Here you can search, research, and learn about the many frameworks and libraries that make Python the best choice for so many jobs in real-world applications.</li><li>Every feature you'll use started as one of the <a href="https://peps.python.org/">Python Enhancement Proposals (PEPs)</a>. Python PEPs are to Python what the RFPs are for the internet and the worldwide web. If you need to deeply understand a feature's purpose and intention, this is the place to go.</li><li><a href="https://docs.python.org/3/whatsnew/index.html">What's New In Python</a> is a crucial resource for experienced developers to <b>keep up with change</b>s in the language. Besides being a bullet list of new features, there's some very good expository writing there and links to the relevant PEPs.</li></ul></div><div><br /></div><div>That is a lot, I know, but if you choose one of these resources according to your needs at the moment, I think you will be well satisfied. </div>Agileotterhttp://www.blogger.com/profile/10773578598860454277noreply@blogger.com0tag:blogger.com,1999:blog-381129527146258002.post-80231152660070212162023-12-20T03:11:00.000-08:002023-12-20T03:15:01.601-08:00Leadership.<p> <span style="background-color: white; color: #050505; font-family: inherit; font-size: 15px; white-space-collapse: preserve;">I have this very simple/simplistic view on leadership.</span></p><div class="x11i5rnm xat24cr x1mh8g0r x1vvkbs xtlvy1s x126k92a" style="background-color: white; color: #050505; font-family: system-ui, -apple-system, "system-ui", ".SFNSText-Regular", sans-serif; font-size: 15px; margin: 0.5em 0px 0px; overflow-wrap: break-word; white-space-collapse: preserve;"><div dir="auto" style="font-family: inherit;">People will become a follower if:</div><div dir="auto" style="font-family: inherit;">a) They believe the person is competent</div><div dir="auto" style="font-family: inherit;">b) They will personally benefit from that person's competence</div></div><div class="x11i5rnm xat24cr x1mh8g0r x1vvkbs xtlvy1s x126k92a" style="background-color: white; color: #050505; font-family: system-ui, -apple-system, "system-ui", ".SFNSText-Regular", sans-serif; font-size: 15px; margin: 0.5em 0px 0px; overflow-wrap: break-word; white-space-collapse: preserve;"><div dir="auto" style="font-family: inherit;"><span style="font-family: inherit;"><a style="color: #385898; cursor: pointer; font-family: inherit;" tabindex="-1"></a></span>Whether it's a minister, a businessperson, a writer, a local organizer, or a criminal doesn't matter all that much. </div><div dir="auto" style="font-family: inherit;"><br /></div><div dir="auto" style="font-family: inherit;">We like to impart character and integrity to our leaders, and we like to pretend that we chose them because of their superior traits, but it<span style="font-family: inherit;"> doesn't matter as much as we would like to pretend. If those were really the criteria, we would never fall for con men and tricksters. </span></div></div><div class="x11i5rnm xat24cr x1mh8g0r x1vvkbs xtlvy1s x126k92a" style="background-color: white; color: #050505; font-family: system-ui, -apple-system, "system-ui", ".SFNSText-Regular", sans-serif; font-size: 15px; margin: 0.5em 0px 0px; overflow-wrap: break-word; white-space-collapse: preserve;"><div dir="auto" style="font-family: inherit;">Remember. that people followed some pretty unsavory characters in the past and many do now.</div><div dir="auto" style="font-family: inherit;"><br /></div><div dir="auto" style="font-family: inherit;">I had to chew on this for years, because people can be radical followers of some pretty awful characters. Why would they be so blind to the character of their heroes? </div><div dir="auto" style="font-family: inherit;"><br /></div><div dir="auto" style="font-family: inherit;">It seems consistent now, that it's down to two factors. </div></div><div class="x11i5rnm xat24cr x1mh8g0r x1vvkbs xtlvy1s x126k92a" style="background-color: white; color: #050505; font-family: system-ui, -apple-system, "system-ui", ".SFNSText-Regular", sans-serif; font-size: 15px; margin: 0.5em 0px 0px; overflow-wrap: break-word; white-space-collapse: preserve;"><div dir="auto" style="font-family: inherit;">The perceptions don't even have to be correct. Sometimes confidence masquerades as competence. In politics, business, religion, or social life the bombastic and dynamic personality is often chosen over the quietly competent because <i>confidence looks like competence</i> to the outsider. </div><div dir="auto" style="font-family: inherit;"><br /></div><div dir="auto" style="font-family: inherit;">Some people speak with such conviction that others are tricked into believing they know what they're talking about.</div></div><div class="x11i5rnm xat24cr x1mh8g0r x1vvkbs xtlvy1s x126k92a" style="background-color: white; color: #050505; font-family: system-ui, -apple-system, "system-ui", ".SFNSText-Regular", sans-serif; font-size: 15px; margin: 0.5em 0px 0px; overflow-wrap: break-word; white-space-collapse: preserve;"><div dir="auto" style="font-family: inherit;">It always comes down to people "backing the winner" - the good/bad guy who is "on our side" and who is aligned with our interests. They're "going to win" so we want to be on their side, and benefit from that support.</div></div><div class="x11i5rnm xat24cr x1mh8g0r x1vvkbs xtlvy1s x126k92a" style="background-color: white; color: #050505; font-family: system-ui, -apple-system, "system-ui", ".SFNSText-Regular", sans-serif; font-size: 15px; margin: 0.5em 0px 0px; overflow-wrap: break-word; white-space-collapse: preserve;"><div dir="auto" style="font-family: inherit;">Their competence will benefit us, so they're the "good guy."</div></div><div class="x11i5rnm xat24cr x1mh8g0r x1vvkbs xtlvy1s x126k92a" style="background-color: white; color: #050505; font-family: system-ui, -apple-system, "system-ui", ".SFNSText-Regular", sans-serif; font-size: 15px; margin: 0.5em 0px 0px; overflow-wrap: break-word; white-space-collapse: preserve;"><div dir="auto" style="font-family: inherit;">That draws followers.</div><div dir="auto" style="font-family: inherit;"> </div><div dir="auto" style="font-family: inherit;">It defines leaders.</div></div>Agileotterhttp://www.blogger.com/profile/10773578598860454277noreply@blogger.com0tag:blogger.com,1999:blog-381129527146258002.post-9387222707712734512023-11-22T10:02:00.000-08:002023-11-22T10:02:52.143-08:00Choose your Expression: Structural Matching, IF-ELSE, and Dictionaries <p> So, I have a command line utility that collects and presents some time-series data.<br /><br />What it is isn't important, but dates are involved.</p><p>You can specify start dates and/or end dates with options <span style="font-family: courier;">--after</span> and <span style="font-family: courier;">--until</span>. If you specify neither, you get everything.</p><p>This programming idea is not so interesting on its own, and I have multiple expressions that all work just fine. It's not a programming puzzle I am here to present.</p><p>Instead, I'm curious about which version speaks to you, which teaches you, which repulses you. <br /></p><p>More than that, I'm interested in WHY. </p><p>Here is an if-the-else version:<br /><br /></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEiBbDAYRaE5v7AAjvyle1-35i6UQbYPOqprLqFdj41jBkPCEZVuhJ1d3pSXAgZJhlZqLJ9zDuaGNYv2nDwLDyz0BBawsIca_k_lt2YBA72Ht_wGKVyiCkwdC0gNDXglmldkKBxX_gPwVc3xXf5RS0mQU0OpmuFqTOi2TyITWH80QawduyV_1YNpc-vX0NY" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="378" data-original-width="1592" height="169" src="https://blogger.googleusercontent.com/img/a/AVvXsEiBbDAYRaE5v7AAjvyle1-35i6UQbYPOqprLqFdj41jBkPCEZVuhJ1d3pSXAgZJhlZqLJ9zDuaGNYv2nDwLDyz0BBawsIca_k_lt2YBA72Ht_wGKVyiCkwdC0gNDXglmldkKBxX_gPwVc3xXf5RS0mQU0OpmuFqTOi2TyITWH80QawduyV_1YNpc-vX0NY=w623-h169" width="623" /></a></div><p></p><p><br /></p><p>Here is a similar version using a dictionary:</p><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEgFjp_0m4eH-GlbHD4dBtmUCOqoLd8D8RlhGORPqvVwRNCwPqXb8SIzr7bcR7oQC2WV-s6FxkTgF9UzyTp-6LFL1pqYUwyc3Su4hVe2BW7MMP8TZtH9HiTPHUYYmvB2qQCtqA7Azo9ARyk8Tzzx5RetJuOuSwil77hZHAiblJDuw8XJpAj-K3Bpg3bBldQ" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="436" data-original-width="1502" height="213" src="https://blogger.googleusercontent.com/img/a/AVvXsEgFjp_0m4eH-GlbHD4dBtmUCOqoLd8D8RlhGORPqvVwRNCwPqXb8SIzr7bcR7oQC2WV-s6FxkTgF9UzyTp-6LFL1pqYUwyc3Su4hVe2BW7MMP8TZtH9HiTPHUYYmvB2qQCtqA7Azo9ARyk8Tzzx5RetJuOuSwil77hZHAiblJDuw8XJpAj-K3Bpg3bBldQ=w734-h213" width="734" /></a></div><div class="separator" style="clear: both; text-align: center;"><br /></div><div class="separator" style="clear: both; text-align: center;"><br /></div>And one that uses structural matching:<p></p><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEiOonfDqA0vmxNpJbKW1VYeIB26ZFfqM9rzGciMkAL04k7zU1nS9480WLzD77X593uUruEix_TFCh0Oc0ys9e67rUUeWVuGfL3duU7An3qtyuam7thqo4aMwNZJlZ2_h6N-XIDnhK7FY1SPfM_qhClX4Hf_xi4eXn1zVcN2gl-laK21mC5nH4db4_ykUCY" style="margin-left: 1em; margin-right: 1em;"><img alt="" data-original-height="492" data-original-width="1428" height="232" src="https://blogger.googleusercontent.com/img/a/AVvXsEiOonfDqA0vmxNpJbKW1VYeIB26ZFfqM9rzGciMkAL04k7zU1nS9480WLzD77X593uUruEix_TFCh0Oc0ys9e67rUUeWVuGfL3duU7An3qtyuam7thqo4aMwNZJlZ2_h6N-XIDnhK7FY1SPfM_qhClX4Hf_xi4eXn1zVcN2gl-laK21mC5nH4db4_ykUCY=w674-h232" width="674" /></a></div><br /><br /><p></p><p>Some people will naturally prefer if/else for the simple reason of familiarity. They see a lot of if/then/else logic, and so there isn't much to learn or think about. They may call it "simpler' but it is not. </p><p>The dictionary version has more parts, but they're very simple parts, and all the actual work is done in the first and last sentence. </p><p>The structural matching is using newer syntax, and is both less verbose than the if/else and more verbose than the dictionary version.</p><p>Which strikes you as the most valuable expression of the idea? </p><p>Which would you rather write?</p><p>Which would you rather edit?</p><p>Which would you rather test? </p><p>What is your reasoning behind the appeal of your chosen method (pun intended).</p><p><br /></p><p><br /><br /></p>Agileotterhttp://www.blogger.com/profile/10773578598860454277noreply@blogger.com1tag:blogger.com,1999:blog-381129527146258002.post-72289549113536493532023-08-30T05:33:00.004-07:002023-08-30T05:51:44.686-07:00CSS Specificity Rundown<p> CSS really is fun. <br /><br />No, seriously. I'm not being sarcastic here. </p><p>Even though I've been in software a long, long, long time, I hadn't really studied CSS before last year (shocking, I know) and so I've been behind in my training. </p><p>I had an opportunity to dive in more, and all was going well until I started playing with media queries and ran into a specificity problem that wasn't so obvious (to me, though it may have been to you).</p><p>So, to help people who are treading the same path, here are some aids on specificity:</p><p><br /></p><p>* <a href="https://www.w3schools.com/css/css_specificity.asp">W3 Schools</a> has a fun "try it and learn" approach to general CSS Specificity</p><p>* Saucelabs specifically breaks down <a href="https://saucelabs.com/resources/blog/css-breakpoints-media-query-breakpoints-responsive-design">specificity and media queries</a></p><p>* Halodoc provides some <a href="https://blogs.halodoc.io/best-practices-that-we-follow-to-avoid-specificity-issues/">best practices</a> to avoid troubles.</p><p>* Specificity with Darth Vader and Stormtroopers and stuff at <a href="https://www.smashingmagazine.com/2007/07/css-specificity-things-you-should-know/">smashing magazine.</a></p><p><br /></p><p>These should get you past the worst of your troubles nicely. If you do get stuck, then it's always nice to experiment with a local HTML/CSS document or maybe fire up a <a href="http://REPL.IT">REPL.IT</a> instance for HTML, CSS, and JS. It's all fun.</p><p>PS: Because we need it so often, here is a <a href="https://www.456bereastreet.com/archive/200509/css_21_selectors_part_1/">CSS Selector Cheat Sheet.</a></p>Agileotterhttp://www.blogger.com/profile/10773578598860454277noreply@blogger.com0tag:blogger.com,1999:blog-381129527146258002.post-6304793808199616622022-04-06T07:58:00.002-07:002023-12-29T04:17:47.147-08:00Code Smells Listicle<p> After many times looking up various resources on code smells and code smell taxonomies, I finally decided to make a listicle (list article) of these. </p><p>Enjoy:<br /><br /></p><ul style="text-align: left;"><li>Industrial Logic's <a href="https://elearning.industriallogic.com/gh/submit?Action=AlbumContentsAction&album=recognizingSmells&devLanguage=Java">Code Smells</a> album is carefully curated and deftly explained. A winner.</li><li>Industrial Logic also has a <a href="https://www.industriallogic.com/blog/smells-to-refactorings-cheatsheet/">cheat sheet</a> for code smells (recommended)</li><li>The <a href="https://wiki.c2.com/?CodeSmell">OG</a></li><li>Wikipedia's <a href="https://en.wikipedia.org/wiki/Code_smell">extensive listing</a></li><li>A nice taxonomy at <a href="https://blog.codinghorror.com/code-smells/">Coding Horror</a></li><li>A nice writeup at <a href="https://refactoring.guru/refactoring/smells">Refactoring Guru</a></li><li>The <a href="https://sammancoaching.org/reference/code_smells/index.html">Samman Coaching List </a>has nice descriptions.</li><li>There is a longish<a href="https://deviq.com/antipatterns/code-smells"> list without explanations</a> at DevIQ, as a jumping off point for many interesting web searches.</li></ul><div>On the "positive" side of the ledger, we also have virtues:</div><div><ul style="text-align: left;"><li>The original<a href="https://medium.com/pragmatic-programmers/how-virtuous-is-your-code-c3d1a587babf"> Code Virtues</a> article from Pragmatic Programmers, republished at Medium.</li><li>The <a href="https://www.industriallogic.com/blog/code-virtues-explained/">explainer article</a> (feel free to start here) at Industrial Logic.</li></ul></div><p></p>Agileotterhttp://www.blogger.com/profile/10773578598860454277noreply@blogger.com1tag:blogger.com,1999:blog-381129527146258002.post-25530058994298228832022-03-14T08:44:00.004-07:002022-05-05T17:53:48.660-07:00What does Tim have against "private" methods?<p> A big thread erupted, all full of misunderstandings and miscommunications, about the idea of "private" methods. </p><p>It all started quite innocently (I maintain) when someone asked how we felt about testing private methods. Some people jumped in with "Absolutely Not! Never! That's wrong! Test via public interfaces."<br /><br />I thought a little longer, and said "I'm not sure" and then later "I'm not sure that 'private' is even needed."</p><p>This is where the problems started, and maybe here I can clarify what I meant by it all. </p><p>People assume (and insist) that I could only possibly mean that they should substitute 'public' for all protected and private members, polluting the interface, and inviting the violation of a class' internal state. </p><p>That was never my intention and still isn't. Still, this is what people insist that I must have meant from the start. I suppose this is because that's what they imagined me to mean and it's hard to admit that you're wrong, or perhaps because this is social media so people never miss an opportunity to double-down and pile on if at all possible. It's like a sport. <br /><br />It's also entirely possible that I didn't communicate well at all in short tweets. Maybe that's all on me. I can't say.</p><p>Well, you've come this far, so let's see if I can't communicate better in blog than in twitter, since I can write in peace without people accusing me of meaning the wrong thing while I try to explain what I actually mean.<br /><br />If I've managed to make sense with this post, let me know. </p><p>If I've not, the forum is open for clarifying questions below.</p><h2 style="text-align: left;">Autocomplete is a big deal.</h2><p>The good thing about 'private' and 'protected' -- the thing that actually makes programming easier/better, is that the<b><i> methods aren't offered by auto-complete</i></b>. The idea of locking people out of calling the method? Not even remotely a second-degree concern.</p><p>People program by autocomplete. You type the name of a thing, press the dot, and you get a list of things you can do. You may never look at the documentation, or read the example code, but you will see the autocomplete hundreds of times a day.</p><p>When you want to disable an account, there is likely to be a 'disable' method attached to an account. You choose that method, run the tests, ship it. That's how you normally will navigate.<br /></p><p>When you don't see a method you want, you might pop up a level and use the module or some management API interface. Again, you type the name and a dot, and you look for 'disable' in the recommended names. </p><p>Private and Protected are two of the ways to keep functions out of that list, and if they're not in the list, you're not likely to even consider calling them.</p><h2 style="text-align: left;">Arbitrarily Located Functions</h2><div>A developer is implementing a class and realizes that they need to compare date ranges. They write that up, drop it into a private method, and all is well.</div><div><br /></div><div>Or is it? <br /><br /></div><div>Why is <i>that </i>method located in <i>this</i> class? Does it have high cohesion? No. Does it support the purpose of this class directly? No. <br /></div><div><br /></div><div>Why then? Because this class calls the function, and this is the file I was editing when I wrote the function.</div><div><br /></div><div>In other words, the function doesn't belong here according to any rule of design, but it wasn't found anywhere else either. The developer drops it into the class with 'private' and moves on.</div><div><br /></div><div>What I've found is that often the private methods in one class are repeatedly reinvented in private methods of other classes. Sometimes they're even copied and pasted directly from one class to another.</div><div><br /></div><div>Why? Because this is the class they had open in the editor when they realized they needed the function, and it's not available for calling because it's private in the other class. So they copied it.</div><div><br /></div><div>Arbitrarily located functions, hidden from view, repeated by invention and copying, likely hiding the opportunity for Single Point Of Truth (SPOT) abstractions and libraries that would make everyone's job a little easier.<br /><br />This isn't a rare occurrence. <br /><br />By being hidden and arbitrarily located, they invite duplication and reinvention. </div><div><br /></div><h2 style="text-align: left;">Testability of Private Methods? None</h2><p>When we talk about testing private methods, it's a non-starter. If you put the word 'private' on the front of a method in most languages, you cannot call that method from a test. That means you can't possibly test private methods.</p><p>Okay, there is a way, but it involves reflection and that's an obscenity. If you ever use reflection to crack into some legacy code and test hidden methods, make sure you remove that hack as soon as humanly possible (or sooner) because it's a travesty. It's awful. It will fail you if the method is renamed or moved. Reflection is generally a bad idea, and I wouldn't do that (much, or for long).</p><p>If you are doing TDD (and why wouldn't you?) you test the public methods, and if they're using private methods then the private methods are being exercised. If you have meaningful tests and assertions, then the private methods are being tested through the public interface and that's probably okay.</p><p>If you're not doing TDD (and why not?) then you may not have code that tests all the private behaviors. You may have to read all the code in order to exercise it properly, which is a pain.</p><p>If you're doing test-after development (but why?) you've written the code and now you have to write tests around it. Every private method is a called from some public method and you're going to have to figure out how to get down into that private method code and recognize if it's working correctly or not.</p><p>By being private, those methods have cut off the easiest route to testability -- calling the method directly.</p><p><br /></p><h2 style="text-align: left;">Should You Test Implementation?</h2><p>You should: implementation is how code behaves and you have to test behavior.</p><p>There are caveats here:</p><p></p><ul style="text-align: left;"><li>If you're structure-aware in your tests, they'll resist structural refactoring</li><li>If you're time-sequence-aware in your tests, they'll resist time-order refactoring</li><li>If you're using reflection, you're poisoning our future and must be stopped (half-grin)</li></ul><p style="text-align: left;">There are rules, of course. You don't lock down things that you want to change, and you don't leave unspoken the things that must be true. Your tests specify how your world behaves at a certain level.</p><p style="text-align: left;">Sometimes that's too high a level and there are mini-behaviors you need to check too.</p><p style="text-align: left;">I've seen cases where testing only at the interface required hundreds of tests, but testing at the internal level requires barely a dozen. This is because at the higher level, you need all the combinations of all the paths of all the subordinate functions. At lower levels, you need one for each path in a function.</p><p style="text-align: left;">High-level end-to-end and integration tests take a long time to run, and microtests are cheap and fast.</p><p style="text-align: left;">We tend to do microtesting (or unit testing) so that we can afford to run the tests in a tight TDD cycle. </p><p style="text-align: left;">To argue against testing implementation functions is to argue against unit testing and microtesting on principle.</p><p style="text-align: left;">If you should only use the most-public interface, then shouldn't you only test at the UI level? Yeah, this is not a good idea. </p><p style="text-align: left;">So how can we get at the lower-level functions? If they're all private, we can't but it is totally possible if they are public methods on lower-level classes that are composed ("encapsulated") by the API classes. </p><p style="text-align: left;"><br /></p><h2 style="text-align: left;">Interfaces and Implementations</h2><p style="text-align: left;">In many languages, you can declare a public interface, and that interface can be implemented by other classes.</p><p style="text-align: left;">It's accepted that one should always program to the interface in those languages. This way, one can only use the declared, public interface of the implementations. This keeps the implementations substitutable (via Liskov Substitution Principle). </p><p style="text-align: left;">Non-interface methods of the implementers are <i>already hidden</i>: callers have no access to them via the interface. </p><p style="text-align: left;">If you're using the interface, and you press the dot, then only methods in the public interface are presented. The other methods of the implementer may as well not exist, because they are not available here.</p><p style="text-align: left;">If you have segregated interfaces, this is even nicer. It may be that two or three public interfaces are the right way to think and design interactions, but combining a few of those interfaces together is the better way to implement the behaviors. No user of one interface has any awareness that the other interfaces exist on the object, nor of the public methods of the other interfaces, nor any of the public methods of the implementers.</p><p style="text-align: left;">In order to reach the public methods of the implementer, a caller would have to <i><b>down-cast</b></i> from the interface to the implementation (a no-no that justifies a sharp crack across the knuckles with a yardstick) in order to even know that other methods exist. </p><p style="text-align: left;">This is convenient. This means that all methods of the implementers can be public without exposing those methods to callers. Since they're public, you can write tests directly against them. Because the implementation is being tested also through the interface, it's easy to ensure that it behaves as a whole implementation.</p><p style="text-align: left;">Why not make them private? Because it's redundant and limits testing. </p><p style="text-align: left;">Without polluting the public interface, one has a fully open and testable class.</p><p style="text-align: left;"><br /></p><h2 style="text-align: left;">Thinking a little more deeply</h2><div>Private methods, when we choose to use them, may signal a need for us to think more deeply about our situation and strategies.</div><p></p><ol style="text-align: left;"><li><b>In a Rat's Nest:</b><br />sometimes people are doing test-last (after coding) and they have a complex method. You shouldn't have big, complex methods if you have any other choice. To try to manage the complexity, they may extract some private methods.<br />In order to test through the API, you have to navigate the rat's nest. You will have to set up deep data structures and some combination of boolean conditions that will allow you to get to the private method's function call, and then to exercise the code inside that method.<br />It's easier to make the method's access less restricted and test it directly than to have dozens of long and complicated tests. Perhaps package-public, perhaps protected so you can cheat with inherit-to-expose. <br />It's better to test the code easily than to write awful, fragile, internals-aware tests.</li><li><b>Missed Abstractions</b><br />Where one class has a bunch of private methods, often there is some cohesion between those methods. If one were to set the private methods side-by-side, one might recognize that there have been missed abstractions.<br />Maybe some of the methods are generic string, date, or math functions. These could be public methods in a utility package or more-primitive type. If you move them to the "right" place, they can be fully testable and can be reused within the codebase. They would not be public methods of the class you're working on.<br />Perhaps some of those represent a lower-level concept that is munged into the current class. If they were pulled out, they could become testable, public methods on the new class. They would still not appear in the public interface of the class you're working on.<br /></li><li><b>In Languages without Private</b><br />In Python, smalltalk, and similar languages there's no 'private' and we've been okay with that for a long time (since the 70s for Smalltalk). <br />While people say that encapsulation is a core feature of OOD (and it is) it isn't the "private" keyword that causes encapsulation. It's done via composition.<br />In a Python module, you can choose what classes you expose and which you don't. You have a class with a public API, which is composed of classes/functions that aren't part of the public API. They're tested directly within the module and don't have a "private" keyword associated with them. They might not have underscore-decorated names or any other semblance of access protections. <br /></li><li><b>Other APIs</b><br />In any language, the Model class or the API class may have a simple interface into the module (as described above) but the module may have a lot of complicated functions and logic divided into multiple classes and functions. <br />The model class doesn't have any 'private' methods at all - it just calls the public methods of other classes in the module. Those classes have copious tests and may not have any methods declared Private or Protected, because only the API and tests call those methods - they're not visible to the outside world (protection from <a href="https://www.hyrumslaw.com/">Hyrum's Law</a>)<br /></li></ol><h2 style="text-align: left;">So What Do You Do Instead</h2><div><ul style="text-align: left;"><li><b>Don't pollute the public interface of a class with private methods.</b> If you simply flip the <b>private</b> methods to be <b>public</b>, you'll lose understandability of the interface and create unwanted dependencies. This is what I recommend <b>not</b> doing. Keep interfaces clear and clean.</li><li><b>Move your methods </b>to the places where they belong (where they have cohesion) and can be easily found by others.</li><li><b>Try not to need private methods</b>. They should be rare. Remember, many OO languages don't even have the concept of <i>private</i> and they're just fine without them.</li><li>in some legacy code test-after situations, <b>you might raise accessibility of a method to public</b>, protected, or module-private in order to support refactoring via better tests (in the short term)</li><li>Consider<b> using encapsulation properly</b>: by composing behaviors under an API, rather than by housing all behaviors in the API's class.</li><li>In some languages, you have 'interface' or 'protocol' classes that <b>declare an interface to use</b>. Do that when there is a clear public interface. </li></ul><div>And, of course, I would be remiss if I didn't admit that I do sometimes create private methods. I try not to, and when I find a better way than settling on private, I am usually happier. I sometimes leave a little cruft like private methods until I have more information and can see a better design form; it may take weeks or months. <br /><br />So yeah, there are private methods in my code. I just don't see that as "good coding" and a "solution." It's temporary.</div></div><p></p>Agileotterhttp://www.blogger.com/profile/10773578598860454277noreply@blogger.com3tag:blogger.com,1999:blog-381129527146258002.post-34479507977191502032022-03-03T08:09:00.007-08:002024-02-08T01:38:45.879-08:00Splitting Stories - A Resource Listicle<p> I've noticed that for several years now, one of the most frequently asked questions in agile forums deals with the splitting of stories. </p><p>We simply can't create a feature, epic, or improvement in a single gesture. If we are going to make progress, we have to start somewhere and build in small pieces. One way or another, whether we release after each piece or not, we have to make progress in bits and pieces. </p><p>In the bad old waterfall days, the analysts and designers would come up with a system with functional decomposition. It would essentially describe a tree with upper-level modules calling lower-level modules all the way down to individual functions.</p><p>After the designers have done a top-down design, the developers would start building the system starting from the bottom-up. They would build the pieces and the higher-level pieces that use those pieces until they had components, sub-assemblies, subsystems, and eventually the entire product. </p><p>This "top-down design, bottom-up implementation" had the advantage that pieces could be farmed out or assigned to a lot of individuals and as the parts started to integrate errors could be discovered. Sadly, full integration was one of the last activities possible in the system, and really large errors could be discovered late in the process. </p><p>We tend to see that whole system - a master designer surrounded by minion "brick-makers" -- to be fraught with peril. There are just too many ways for the work to be wrong or late, and too little engagement of the intelligence of all the brick-building developers. These kinds of systems fail much more often than agile ways of working, according to Standish reports.</p><p>We find working in end-to-end slices to be superior as far as engaging the intelligence of our people, getting integration (and therefore bug detection) early and often, and in our ability to demonstrate a running, working system at all times. Rather than having 100% of the system N% complete and little to demonstrate, inspect, or use to acquire feedback, we always have N% of the system 100% done and demonstratable. </p><p>This is a political and technical improvement in the way of working. Where it is practiced, teams are more successful in building products that satisfy the needs of the product community.</p><p>But how does one do that?</p><p>Here are some writeups that I like and recommend:</p><p></p><ul style="text-align: left;"><li><a href="https://www.industriallogic.com/blog/making-user-stories-work-for-you/">Understand the process </a>user stories are <a href="https://www.industriallogic.com/blog/writing-better-user-stories/">intended to support.</a></li><li>What is a <a href="https://www.henricodolfing.com/2018/04/start-your-project-with-walking-skeleton.html">walking skeleton</a> anyway?</li><li>Josh Kerievsky's description of <a href="https://www.industriallogic.com/blog/evolutionary-design/">Evolutionary Design</a> (the primitive whole, walking skeletons, etc)</li><li>Learn why you need <a href="https://www.industriallogic.com/blog/whole-stories-for-whole-teams/">Whole Stories for Whole Teams</a></li><li>Try Gojko Adzik's <a href="https://gojko.net/2012/01/23/splitting-user-stories-the-hamburger-method/">Hamburger Method</a></li><li>Check out Neil Killick's <a href="https://www.neilkillick.com/blog/the-essence-of-story-slicing-in-agile-development">capability slicing</a></li><li>George Dinwiddie suggests splitting stories <a href="https://blog.gdinwiddie.com/2011/05/01/splitting-user-stories/">by testable requirements</a>.</li><li>Try <a href="https://www.industriallogic.com/blog/bargain-hunting/">Bargain Hunting</a></li><li>See the nightmare of <a href="https://www.industriallogic.com/blog/scatter-gather">Scatter-Gather</a> (and avoid it!!)</li><li>Bill Wake's exploration of <a href="https://www.industriallogic.com/blog/evolution-cupcakes-and-skeletons/">ways to grow systems</a></li><li><a href="https://agileinaflash.blogspot.com/2009/02/breaking-down-larger-stories.html">A Dozen Ways</a> to split stories </li><li><a href="https://www.mountaingoatsoftware.com/blog/five-simple-but-powerful-ways-to-split-user-stories">SPIDR</a> - Mike Cohn's <a href="https://blogs.itemis.com/en/spidr-five-simple-techniques-for-a-perfectly-split-user-story">Spikes, Paths, Interfaces, Data, Rule</a>s method.</li><li>Bill Wake's<a href="https://xp123.com/articles/twenty-ways-to-split-stories/"> 20 collected ways</a> to split stories</li><li>Richard Lawrence's <a href="https://www.binarysludge.com/2012/03/07/flowchart-how-to-split-a-user-story/">Story Splitting Flowchart</a></li><li>Dr. Balbe's <a href="https://techbeacon.com/app-dev-testing/practical-guide-user-story-splitting-agile-teams">fairly comprehensive guide</a>, including INVEST and ZOM.</li><li>For "what not to do" check out Cohn's <a href="https://www.mountaingoatsoftware.com/blog/five-story-splitting-mistakes-and-how-to-stop-making-them">5 Mistakes article</a>.</li><li>A quick introduction to "<a href="https://builtin.com/software-engineering-perspectives/what-are-tracer-bullets">tracer bullets</a>" can't hurt.</li></ul><div>Check out the <a href="https://www.agilealliance.org/glossary/story-splitting/">5 selected articles</a> from Agile Alliance while you're at it.</div><div><br /></div><div><br /></div><div><br /></div><p></p>Agileotterhttp://www.blogger.com/profile/10773578598860454277noreply@blogger.com2tag:blogger.com,1999:blog-381129527146258002.post-49185875063261829122022-02-18T13:06:00.002-08:002022-02-18T13:10:14.456-08:00Maximize Value, not QuantityI was chatting with a manager who was once a PO on a team I coached many years ago. This is only my best memory of the conversation (I didn't record it at the time). I may have slightly embellished it with snippets from conversations that followed over the course of days or weeks, but I try to be faithful.<br /><div><br /></div><div>One day she took me aside and asked what she should be doing to accelerate the team and get more work pushed through.<br /><br /></div><div>“Nothing,” I said.<br /><br /></div><div>“Nothing? But I thought that I’m supposed to be getting maximum work and speeding up the team…?”<br /><br /></div><div>“Nope. Your job as PO is to maximize the <i>value</i> of the work, not the <i>quantity</i> of the work. Given that they’re doing roughly the same amount of work each week (barring emergencies and vacations), your job is to make sure that what they are working on is the most valuable work that they could do that week - that it is impactful and useful.”<br /><br /><blockquote><i><span style="font-size: medium;">The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.</span></i> - <span style="font-size: x-small;">the <a href="https://scrumguides.org/scrum-guide.html#product-owner">scrum guides</a></span></blockquote></div><div><br /></div><div>“I was told that I’m supposed to push for more, and there was a healthy tension between PO pushing for more and SM pushing back.”<br /><br /></div><div>“Yeah. That’s nonsense. You’re all on the same team and should be all working for the same results. If you push people beyond their capacity to work, they’ll turn in crappy work and that won't be the best value for time spent. Don’t do that.”</div><div><br />“OMG! That’s GREAT! I was so worried because I don’t know how to make people work harder. All I have to do is deal with content and not execution?”</div><div><br />“Yep. That’s it.”</div><div><br />“That’s incredibly good news. I just felt a lot of stress roll off of my shoulders. That’s great! I can totally do this job!”</div><div><br />And she did. Soon she was known for being the best PO in the building, having the best teams, having solid relationships with her teams, and making wise decisions.</div><div><br />Her career as a product manager was launched there and has progressed to this day.</div><div><br />PO/PM/etc: <br /></div><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px;"><div style="text-align: left;"><b>Your job is not to fight your team</b>. You’re all supposed to work together on this thing.</div></blockquote>Agileotterhttp://www.blogger.com/profile/10773578598860454277noreply@blogger.com1tag:blogger.com,1999:blog-381129527146258002.post-29062809478082500172022-02-15T08:25:00.000-08:002022-02-15T08:25:04.286-08:00Can teams be accountable for delivery of features? <br /><br /> Including delivery/deployment in the <i>definition of done</i> I'm told is<b> unfair</b> because teams aren't in control of what gets delivered or when.<ul style="text-align: left;"><li>"Their work might be completed, but be only a fraction of some larger<a href="https://www.industriallogic.com/blog/scatter-gather/"> scatter-gathered</a> effort, so it's not their fault." </li><li>"They may be dependent on work from another group, say FE or BE or database, or something, so it's not their fault the work isn't done." </li><li>"They may have worked on a dozen things, but only one was delivered. It's unfair that it doesn't represent all of their efforts." </li><li>"Releases aren't done every sprint/increment/week/whatever, so it will look like uneven velocity if we only count work actually delivered." </li><li>"They should be able to count the points for everything they worked on, whether it's delivered or not." </li><li>"A manager may decide not to release their feature and leave it in the branch -- maybe never release it. It's not their fault so they should be able to count the work they did that was canceled." </li><li>"There could be technical issues that make the feature un-deliverable. How will they count their points if the feature can't be completed?" </li><li>"The testing departments could return their code for rework, and that would keep them from counting all the work that they did on the feature." </li><li>"It's up to the customer to accept the work, and if they don't then none of the efforts will count." </li></ul>All of these say "it seems unfair to count accomplishments when the system works against accomplishing things, so we want to honor and respect the busyness of the team members instead."<div> <br />This is what I mean by "busyness accounting" -- focusing on how busy people are, not on whether we're reaching our goals. It seems more "fair" if we are evaluating people on how *much* they do instead of what value is delivered.</div><div> <br />Busyness accounting arises naturally and organically when we're tracking people in the system instead of tracking the flow of work through the system, and when we're focused on people "scoring points" of velocity instead of delivering value.</div><div><br />Go back and notice the helplessness in each of the complaints/reasons to not count delivery.<br /><br />"Our system is dysfunctional and resists our best efforts, so we count how hard we try instead."<br /><br />A better system might change everything.</div><div> <br />If only delivery/achievement counted, how would you rework the way you are doing software today?</div><div><br /></div><div>What processes would you change, eliminate, or trade out?</div><div><br />What would you do instead?</div><div> <br />What if it's not impossible?</div><div><br /><b><i>Could you work in a world where the rules are different? </i></b><br /></div><div><b><i><br /></i></b></div><div><b><i><br /></i></b></div><div><i><span style="font-size: xx-small;">this post is recreated from a <a href="https://twitter.com/tottinge/status/1473695364964364290?s=20&t=qhnxFqVRCZrmtjKhjv3wGA">Twitter thread</a> from December 2021</span></i></div>Agileotterhttp://www.blogger.com/profile/10773578598860454277noreply@blogger.com0tag:blogger.com,1999:blog-381129527146258002.post-2046439530018496092021-10-11T12:39:00.002-07:002021-10-11T13:34:46.854-07:00The inefficiency of tests<p>So a given web application has an architecture that involves a UI and an API and under that some domain objects, data, etc.</p><p>When a new feature comes up, there is a <b><i>gherkin test </i></b>that does NOT go through selenium, but directly to the API. In developing the gherkin test, the team drives out the changes needed by the API and gets it working.</p><p>The gherkin test is a "story test" and checks to see if the system (behind the UI) works correctly. It does data, persistence, etc in a safe way.</p><p>But to build the code, you are <i><b>doing TDD directly on the API</b></i> and the deeper domain objects. As you do, you are refactoring and committing (of course).</p><p>The microtests and the gherkin tests together are super-fast, so you run both in<i><b> the auto tester</b></i>. The auto tester re-runs the tests any time the code is changed and compile-able. This means the tests are run many sometimes more than once a minute. You're always clear where you stand.</p><p>But of course, there is a web page to deal with. You create <b><i>render tests</i></b> that will turn data (specifically the kind needed or returned by the API) into a web page. </p><p>Now, these are back-end rendered old-school style. You get that working correctly. <br /><br />It works, but is it ugly? Is it awful? Sigh.</p><p>Okay, you fire up the webserver and look at the page, and sure it's ugly. You work on the CSS and make it look better. You're using a d<i><b>evelopment web server that reloads</b></i> the page when the HTML or CSS changes so fixing the aesthetics and flow is fairly quick (if tedious).</p><p>But where is your automated test to be sure the wiring between the web page and the API is working correctly? </p><p>Okay, you write some <b>selenium tests</b>. Just the necessary ones, maybe just automating tests you were doing by hand to check out the web page(s) rendering(s).</p><p>It just so happens that someone built a testing tool that pretends to be the webserver! You write some <i><b>HTTP-level tests</b></i> that do the GET, POST, PUT, DELETE and they run quite fast and give you confidence. You might eventually replace the selenium tests with HTTP-level tests but for now you leave some of them in place.</p><p>Hey, the app works! You <i><b>deploy</b></i>. </p><p>You're ready to move on to the next feature, but your friend brings up a problem. </p><p><span style="font-size: medium;">Y<b>our friend mentions that some of the code exercised and checked by the UI test is <i>also</i> checked by other tests.</b></span></p><p>The render tests check the DOM, the API tests check message-passing, the microtests check underlying functions, the UI tests are end-to-end: while there are many different tests, many code paths are indeed covered by integration tests and end-to-end tests as well.</p><p>Your friend says<i> "this is inefficient because the same code is getting coverage more than once."</i></p><p>You smile.<br /><br />You know it's <i><b>not</b></i> inefficient, because you aren't measuring efficiency by total lines written or the number of times you <i>had to </i>run the tests, or by some standard of minimal coverage.</p><p>You know that human efficiency is high - it's a quick, reliable, and safe way to create a system that can be safely refactored, extended, modified.</p><p>You value safety over efficiency, and efficiency is a side-effect.</p>Agileotterhttp://www.blogger.com/profile/10773578598860454277noreply@blogger.com0tag:blogger.com,1999:blog-381129527146258002.post-84724322055110136792021-09-10T09:47:00.003-07:002022-05-13T11:37:12.349-07:00FIRST: an idea that ran away from homeQuite some years ago, Brett Schuchert and I invented the acronym FIRST for <a href="https://www.youtube.com/watch?v=H3LOyuqhaJA">micro-tests</a>, though we called them "unit tests" (as was common at the time). This was later included in <a href="https://www.pragprog.com/titles/olag/agile-in-a-flash/">Agile In A Flash</a> and was also published in a Pragmatic Programmers' <a href="https://medium.com/pragmatic-programmers/unit-tests-are-first-fast-isolated-repeatable-self-verifying-and-timely-a83e8070698e">article.</a><br /><div><br /></div><div>It’s grown a following and has been widely repeated. At this point, the idea just exists in the aether, and authorship isn’t often considered or cited. I suppose it has become "common knowledge" at least in some circles. It's usually not even given a citation, so I guess it's become a thing in its own right.</div><div><br />I’m still proud of Brett’s work and my small contribution to it. I'm glad it has taken on a life of its own, but I'm aware of when it's poorly described or when it's corrupted and am offended when people present it as their own unique work (or take praise for it, knowing that it is not original). <br /><br />I get it, though. I'm sure there are many people whose work I didn't know how to credit, and whose work I may have likewise twisted to my own ends or interpreted in my own context whether I realized it or not. <br /><br /></div><div>The acronym is pretty simple</div><div><br /><ul style="text-align: left;"><li>FAST - you can run all your microtests so quickly that you never have to decide to run them later or now.</li><li>Isolated - tests don't rely upon either other in any way, including indirectly. Each test isolates one failure mode only. <br /></li><li>Repeatable - The test always gets the same result. This is largely a matter of good test setup and cleanup, but also the consideration of things like time of day, network status, database, global space, configuration, etc never being changed. <br /></li><li>Self-validating - a test is pass/fail. You never have to examine the input, output, or system state to determine if a test has passed. It is either green (passed), red (failed), or else the test did not run to completion (error), and it states the fact very clearly.</li><li>Timely - microtests are not to be written in batches, either before or after coding. They are written with the code, preferably just before adding a line or just after finishing a tiny change to a function.</li></ul><div>Some people change the T to <i>Thorough</i> because they don't want to encourage TDD. </div><div><br /></div><div>I think this is a mistake. It's not "just as good" to have high coverage from a batch of tests written after the code is finished. It's not even nearly as good.</div><div><br /></div><div>Done correctly, the tests inform and guide the code. <br /><br /></div><div><ul style="text-align: left;"><li>They help us to consider our code <i>first</i> from the point of view of a user of the code, which results in more sensible and cohesive APIs. </li><li>The tests make acceptance criteria a primary concern. If we don't know what result we are expecting, we can't write the test for it.</li><li>They make testability a primary concern: we can't write a test if we can't call the method or can't observe the result of making the method call. There is no "untestable code" if the tests come first.<br /></li><li>As we realize we have corner cases, we add more tests, so that it's clear when we have covered the corner cases in the production code.</li><li>Because tests are written first, they are a kind of standalone documentation - you read the tests to understand the code. When tests are written after the code, they tend to take the structure and algorithms of the written code for granted: you must read the code to understand the test.</li><li>Whatever code passes the tests, that code is sufficient. The tests help us recognize a complete state.</li><li>Since the invariants for the production code are tested automatically, we can refactor the code to a different shape and design with the confidence of knowing that all of the tests still pass so we haven't violated any of our design invariants.</li><li>Each time our tests pass (run <i>green</i>) we are invited to reexamine the production code and the tests for readability and maintainability. This allows us to practice code craft continuously.</li><li>Because our intentions for the code are captured in the tests, we have externalized our intentions. We can be interrupted and quickly regain our context in the application - something that can't happen if we're in the middle of transcribing a large plan from our heads into the codebase.</li></ul></div><div><br /></div><div>Done post-facto, the tests have no way to influence the organization and expression of code in any meaningful way. Writing tests after the code in order to increase coverage becomes drudgery.</div><div><br /></div>Where to find it.</div><div><ul style="text-align: left;"><li>Our old <a href="http://agileinaflash.blogspot.com/2009/02/first.html">AgileInAFlash article</a></li><li>The expanded <a href="https://medium.com/pragmatic-programmers/unit-tests-are-first-fast-isolated-repeatable-self-verifying-and-timely-a83e8070698e">Pragmatic Programmers' article</a>.</li><li><a href="https://howtodoinjava.com/best-practices/first-principles-for-good-tests">How To Do In Java</a> (no credit given)</li><li><a href="https://dzone.com/articles/writing-your-first-unit-tests">Java DZone</a> (Credits Clean Code) </li><li><a href="https://www.appsdeveloperblog.com/the-first-principle-in-unit-testing/">Apps Developer</a> (modified T, no credit)</li><li><a href="https://hackernoon.com/test-f-i-r-s-t-65e42f3adc17">HackerNoon</a> (at least linked to our article): </li><li><a href="https://stackoverflow.com/questions/18024785/tdd-first-principle">Stackoverflow</a> discussion </li><li><a href=" https://luminousmen.com/post/ode-to-unit-tests">ODE to testing</a>: Credit is given! </li><li><a href="https://openclassrooms.com/en/courses/5661466-use-testing-in-java-to-achieve-quality-applications/6290871-apply-principles-for-writing-good-tests">Open Classrooms</a> has a pretty good interpretation.</li><li><a href="https://medium.com/dev-genius/first-principles-of-unit-testing-5b6c452ccb7d">This one</a> references an article that we wrote that used to be on Pragmatic Programmers. https://thoughtbot.com/blog/back-to-basics-writing-unit-tests-first </li><li>"<a href=" https://codebork.com/testing/2020/04/26/complete-guide-testing-your-software-part-1.html">Complete guide</a>" No mention of authorship. :disappointed:<br /></li><li><a href="https://docs.microsoft.com/en-us/dotnet/core/testing/unit-testing-best-practices#characteristics-of-a-good-unit-test" target="_blank">Microsoft quoting us</a> accurately but without attribution.</li></ul><div>Any quick google search will turn out dozens of articles. </div></div><div><br /></div><div><br /></div>Agileotterhttp://www.blogger.com/profile/10773578598860454277noreply@blogger.com0tag:blogger.com,1999:blog-381129527146258002.post-15694413964246398972021-08-11T14:47:00.005-07:002021-08-12T06:15:38.472-07:00Changing Axioms<p> (originally posted in march 2008, republished with edits)</p><br />I read a mailing list entry in which one fellow (who? I can’t remember!) asked another:<div><br /><blockquote>“Do you want to get better at what you’re doing, or find a better way to get the results you want?”</blockquote><br /><br />I’m a sucker for a good one-liner. That one had me thinking, and as I’ve had other conversations about innovation, I keep coming back to that line.<br /><br />In many Agile practices, we work really hard for a week or two, and then hold a retrospective. The purpose of the retrospective is to find <i>ways to work more effectively for the next two weeks</i>. </div><div><br /></div><div>As we develop better software, we also evolve a better team. We may use “tricks” such as tracking our velocity and recording blockages on our ‘waste snake’ to provide data for our decisions, and we use gut feel to evaluate those things that feel like collateral effort to us.<br /><br />If the practice works, we will see incremental improvement in the team. We will develop ways of avoiding special variations, and we will learn to accept our normal variations. </div><div><br /></div><div>It will make us better at the way we do things now.<br /><br />However...</div><div><br />XP didn’t come from a series of incremental improvements to waterfall processes. </div><div><br /></div><div>I wasn’t there when it happened but it seems that they took on a change in <b>axioms</b>. They reimagined the development process.</div><div><br /></div><div>They didn’t strengthen the contracts between groups but pulled all the decision-makers onto the same team.</div><div><br /></div><div>They didn’t find more careful ways to preplan the code they were changing, but rather decided to lean radically on volumes of tests.</div><div><br /></div><div>They didn’t build practices to improve their anticipatory design, they decided instead not to anticipate at all and simplify their design to allow future change. </div><div><br /></div><div>At the time, this was radical stuff.<br /><br />I’m sure there have been many other less-successful process mutations, but there is no evolution without mutation.<br /><br />The man behind the iPod, iPhone, and MacBookPro has had some less successful product ideas, too. Some exciting high-concept products didn’t make it in the wild. But then some new ideas become category killers.<br /><br />How do we learn to make the axiomatic changes that lead us to radically better ways to get what we want?</div>Agileotterhttp://www.blogger.com/profile/10773578598860454277noreply@blogger.com0tag:blogger.com,1999:blog-381129527146258002.post-82073777204723200072021-08-06T13:00:00.001-07:002021-08-06T13:00:11.229-07:00Outliving The Great Variable Shortage<p> </p><div class="atomentry" id="article-275" style="font-family: Verdana, Helvetica, sans-serif; font-size: 12px; margin: 0px 0px 3em;"><h2 class="title" style="color: #003399; font-family: Arial, Helvetica, sans-serif; font-size: 1.8em; letter-spacing: -1px; line-height: 1.7; margin: 0px; padding: 0px;"><br /></h2><p class="author" style="color: #003399; font-family: Arial, Helvetica, sans-serif; font-weight: bold; line-height: 1.7; margin: 0px 0px 10px; padding: 0px 0px 0px 2px;">Originally Posted <abbr class="published" style="border: none; color: #aaaaaa;" title="2007-02-26T23:07:00-06:00"><span class="typo_date" title="Tue, 27 Feb 2007 05:07:00 GMT">on 2/26/2007</span></abbr></p><div class="content"><p style="line-height: 15px; margin: 0px 0px 1.2em; padding: 0px;">One of the more annoying problems in code, confounding readability and maintainability, frustrating test-writing, is that of the multidomain variable.</p><p style="line-height: 15px; margin: 0px 0px 1.2em; padding: 0px;">I suppose somebody forgot to clue me in to the Great Variable Shortage that is coming. I have seen people recycling variables to mean different things at different times in the program or different states of the containing object. I’ve witnessed magic negative values in variables that normally would contain a count (sometimes as indicators that there is no count, much as a <span class="caps">NULL</span>/nil/None would). I might be willing to tolerate this in programming languages where a null value is not present.</p><p style="line-height: 15px; margin: 0px 0px 1.2em; padding: 0px;">Yet I have seen some code spring from multidomain variables that made the code rather less than obvious. I think that it can be a much worse problem than tuple madness.</p><div class="extended" style="padding-top: 5px;"><p style="line-height: 15px; margin: 0px 0px 1.2em; padding: 0px;">I have a rule that I stand by in OO and in database design, and that is that a variable should have a single, reasonable domain. It is either a flag or a counter. It is either an indicator or a measurement. It is never both, depending on the state of something else.</p><p style="line-height: 15px; margin: 0px 0px 1.2em; padding: 0px;">It is sort of like applying Curly’s law (Single Responsibility Principle) to variables. A variable should mean one thing, and one thing only. It should not mean one thing in one circumstance and carry a different value from a different domain some other time. It should not mean two things at once. It must not be both a floor polish and a dessert topping. It should mean One Thing and should mean it all of the time.</p><p style="line-height: 15px; margin: 0px 0px 1.2em; padding: 0px;">Surely I’ll take a shot from someone citing the value of a reduced footprint, and I won’t argue very long about the value of using only as much memory as you must. In C++ I was a happy advocate of bitfields. I haven’t been overly vocal about using various data-packing schemes, but I think that it can be a reasonable choice for compressing many values into a smaller space, but I will maintain that multipurpose variables are a bad idea, and will damage the readability of any body of code.</p><p style="line-height: 15px; margin: 0px 0px 1.2em; padding: 0px;">I suggest, in the case of constrained footprint where there truly is a Great Variable Shortage (<acronym title="tm">GVS</acronym>) that <strong>if</strong> (and that’s a big <strong>if</strong>) the author absolutely <span class="caps">MUST</span> repurpose variables on the fly that it is the lot of that programmer to make sure that users of the class/struct never have to know that it is being done. Never. Including those writing unit tests. The class will have to keep data-packing and variable-repurposing as a dirty secret.</p><p style="line-height: 15px; margin: 0px 0px 1.2em; padding: 0px;">Perhaps a strong statement or two in rule-form should be made here:</p><ol style="margin: 1em; padding: 0px;"><li style="line-height: 16px; margin: 0px; padding: 2px 0px 0px;">A variable should have a <span class="caps">SINGLE DOMAIN</span>.</li><li style="line-height: 16px; margin: 0px; padding: 2px 0px 0px;">One must <span class="caps">NEVER GET CAUGHT</span> repurposing a variable.</li></ol><p style="line-height: 15px; margin: 0px 0px 1.2em; padding: 0px;">We don’t have to make do with the smallest number of variable <strong>names</strong> possible. Try to learn to live in plenty: use all the variables you want. For the sake of readability, consider having a single purpose for every variable not only at a given point in time but for the entire program you’re writing.</p></div></div><ul class="meta" style="border-bottom: 1px solid rgb(85, 85, 85); border-top: 1px solid rgb(85, 85, 85); color: #555555; font-size: 10px; list-style: none; margin: 0px; padding: 5px 0px 5px 20px;"><li class="categories" style="color: black; font-size: 12px; line-height: 13px; margin: 0px; padding: 0px;">Posted in <a href="https://web.archive.org/web/20120315102554/http://blog.objectmentor.com/articles/category/tims-tepid-torrent" rel="tag" style="color: #555555; text-decoration-line: none;">Tim's Tepid Torrent</a></li><li style="color: black; font-size: 12px; line-height: 13px; margin: 0px; padding: 0px;">Meta <a href="https://web.archive.org/web/20120315102554/http://blog.objectmentor.com/articles/2007/02/26/outliving-the-great-variable-shortage#trackbacks" style="color: #555555; text-decoration-line: none;">no trackbacks</a>, <a href="https://web.archive.org/web/20120315102554/http://blog.objectmentor.com/articles/2007/02/26/outliving-the-great-variable-shortage#comments" style="color: #555555; text-decoration-line: none;">34 comments</a>, <a href="https://web.archive.org/web/20120315102554/http://blog.objectmentor.com/articles/2007/02/26/outliving-the-great-variable-shortage" rel="bookmark" style="color: #555555; text-decoration-line: none;">permalink</a>, <a href="https://web.archive.org/web/20120315102554/http://blog.objectmentor.com/xml/rss/article/275/feed.xml" style="color: #555555; text-decoration-line: none;">rss</a>, <a href="https://web.archive.org/web/20120315102554/http://blog.objectmentor.com/xml/atom/article/275/feed.xml" style="color: #555555; text-decoration-line: none;">atom</a></li><li></li></ul></div><div class="atomentry" id="article-187" style="font-family: Verdana, Helvetica, sans-serif; font-size: 12px; margin: 0px 0px 3em;"></div>Agileotterhttp://www.blogger.com/profile/10773578598860454277noreply@blogger.com0tag:blogger.com,1999:blog-381129527146258002.post-24500002364635283612020-06-01T06:58:00.001-07:002020-06-09T13:03:21.105-07:00A Whole Lot Of Nope<div dir="ltr" style="text-align: left;" trbidi="on">
In light of recent outrages, there are a lot of people posting bloodthirsty things on social media. If you post bloodthirsty things, I want you to know I don't stand with you on that. I may agree with your underlying cause(s) and reason(s). But I don't want people to be killed.<br />
<br />
I don't want looters to be killed.<br />
I don't want protesters to be killed.<br />
I don't want suspects to be killed.<br />
I don't want curfew-violators to be killed.<br />
I don't want civilians to be killed by cops.<br />
I don't want cops to be killed by civilians. <br />
I don't want politicians killed. <br />I don't want community leaders to be killed.<br />
I don't want bystanders to be killed.<br />
<br />
I'm not claiming that all of these things are equivalent. The only equivalence is that I want all these people to go home at night, and justice to be accomplished without bloodshed. I'm not suggesting outrage is unfounded. I'm not saying nothing should be done. <br />
<br />
I will suggest that if escalation and bloodthirst were really the answer, they probably would have worked by now. </div>
Agileotterhttp://www.blogger.com/profile/10773578598860454277noreply@blogger.com0tag:blogger.com,1999:blog-381129527146258002.post-67308035845286040162020-05-04T09:29:00.000-07:002020-06-01T11:32:02.607-07:00Speech Hacks to be More Decisive<div dir="ltr" style="text-align: left;" trbidi="on">
I was in a leadership program with Christoper Avery some years ago. In that program, people would say “<a href="https://www.psychologytoday.com/us/blog/inviting-monkey-tea/201304/stop-shoulding-yourself-death-0">don’t should on yourself.</a>”<br />
<br />
Another friend had years ago told me that “should” is the saddest word in English because it means you see value in something, haven’t done it, and probably won’t.<br />
<br />
I embarked on a quest to get rid of some aspects of self-defeating speech:<br />
<br />
<ul style="text-align: left;">
<li>Instead of “I’m sorry” <a href="https://www.boredpanda.com/stop-saying-sorry-say-thank-you-comic-yao-xiao/?utm_source=google&utm_medium=organic&utm_campaign=organic">say “Thank you”</a></li>
<li>Instead of “No thanks, I can’t eat that” say “No thanks, <a href="https://medium.com/@lombo/dont-say-i-can-t-say-i-won-t-970ab88acef8">I won’t</a> eat that.”</li>
<li>Instead of “I don’t know how” say “I haven’t learned <a href="https://www.gettingsmart.com/2018/02/mindset-and-the-power-of-yet/">YET</a>”</li>
<li>Instead of “<a href="https://www.verywellmind.com/should-statements-2584193">I should <x></x></a>” say “I may <x>” or “I would like to <x>“.</x></x></li>
</ul>
<br />
You know, these little things make a difference for me.<br />
<br />
The speech patterns are more decisive and confident, reflect agency and choice, and generally help me avoid shame (in myself) and appearing uncertain or indecisive.<br />
<br />
These are just little things, and it's not magic. One a person chooses an attitude they need to find language that supports that attitude.<br />
<br />
My speech changes support the internal decisions I've made about how I want to address the world.<br />
<br />
I am no psychologist so I can't say why it works for me or whether it will work for you. This isn't a prescription.<br />
<br />
If you want to try some or all of these, then go to it. I didn't originate these ideas and you don't owe many any credit if it works wonders for you. If it doesn't work for you, well, you were warned.<br />
<br />
If you try these hacks, then please:<br />
<ul style="text-align: left;">
<li>Try them for yourself and on yourself. </li>
<li>Do not insist that people use these terms. </li>
<li>Do not chastise or pillory other people for not using these terms.</li>
</ul>
<br />
Does changing a speech pattern really change a person's attitudes? <a href="https://www.psychologytoday.com/us/blog/the-biolinguistic-turn/201702/how-the-language-we-speak-affects-the-way-we-think">Probably</a>.<br />
<br />
Are we wandering into <a href="https://en.wikipedia.org/wiki/Political_correctness">political correctness</a> and the <a href="https://en.wiktionary.org/wiki/euphemism_treadmill">euphemism treadmill</a> right now? <br />
Gosh, I hope not. I'm no expert on those and see both advantages and disadvantages in those things.<br />
<br />
I don't feel the authority or invitation to lecture you on how you should/must/shouldn't/mustn't speak. I'm just offering some things you can choose to do or not. <br />
<br />
I'm not saying you <i>should</i>.<br />
<br /></div>
Agileotterhttp://www.blogger.com/profile/10773578598860454277noreply@blogger.com0tag:blogger.com,1999:blog-381129527146258002.post-63593591990468224462020-03-17T08:48:00.001-07:002020-03-17T08:53:49.394-07:00Some Covid-19 Information<div dir="ltr" style="text-align: left;" trbidi="on">
Hello all.<br />
<br />
From time to time, I will post something that is not on-brand for Agile Otter Blog at all, but is of concern at a point in time or in celebration or mourning.<br />
<br />
Today I'm listing some resources related to the Coronavirus COVID-19.<br />
<br />
A quick warning: there is a thin line between being informed about the virus and being obsessed with it. You should have the facts, and these sites will help you. But don't be so obsessed that you can't think about anything else. Take precautions, follow guidelines, don't be fooled by myths, don't search for miracle home cures. Take care of yourself and your family, and try to continue living a productive and normal life.<br />
<br />
I took time out to gather a few resources for you, but I have other things to do too. May we all get on with delivering value to each other and serving our communities of practice as well as protecting our friends and family.<br />
<br />
Don't panic. Do take precautions as recommended.<br />
<br />
Info and advice:<br />
<ul style="text-align: left;">
<li>WHO <a href="https://www.who.int/emergencies/diseases/novel-coronavirus-2019/advice-for-public">advice for public</a></li>
<li>NIH<a href="https://www.nih.gov/health-information/coronavirus"> information on covid-19</a></li>
<li>CDC <a href="https://www.cdc.gov/coronavirus/2019-ncov/downloads/2019-ncov-factsheet.pdf">fact sheet</a></li>
<li>CDC <a href="https://www.cdc.gov/coronavirus/2019-ncov/prepare/prevention.html">guide to prevention</a></li>
<li>WHO <a href="https://www.who.int/emergencies/diseases/novel-coronavirus-2019/situation-reports">situation reports</a></li>
</ul>
<div>
Myth Busters:</div>
<ul style="text-align: left;">
<li>Medical News Today's <a href="https://www.medicalnewstoday.com/articles/coronavirus-myths-explored">myth-busting</a> article</li>
<li>Hopkins' <a href="https://www.hopkinsmedicine.org/health/conditions-and-diseases/coronavirus/2019-novel-coronavirus-myth-versus-fact">myth-busting</a> page</li>
<li>A <a href="https://www.rochesterregional.org/news/2020/03/covid19-myths-and-facts">myth-busting page</a> from Rochester</li>
</ul>
<br />
Stay healthy, and that includes not having an unhealthy morbid fascination with covid-19.<br />
<br />
<br /></div>
Agileotterhttp://www.blogger.com/profile/10773578598860454277noreply@blogger.com0tag:blogger.com,1999:blog-381129527146258002.post-89784208355305886032020-02-27T13:53:00.003-08:002020-02-27T15:02:33.421-08:00The Laptop "Problem"<div dir="ltr" style="text-align: left;" trbidi="on">
A few friends of mine have been pretty down on people using computing devices during meetings. The very presence of open laptops, tablets, phones, etc, gives them the impression that people are disinterested and disrespectful.<br />
<br />
You might know the individuals in question, there are a few of them and they all have some pleasant association with me in the past, they are friends, and I'm not here to talk about them. I want to talk about <a href="https://agileotter.blogspot.com/2016/08/the-curiosity-space.html">Curiosity Over Judgment</a> instead.<br />
<br />
<h3 style="text-align: left;">
Corporate Training</h3>
<br />
A long time ago, when I was working for a company in the great midwest, we took a class on crucial conversations. Our instructor was from headquarters and so was clearly an Important Person. The topic was clearly a Very Important Corporate Topic to have flown someone in from headquarters and cancel a day of work to educate us.<br />
<br />
My friend had an apple device that was his exclusive note-taking machine. If one is to take notes, it's best that they're collected together, and having them on his device meant he could organize and search them and also take his entire library of notes from place to place in a pocket. The device was an Apple Newton - this was well before the ubiquity of laptops and tablets.<br />
<br />
Early in the course, the instructor walked to my friend's desk, tapped the device and said severely "Put this away." My colleague tried to interject and explain, but the trainer would have no part of it. "Put it away now, please."<br />
<br />
Realizing the hopelessness of his situation, my friend shut the Newton down and put it in his bag. Then he crossed his arms across his chest, sighed deeply, and checked out. I could tell he was not concentrating on the topic as much as fuming over the unfair treatment he'd just received.<br />
<br />
The Important Corporate Topic was "crucial conversations." Let that sink in.<br />
<br />
The trainer who was presenting how to have crucial conversations just missed the greatest opportunity to practice and demonstrate the very tactic they were teaching us. Instead, a unilateral hard-correction command "Put this away." No conversation about "I saw you were doing this, which led me to think that, what do you think, what will you do?" None.<br />
<br />
<img alt="Image result for apple newton" src="data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/2wCEAAkGBxMTEhUTEhMWFRUXFRgaFRgXGBgVGhYYFxgXGBcWHSAZHSggGB0lHhYXIjEhJisrLi4uFx8zODMtNygtLisBCgoKDg0NFRAQFysfIB0rLSstLSsrLy0rLSstLS0rLSstLS0tLSstKystLS0rLS0tLS0rNystNzcrLS0rKzMtK//AABEIALgBEgMBIgACEQEDEQH/xAAcAAEAAQUBAQAAAAAAAAAAAAAAAwIEBQYHAQj/xAA9EAABAwICBwUGBQQCAgMAAAABAAIRAyEEMQUGEkFRYXEHEyIygVKRobHR8EJicoLBFCPh8UOSM9JTY4P/xAAXAQEBAQEAAAAAAAAAAAAAAAAAAQID/8QAHhEBAQEBAAMBAQEBAAAAAAAAAAERAiExUQMSYUH/2gAMAwEAAhEDEQA/AO4oiICIiAiIgIiICIiAiIgIiICIiAiLW9a9dsLgRFR23Vjw0mQX3yJ3MHM+koNkXPteu0qlhR3WFLK1eYdJJZT4zs+Z022QRF5NoPM9Ze0DGYskGoaNIgjuqRIEHMOOb/W3ILU5Vwdi1c7YGmG46lsn/wCWiCW/uYSXD9pdM5BdL0XpWjiGd5Qqsqs4sIMHgd7TyN18rMu3aAOzMbUHZnhMQVPo/SFWg8VKNR9N4/Ewlp6GMxyNkxH1ci4zq32wVGQzG0xUGXe04a/ddzD4XbzILehXVNCaew+LZt4aq2oN4BhzZ3OafE09QorJIiICIiAiIgIiICIiAiIgIiICIiAiIgIiICIiAiIgIi8JQeqz0rpSjhqZq16jabBvcYk8AM3HkLrSNb+1Ghh5p4XZr1RYun+0w8yP/IeTbcxkuOab03XxVTvMRUdUdeJyaDuaBZo6cLyrg6Brd2svfNPAg0276rx4z+lpszqZN8mlcvq1S4lziSSZJJJJJzJJuTzUb3xc2C2rVnUWtiYfXJw9E8v7rx+Vp8g5uv8Al3qpbjWsJh6lV4pUWOqVDcNbcxxO5o5mAt20P2f7PjxhDjupMJ2f3OsX9LDqt70fgMPhWd1h2NYMzvc8i204m7j1VFd6X05Xv4xFWmzZ2HsGyMgBYDhAzA5W6LWdK6oMf48O7Z/KZLfQ5hbjUurOpSgktsT6/P145rGpLjlukNH1KJiqyOBzaehTR9ao13eUqhpuZ+MOLC2chtC4n4rpNW42XgOndAv6G1hzWs6W1Ua47VE7B9l3iafota3O/rYNXu1vEUYZjGDEM3PYWtqRxt4KnD8PMldQ1d1wweNtQrDb303+CoOPhPmHNsjmvnXF1HMAZi6TrEjvAfEQSTZxlro2nQDb1uIW4OYdSe18QYEMe0jaMwTNtkmc+Ai6tjcr6uRcA1Z7UsXh4ZWP9TSEWqGKgHJ9yf3Ak8Qusas6+YLGw2nU2Kp/4qsMeTwbeH/tJ9FMVs6IigIiICIiAiIgIiICIiAiIgIiICIiAit8djadFhqVXtpsbm5xAA9/yXKtbu1cmaeAGyMjWeLn9DTl1cOPhGaDoOsuteGwTZrv8REtpt8T3dBuHMwOa4vrf2gYnGSwHuaBt3bCZePzuzd0sORzWqYnFPe4vqOc97jLnOJcSeJJuVAJJDWglzjDWi5PQKo9c5TaO0fVxDtmizajzONmM/U7+BJ5LP6F1Rc87WIt/wDU03/e4ZfpbJyvuW6YagKTQxrAGDIMEBv7f5EnkE1m9YxeruqlGgQ+p/dqi4c4eFh/K3IfqMngdy2wV1j2VQbgz9eB4L1ojeprlfPtdvrSrWq8yIjnP8KJ2JbMEgE5Cc+nFHPUtHrnKB5XlRw6qCtUMZT65oPait38vcfr/tVVHmLC/A/cK1e4778tw+vyREOMbteYw38TS0ODxztb0WvaR1dZc0j3c5A3Y7P/AK5Ss/iaz4GwGu4g8OX1NuqpJkcCRkfFA9/rzWpcajRMVQfSMVGlvA5tPQqmZW6Pp22YGVwRLZ4ASY9JWFxGhGuvS8B4eamfddqvh0nTLat9o2OwkNL+/pD8FYlxAvZr/M3dntARkutasdpGCxcNL+4qm3d1SGyfyv8AK6dws7kvnuvhns87SOYu33j+VGUxqV9covmvVrX3G4OGsq95SEf2qsvaBazTO0y2QBi+RXXdT+0rDY1zaLmuoV3ZMd4mvIEkMeAJ6ODSdwKmK3dERQEREBERAREQEREBEWH1i1lw+CZt13wSPCwQXv8A0t39bAbyEGYWja3dpOHws06MV6wsQ0+Bh/M4ZkeyL7jC51rd2iYnFzTZNCifwNPiePzuzP6RAvBnNaUXK4jLaw6xYjGP28RULo8rRZjP0tyHXM7yVhnOVVJrnv2KbS953DcN7iTZrRxK2nQ+rDGw+uWvdmAbU29Af/IfzOgZEApqXqT2wmitC1a8O8lM5PcJLv0Nzd1y33W66K0RSw7bDZnzPcQXu/U7cPytgW9FfClvBM8Teev3A3BW1bDbTwXFzfiLeyfw+so43vV1iGGAAARutaIyLZuOmVuijwWFLDJIjZgAXtI37IPzUzAGCMh75J+JJPvUQxbXGJLSDvtP8emfJRnUtasybuDXZAgwTG780T5b5i2St8diqobLGh35hMx+k3+fRUVcJtE7RIFyIjZE+Y8QTf3nnNz3zWAAm0b5JgZk9OKNNXrVi8ybk/H6rNaLbVDfGbbgbkfT7sFV39Nzw4CHHyvAB2t149L5xvAU7q8eYeoy9fZ9bDiU1bdVlyiLke0TJF1FUcRz9yMhA3KAm0EGOd/8qsnj7vvNUOcjSBzeBMD4+pz6qHajlyGf3zU5zmVE597kchvnejSJ5twH3xy6lW2LxLaY2nmBuGZd0G/143hWek9MMYSKYDn7zub/AOx+5tC16tUc8lzjJO8/Ll0T21IuMVjy6WsAYyfKN/U78sslaSkKPaJy96rStzoWZ1QcW43C1HWDcRRPp3jZ+Cw4aG53PBbBqbhO8x2FafEf6inbcA14LupgG6s9j6eREWVEREBERARFHXrtY0ve4Na0S5ziGgAbyTYBBIocXimUmF9R7WMaJc5xDQBzJyXN9a+1mnTmngmiq/LvXgimOOyLOf1sN8lco03p3EYp+3iKzqhBsCYa39LR4W+gVwdP1u7WAJp4ASbg1niw5sac+rrWyIXKsbjKlV5qVXue9xlznEuJ9T8lZ94p8Hhn1ntp0wNp3tEAC0zzyyF08IhqVALkwFk9Gav1q0OeHUqZykQ90HdIhg5m/AOWxaD1epUpqH+5VbvcPKeDQPKeG/mFnWVc8gd8En0IIkf53LF7+Jf8YvC4WjhwGBoYD1gncS82c7htEcoyV+5siPMIyNiOFov6quoA4RYTuN2u5FY/+mfTMUpEX7t87N89hwvT6XHJWWVwsv8A1kW0QQAS4iIuSPeBEryviWsgExw+UffBW9DF7Utc1zXbwR4hle1nC+Yz4KeiIvIJO8CCQNxVRS0hzfDBac2mDnu3ieWSUqbWneCbw4zB/k8JJPBe1sQ1olxAA+fC2/kqKVdtQGzhFiHCDf76qEK+Ng7IBJgHcBnEcZ6BUUnB7ZbYTkRaQbHKJtm33r2tRm5aHZZ5wMoP8fVVuMTAk8BARpHQptZJynOSI9N9+dza5UON0jsECP3EHZ+Fz6KuliHHNu/deM7Ok2OXv93vcjnHDd7kM+o6L5bLQWcjdp5gfSPVemrHm8J53B9f4MdFU+pFt/36K17xxIj1BBEDnN5+uRF0akS1RNlG4xz+fwXlQbI8JgcDlyA4enuJWH0jp1rLMEv38GngSMzyHrBsquMhisWxjdpzgB8+Q4+i1nSWmHVJDZaz4nrwHIfFWOIrOe7aeZPP5DgOQUZVxuTFKpe8BUuqTZv+AjKcXNzx+8kV4Gk52HD7yUzRuHh58OQHFUd4B6ST6CVLo3B1cQ/ZYCZ+/QIr1oHlaM895cV1zso1Je2o3G1zslsmlT/FLgW7buFiYGckTEQa9SNQAyH1BtO55Doup4TDBjYCmidERAREQERad2ga7MwLNinD8S8SxpyY0yO8fG6RAFtqDwJCQZHWzW7D4Bk1SXVHD+3SbG07n+VvFx9JNlwzWrW7E4501XRTB8NJshjeBI/G78x9ImFidIY2pWe6rWeXvcZc5xufoOAFgLCFalazE1SVQVWQqCgoKNMEH5KohUkKDZ9GaxmQK5JAyqDzAW83tj49Vs9HGNdB2gWnyOmWk8JynlmFzJjo6fJXmCxr6RlhicwbtcOYyPXPgQs9c76HQqRcI2r8TtF0niZAPC0QpG1DMGDyOfp9FgdG6fbUIDvA72cw47tk5yfZN8gJuspVDHDxNt+a0fQzkb52sudliWavCJy928LFl1RhJBNRu8GBUb/FQcjB3Ar3EPqG1OzmkAl4cARxBjxHn9VctJIG2LwJcMwd61Os9ud4+KaVRrxIsDyMcbgxe4z5XKugIsBA4C0KLYtMzzFlZ1sWaZ8TSGW8Q8TR+oASzqJC17ZxkZUb2z9wQo6dcOgg55b55gix9FUXIPSbK1rVXTbyxc3kZ7gDy4Wm6u6TxvVrW2QdrL4T9VGojY8unaFotLY3m+Z3RlxUWKxjaYMkQOJsOW8k8hJ+ax+ldNBktF3cAY/7EeXoPF+la1icQ55lxngMgBwA3Kzy3IvdIaZc8kNlo45OPu8o6XO8nJYxFE+peG3K16aVPeBmo4LuQ+J+iqZT3m5+ASpVhUe2AUTnErwmc1ktFaHfWcABb4evHooq2wGDdVOxTbtONhzPAfXJd01A1NbQpt2gC43e7ifoMgrTUfVJtKDsy45k59OQXTcPRDQAFBVSpBogBVoiAiIgIiINd151mbgMMalnVHHZotP4nkZn8rRc+7MhfO2Mxb6r3VKji973Fz3OMkk/cACwAAFgun9umFcXYV4yDarRwmWEjkSI/wCvJcn2veNy1PCWJGPIMj7911kH0f6jaeyzwJeCYB4EE2mAZkjKYvbGSg/0qyrrUXNMOaWmJggiRxE5jmoiFd18YXtDXBpI/FHiiZies/czaoqgheEKtS4TCOqvaxkS7iYAG9xO4D/UkgGW5Na5l6uSbVqgMLbcXqDimtD2upVGbJc5zHPIbAkiO723WyDWl35QtTI5zzEwed9y5fn+3H6zeOtS+LZfcVAyr2hpJwAbUHesGTXFwjo4XHrI5LHEL0PPVdBvGA0vTfGzb8ps4ADhvHRXjmtLtqSTu3xfcTcDMQLGVzwVB0WXwmnajYDztjj+L37/AFz4rF4+DcASDnBN4An7Fx71Sdk3HhJm4kAkWMjjxn+Fj8FjqdQSNmcyIAPMkfGb9VeBwgGxmzQLD0jlf0WPSZqJ+AglzDsE5iJY7mW5eoMqo4kA7JN+HwgONj0JnmpWuMZen399VhtKY6lTNhLt7RaDzP4fQT0W51rP8sliMY1oJJAAzJsByO+eQvl1WtaR0058hktHtZOPT2B0vxKsMVinVDLjlkBYN6DcoQFqRqTHgCpe8DNUVKsWFyqG0pu6/LcPqtK8JLuQ+JUgaAEe8BWznygkfVnJU06ZJgXKucBo99Uw0H7+S6LqvqbkXCT8lm1WvauaqOqEFwMffu6LrGrmq4YB4VmtDaAawCy2KlTDRAUEWEwoYICuERUEREBFYaV01h8MGnEV6dLaMN23hs8Yk7vgryjVa9oc0hzSJBBBBByIIzCCtERBpnaxgO8wBcBJpPa70PgPp4wf2rhWKw0iR79468R9819RYvDMqsdTqNDmPaWuB3giCFxHXPUx+CcXUnGpRJke2wG8O3OA9oeoGZu+Ec82iDDvTgVWFeVqQd92P0Vi6m5vMcN4+qSlitFSx85KqVrUFd6L0i+g/bZF7PaQCHtkEtuJGQuINgrRFqWy7EjK6W0/UrDZbNKnM7DXOIJ3Txi8CLSViIVUKl5gT/n5LE5k9Rvv9Ov06/rq7VJCoIVRvcHdllnlNpCpDtxEGJOcD1hGVJCpAjJSkKkhRRlUgzOXp6rLaP089hAdLm/GPWx+fNYjZXsJZozukNPFwikC0cTG10ABIHX5LCqgGF5UrgdUkwSOMK3dULrNy4r0Uy67vd9VW5waqDKYA+5UdWtwUdSqSqsLhnPMNEqKiuVsGgtXH1iCQQPvL6rYNWNTZhzxPL7zXV9BauNaB4VBrurOqTWAeFdA0fotrBkrvD4ZrBYKdQeAL1EVBFp+sfaPgcLLdvv6ot3dGHwcoc6dhsbxM8lzHT3ahjq5IpkYanubT8T/AFeRP/UNQdn07rLhcGJxFZrDEhnme4cQxsuIuLxAlcx1i7XqtSWYGn3Qy7yqGufv8rQS1u4y4uz8oXNnkmXuMkmXPcZ2jxJN3H49VNgdHVMQ8MoUnVXcgY+vrZXBBjcVUrVHVKr31Kh8znEuMbhfIDcMgt57INY6lHFswhdtUqxd4Jnu3hpftiLCdkgjfM7lkdA9kNV8OxlXYHsM8R9dw+K6Rq9qlhMHehSAdEF58TiN4k5eiDOoiKArTSOAZWaWvEj5K7RSzRxzW3s9cwmpQyzgLn2JoFp2ajSCPuy+oXsBzWo60al0sQCQ0Byxt59q+fcRhouPf9VC2pudZbZp7VmthXGQS3j95rXqlEOy927/AAukqYhCqCtyxzfof4UlOoD14LUrOJSoi1wuDMkZ2AG+IHzUiLSLcgOnNhJifKXRwnMKp07xIJgAcOJlSuaN/wDpGMgRJPUyVMFGxf7+C82VJC8fAzTFUbKiq1AFHVxM2arZ08Vm1UlSsTyVxQphol2asNpempKaq9q4rgrVz5XlKm5xgCStw1b1Pc8h1Qen1UGF0NoOpWIgW4/ea6lqxqg1oHhvxWw6A1aDQPCt0weBawZKCw0XoZrAJCzTWxYL1Y7TOnMPhGbeJrMpN3bRu48GjzPPIAlUZFRYnEMptL6jmsY0S5ziGtaOJJsFynWDtgJlmAo//rXBA6tpgyeriOhXOdLaUxGKdtYms+sQZaHHwtP5WNhrc4kCUHW9Yu1rDUpZhGHEv9udikN3mIl/Gwg8VzLWHW/GYyRXrEMP/FTmnT5ggGXjk4uWELgLb+AufoFsWr+pWNxcFlPume263xP8BXBrRbGcN4cfQC6ymhNXMVi3Rh6LiN73Cw/gfFdd1c7K8LQh1aaz982b9T6rfMPQaxoaxoa0ZACAPciOY6vdkdNpD8ZUNR3stNhyn6Quj6O0ZRoN2KNNrG8GiPfxV2imqIiICIiAiIgLwheogx+kdFsqtLXNBC5jrV2eRL6NuX3muvKipTBF1zvNnmLr5dx2DfTOzUbH38Fja1G9r/Mcev3mvozWLVKlXaZaJXIdZdTquHMtBLQVeeyxpoeRzHxClZUByUtSmDnY8cj/AJ9VbVaXEerf5Gfz9F0ROqwrRtQge0OIVNTF7mqys2J69cN68FYveXG+SpAzJXj1LVwdZUN5qoBZXRugqtcgMbYkXPDlxUVi6dIuMASStg0ZqtUefEIXR9VNQGsALhJ4n7st9wOrjG7kHOtXdSg2CWromidANaBZZqhg2s3LU9ZO0/AYSWNf/UVRbYow4A5Q5/lbG8SSOCg3KlSDRAWv6y68YLBSK1UGoP8Aip/3KnKQLMni4gc1xzT+v2kcbLQ/+lpH8FElriODn+Y+myDNwtaZhmMEnqSfmqN7052sYysSMKxuGp7nOAqVTzv4G9Id1WjVy6o81ar3VHnzPe4uJ9Xbr5KXBYerWdsUKTqjjyMffVdA1e7JatSH42psj2G3PTgPiqjnNIF5DabTUccg0GPqfRbrq/2Y4vEQ6ue4pnd+Ijpn711/QmrWFwoijSaD7Ru4+pWXTVarq9qBgsLBbT23j8T/ABX4gZBbS0RkvUUBERAREQEREBERAREQEREBERB4QrXG4BlRpa4Agq7RZvMprlOtvZ2HS+iL8vu65dpDR9Si6HtI57l9SlsrA6e1Wo4kHaaAeIAWfPKvmp9MG+R4j+dxVm+mZNx6D/K6LrTqBVw5LmAubu4LR62DqbcbDp4QV0nUqMe1uY5/wFXSwznENaC4nhf/AEtv0DqPVqmXy0HcPqupat6g06UEtQc81R7Pn1CH1RPBu4deK6/oTVinSAsFnMLg2sENCstZtPUsFh3YittFrYAa0S57nGGtG6Sd5sEGQ2GsBNgAJJNgAN/Jc+1n7XMLQ8GEH9XU4tOzSHV8Ha4+EEHiFz3WnWTGaROzWcKNDdh6ZkH9ZzqHqABuAK12q2mywu4cLkH0y9YWv5qay2ndZsfj5GIrbNI/8VOWU44EAy/9xKxLaNOkN3zKzugtU8djI2KRps3vcNkfEfKV0jV7smw1Ih+Ic6u/eMmz8yg5TonRWKxbtnDUXEe0RYfwF0XV3siaIfjKhe7PYbl7/ouoYXCsptDabWsaMg0AD4KZTVWWjNFUcO3Yo02sHIXPU71eoigIiICIiAiIgIiICIiAiIgIiICIiAiIgIiICIiCipSDhDgCDuKxL9WMMXbXdgFEUyC+wujqdPytAV2iKgua626jY7H1HGtiqfdhzu5ptYQ1jZOyTLvE+LExxggGF4iaLDA9j7zbEYsluWywOg/9jHwK3HQmoGBw0FtEPcPxVPF7hkPciJo2gCLBeoiAiIgIiICIiAiIgIiICIiAiIgIiIP/2Q==" /><br />
<br />
"Put this away now, please."<br />
<br />
I approached the trainer during the next break because it allowed me to follow the rules and talk one-on-one to offer feedback. <br />
<br />
"I noticed that you told Chris to put his device away."<br />
<br />
"Yes, I don't need him distracted during this training. I can't believe he brought it in."<br />
<br />
"Okay. I was thinking that maybe you didn't know what that device is and had misinterpreted it. Did you know that it's a note-taking device and he was keeping notes on the class? No? Okay, so what do you think about that?"<br />
<br />
"I thought it was a game or something. I've never seen one of those."<br />
<br />
"I thought that was the case. You didn't ask, either. You seemed intent on shutting it down."<br />
<br />
"Well, I wanted him to pay attention."<br />
<br />
"Do you know now that you prevented him from taking notes on your class? What do you want to do about that?"<br />
<br />
"I'll take care of it."<br />
<br />
"Thank you."<br />
<br />
I just had my first "crucial conversations" type of talk, and it went well. I felt pretty good about it. I was waiting for the apology and explanation and change of behavior. To be honest, I was feeling both useful and a little smug as the instructor walked over to Chris's desk.<br />
<br />
The instructor pointed at his computer bag, said "it's okay to use that now" and returned to the front of the class. No explanation, no apology, no nothing. As if it was not okay earlier, but now the class has reached a different point in the curriculum where it's okay -- no mistakes made, no assumptions, no flaws. I was dumbfounded, but at least Chris was able to take notes.<br />
<br />
I vowed not to correct people based purely on my own assumptions.<br />
<br />
<h3 style="text-align: left;">
Geepaw's Influence</h3>
<div>
<br />
I was co-teaching a class with <a href="https://anarchycreek.com/">Mike "Geepaw" Hill</a> once. He was handling the first hour's introduction. </div>
<div>
<br /></div>
<div>
He stated that one will get out of the class what one puts into it, and he expects that everyone will try to get as much as possible. </div>
<div>
<br /></div>
<div>
However, he said, he expects everyone to be grownups and manage their attention appropriately and therefore he would not be policing the use of phones and computers in the room. </div>
<div>
<br /></div>
<div>
He suggested that one could feel free to take notes, look up references, or whatever as much as necessary as long as they attended the classes and did their best. </div>
<div>
<br /></div>
<div>
I had recently been co-teaching with another trainer who asked that all phones, tablets, and laptops be piled on a table at the back of the room. I remember feeling uncomfortable with what seemed a draconic measure to me, and wondered how students would take notes. I remembered Chris' Newton and felt bad, but didn't confront the very confident trainer at that time.</div>
<div>
<br /></div>
<div>
But now I was with Geepaw in Geepaw's classroom and I felt that what he was saying was right. We work with adults, they are tasked with learning, they are in charge, and there are reasons they may need a computer or tablet out. Some of them took notes, even. Some looked up references. Some were creating email lists of references and a summary of ideas for people who couldn't be there.<br />
<br />
Some people were only allowed to be in the room under a manager's protest, because there were important things going on in their teams - releases, production crises, etc. That they were present in the room at all was a testament to their interest in the topic and their desire to learn even under these difficult circumstances. </div>
<div>
<br /></div>
<div>
Rather than feeling competition from the devices, and disrespect from people using them, GeePaw gave respect and room to the attendees. I suspect they cared more because of it even if one or two of them may not have been paying full attention the whole time. </div>
<div>
<br /></div>
<h3 style="text-align: left;">
Some Reasons You May Allow Devices In Meetings</h3>
<div>
Let's consider twitter again. Here are some of the reasons our tweeps have listed why people may have devices in meetings:</div>
<div>
<ul style="text-align: left;">
<li>Note-taking (see Chris, above)</li>
<li>Remaining available to managers via text/chat/slack</li>
<li>Vision issues mean they can't see your materials except via screen sharing</li>
<li>They are struggling to attend your meeting even though other events pull at their time</li>
<li>They were invited in case they were needed, and are awaiting the need</li>
<li>They're researching (pulling up logs, databases, documents, source code)</li>
<li>They may be summarizing the meeting for people who want to be there, but can't be</li>
<li>They are asking questions of people who should be in the meeting, but aren't</li>
<li>What you didn't allow them to ask, they may be asking on a back-channel so that they can present a more complete idea to the room.</li>
<li>Neurodiverse people may need to "burn off" excessive mental energy -- using the device as a fidget cube (one US president did crossword puzzles during staff meetings while paying attention and asking probing questions)</li>
<li>Recording the meeting</li>
<li>Sketching or sketchnoting the meeting</li>
<li>Documenting the agreements of the meeting for dissemination.</li>
<li>Remaining available for some personal crisis (sick parent, children, pet, house sale, etc)</li>
<li>Fact-checking statements by meeting attendees.</li>
<li>Checking company policy where a violation seems likely</li>
</ul>
<div>
Face it, we can't tell a person's mental state by seeing them type into a computer from a distance. We are fooling ourselves when we think we can. </div>
<div>
<br /></div>
<div>
Until we know for sure, we have only our assumptions.<br />
<br /></div>
<h3 style="text-align: left;">
Summary:</h3>
</div>
<div>
<br />
It is possible, of course, to take the presence of devices in a meeting or training as an affront to one's ego -- "they aren't paying attention to ME" -- or as discourteous disinterest. One is free to do so. Some people do so routinely. </div>
<div>
<br /></div>
<div>
It is also possible that someone at your meeting is "untending" the meeting, paying no attention whatsoever and doing their daily work in your office instead of theirs: physically present but mentally remote. It's also possible that there's a reason for that. </div>
<div>
<br /></div>
<div>
But this issue is a classic case where we can value curiosity over judgment. Maybe it's unfair of us to assume that the device indicates some particular mental attitude (generally one of disrespect) in the device users when we really don't know what they're doing or why. </div>
<div>
<br /></div>
<div>
Its too easy to let ego defenses and Fundamental Attribution Error take over, as it did for our instructor (and I think for my friends who objected so strenuously, citing disrepect) but that may be as counter-productive and destructive to relationships when we do it as it is when my corporate instructor did it.</div>
<div>
<br /></div>
<div>
Maybe we ask first, judge second?<br />
<br />
A little curiosity over judgment can go a long way, as can some Geepaw-style respect for the people we work with. </div>
<div>
<br /></div>
<div>
<a href="https://agileotter.blogspot.com/2018/07/dont-be-dreadful.html">Don't be dreadful.</a></div>
<div>
<br /></div>
</div>
Agileotterhttp://www.blogger.com/profile/10773578598860454277noreply@blogger.com0tag:blogger.com,1999:blog-381129527146258002.post-446613193062364022019-10-04T20:00:00.000-07:002019-10-07T09:05:31.076-07:00Disciplined Breaks, Two Years On<div dir="ltr" style="text-align: left;" trbidi="on">
I described <a href="https://agileotter.blogspot.com/2017/11/taking-breaks-in-disciplined-way.html">Disciplined Breaks</a> here in 2017.<br />
<br />
Sometimes people ask me how that's working.<br />
<br />
I wish my answer was more confident and assertive, but what I can say is "it works great when we do it."<br />
<br />
I use Disciplined Breaks in all of my training and coaching engagements, and often in conference talks. It works. 100% of the time it works. It works so well that people feel like they're cheating. They feel guilty for not being tired.<br />
<br />
When I'm not there to enforce it, the teams practice it sporadically at best. When they work solo, few of them ever continue it (even though it works 100% of the time). Worse, when I work solo, I also sometimes "forget" to do it. Yes, even though it works all the time.<br />
<br />
We are talking about human beings and their sense of sufficiency and power and their work ethic and competitive, go-getter training.<br />
<blockquote class="tr_bq">
<span style="font-size: large;">Disciplined Breaks is a behavioral skill, and all behavioral skills (especially formal disciplines) are hard.</span></blockquote>
We are better at this when it's a special circumstance, an event like training or coaching or mob programming for a week. We're better when we support and remind each other. We're better when it's clearly expected of us. We're better at it when someone in charge expects it of us.<br />
<br />
Lacking some external drivers we tend to be inconsistent -- not just students, but coaches and me individually.<br />
<br />
<br />
Here are some patterns we see:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi0wGjvcKhVFPgOcTGzEspG-oFaP9G8gBjIgtQq7neESEbo5jf5TKyo1UY4PwUIpd2s3IDArk1Cg0FifHURwSbfS7j2e6sci6cGdCFKoFyE0FlDjathfjxaqZcKZLTe5_XYCvnmY0sY5pU/s1600/I+don%2527t+take+breaks.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="436" data-original-width="739" height="188" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi0wGjvcKhVFPgOcTGzEspG-oFaP9G8gBjIgtQq7neESEbo5jf5TKyo1UY4PwUIpd2s3IDArk1Cg0FifHURwSbfS7j2e6sci6cGdCFKoFyE0FlDjathfjxaqZcKZLTe5_XYCvnmY0sY5pU/s320/I+don%2527t+take+breaks.png" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div style="clear: both; text-align: left;">
This is typical non-break-taking behavior. People feel that they have to be nose-at-the-grindstone at all times so they take no breaks and grind through the work all day long. Because they're lacking the energy to do their best work, they have to stay at it even longer to get similar results. </div>
<div style="clear: both; text-align: left;">
<br /></div>
<div style="clear: both; text-align: left;">
As often as not, they make mistakes. When they go home and have some sleep they are refreshed and they realize what they should have done 4 hours into the day yesterday; which they couldn't see at the time. And they discover the mistakes they made, and fix those. </div>
<div style="clear: both; text-align: left;">
<br /></div>
<div style="clear: both; text-align: left;">
They don't take breaks again (nose at the grindstone!) so they're tired by the time they've finished fixing yesterday so they'll have to work twice as long and hard to get their work done today. Maybe they'll do overtime.</div>
<div style="clear: both; text-align: left;">
<br /></div>
When I follow this pattern I can tell how slow and depleted I am by 3pm. I'm aware of being unproductive and "slow" fairly early in the day. I can't concentrate. I'm antsy and have low impulse control. I'm easily distracted. I forget to keep track of my work, my learning, and the time of day even. I'm sort of lost and adrift and trying to force myself to be so.<br />
<br />
Why do I even do it? I think it makes no sense to totally break discipline like that. And yet here we are. I have those bad days. I used to have nothing but.<br />
<br />
So here is an intermediary pattern:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi1p_Mowo00d_Uuj8fU5gS7LsRT67XgoMdcOeBBz00Btj2ksFCCo_6JIYQ3Qvj-yOwv2BCuuu8mYDrzklEfSVDtwyzfd__tBNilefnhq9U5M25mvY7L_n94bGMyElUXX5dceGO1K7IYnDY/s1600/I+skip+my+break.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="431" data-original-width="730" height="188" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi1p_Mowo00d_Uuj8fU5gS7LsRT67XgoMdcOeBBz00Btj2ksFCCo_6JIYQ3Qvj-yOwv2BCuuu8mYDrzklEfSVDtwyzfd__tBNilefnhq9U5M25mvY7L_n94bGMyElUXX5dceGO1K7IYnDY/s320/I+skip+my+break.png" width="320" /></a></div>
<br />
<br />
Here someone takes breaks in the morning or into the afternoon and they are surprised to realize that the breaks work and they're still energized at 2pm!! Since they still have energy, they reason, they don't really need a break so they skip it.<br />
<br />
As a result, the energy level that was created by taking breaks is destroyed by not taking breaks, and the work becomes less energized. Now a break is needed for recovery.<br />
<br />
<blockquote class="tr_bq">
<span style="font-size: large;">We shouldn't need recovery breaks. We take breaks to avoid being tired, not to recover from it. </span> </blockquote>
<br />
But once we're tired, we'll need a bigger break to recover. This is the trap that most people fall into: you end up taking breaks in arrears -- only once you're depleted. But you have to ask yourself, why ever be depleted? What virtue is there in being tired and grumpy and slow-thinking at work?<br />
<br />
I guess it's human nature. We would rather skip prevention, and then if we get sick we can have it cured. After all, we might not get all that sick, and maybe we can avoid both cure and prevention by just not succumbing to illness. Which is poppycock, of course. Human beings need maintenance -- either preventative or curative. But one of those is plannable and predictable and manageable. It's just hard to get past "I'll just push on, I'm sure I'll be fine. Or if I'm not fine, I won't whine about it."<br />
<br />
Of course, when traveling and consulting "I can rest when I get home" is the thought. But that means we'll focus on work and ignore homelife. Not healthy either. I should come home in condition to participate as a family member, husband, friend, neighbor. So that's also silly once we examine it.<br />
<br />
I usually get this pattern "rest when tired" pattern after I've fallen into the pattern of working without breaks for a little while. Returning to Disciplined Breaks requires me to shift my mindset back to taking breaks in advance of work as a preventative measure. Before I shift back to prevention, I mistake my energized state as one that doesn't need rest, rather than one that comes from having rest. An easy mistake to make. Being human is weird.<br />
<br />
This is clearly the better pattern:<br />
<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg7ShD30cjO7_GLWtTZLJQiiBJUzjreQNxNfq8nTrDwHgEe-vLj7fSR4BeWq1uO9WusbcNz4fWfiT9mEPKPawT4qnTrhLFOUJMlri0yFVxqymMI1y1TrScjtaGZ8-FBOH0dnY5Jme1UBeU/s1600/I+take+breaks.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="448" data-original-width="725" height="197" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg7ShD30cjO7_GLWtTZLJQiiBJUzjreQNxNfq8nTrDwHgEe-vLj7fSR4BeWq1uO9WusbcNz4fWfiT9mEPKPawT4qnTrhLFOUJMlri0yFVxqymMI1y1TrScjtaGZ8-FBOH0dnY5Jme1UBeU/s320/I+take+breaks.png" width="320" /></a></div>
Again, back on schedule. We take the breaks so we're energized all day long. We don't skip breaks because we realize that they are to maintain the energy level. We don't need to be tired to take an energy-maintaining break, so we stay full of energy all day long. And the next day. And the next.<br />
<br />
Maybe not on the weekend. Maybe I'll just rest when tired. Or maybe not on vacation, because there's so much to see. Oh, wait. That's the all-red pattern creeping back in. Darn it. Humanity is a tough skill.<br />
<br />
When I stick with the last (all blue) one, I am energized all day. I have good interactions, and I tend to do good work. I even end the day with a list of things I learned and new insights about working.<br />
<br />
When I don't, I don't.<br />
<br />
<br />
<br /></div>
Agileotterhttp://www.blogger.com/profile/10773578598860454277noreply@blogger.com0tag:blogger.com,1999:blog-381129527146258002.post-12162024149847520272019-09-26T09:22:00.000-07:002019-09-26T09:39:35.103-07:00The Coward's Confrontation: Leadership fail<div dir="ltr" style="text-align: left;" trbidi="on">
I want to introduce you all to a term:<br />
<br />
<blockquote class="tr_bq">
Cowards' Confrontation: a rule made in order to avoid having an uncomfortable conversation with an individual, which rule is either selectively relevant or selectively reinforced (or both).</blockquote>
<br />
So, for instance, a 15-person team exists of which only two people ever eat at their desks. One has a cold sandwich and carrot sticks, but the other brings tuna and shrimp freshly heated from the cafeteria's microwave oven. The team has been bothered by the fragrance of the daily seafood and the residue left in the trash can.<br />
<br />
The team (or a manager at the team's request) makes a rule that there will be no eating in the workspace.<br />
<br />
Our sandwich-eater ignores the policy with impunity. After all, this person knows that the policy was about smelly seafood and doesn't apply to them. Nobody, team member or manager, says anything.<br />
<br />
The seafood-eater notices the sandwich-eater's scofflaw behavior and returns to their desk with food one day. They are confronted with "you can't eat here; you know the policy." This is upsetting because sandwich-eater has been eating at their desk. The seafood-eater now feels singled out.<br />
<br />
BECAUSE THEY ARE.<br />
<br />
"We're sorry," say the other team members, "if it were up to us it would be fine, but you know the rule."<br />
<br />
This is the Cowards' Confrontation. Selectively-made, selective-enforced policies that allow people who are afraid of a confrontation to <i>control the behavior of another</i> without actually admitting to being upset or asking them to change.<br />
<br />
<br />
<br />
When you are making team agreements or rules, beware. Don't be the coward cowering behind the Cowards' Confrontation.<br />
<br /></div>
Agileotterhttp://www.blogger.com/profile/10773578598860454277noreply@blogger.com0tag:blogger.com,1999:blog-381129527146258002.post-49838446485808130322019-09-23T10:32:00.009-07:002023-12-12T02:27:46.426-08:00Is It My Fault You Can't Handle The Truth?<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgxpK8h5FtSef2VhHm9IhipUTR7iumd9eMC2BKuhwdetliNI8ZcenHgHaTvXE5YJaP1BwfA1PaIotFQk3Tf-4qfphRUiVDW2q5gR_nH47D3Y2PbpnNEFwZFgYT4rAYtt3HVRLxEWxW2yN0d4qaBEPIUng_-4ihyH03o4JVOGLV0_sNLZEH-mMK-rUHK/s663/CantHandleTruth.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="574" data-original-width="663" height="277" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgxpK8h5FtSef2VhHm9IhipUTR7iumd9eMC2BKuhwdetliNI8ZcenHgHaTvXE5YJaP1BwfA1PaIotFQk3Tf-4qfphRUiVDW2q5gR_nH47D3Y2PbpnNEFwZFgYT4rAYtt3HVRLxEWxW2yN0d4qaBEPIUng_-4ihyH03o4JVOGLV0_sNLZEH-mMK-rUHK/s320/CantHandleTruth.png" width="320" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">You can't handle it!</td></tr></tbody></table><br /><div style="margin-left: 1em; margin-right: 1em;"><br /></div>
<br />
<div style="margin-left: 1em; margin-right: 1em;">
</div>
In 2018 or 2019, I was introduced to the idea of hyper-rationality. I think it was under another name (to be given shortly) and as part of a presentation by George Dinwiddie on, of all things, estimation.<br />
It was a funny place to be introduced to ideas from psychology and family therapy, as well as organizational psychology and collaboration, but there it is.<br />
<br />
It is nice to be smart.<br />
<br />
It's extra nice to be right.</div><div dir="ltr" style="text-align: left;" trbidi="on"><br /></div><div dir="ltr" style="text-align: left;" trbidi="on">It is wonderfully nice to be right, smart, rational, and helpful to others.<br />
<br />
Sometimes we put too much emphasis on being right and forget to be helpful.<br />
<br />
<a href="https://bigthink.com/hyper-rationality">Hyper-rationality</a> is a state of being excessively or inordinately rational. It is a belief in rational <i>truth </i>as an unassailable fortress, that being correct is all that matters.<br />
<br />
For instance, consider the sentiment that if I am <i>right </i>or I am <i>telling the truth</i> then you have no right to be offended or upset. It might feel right, but it sounds wrong.<br />
<br />
When people are acting hyper-rationally, they often expect to be respected and appreciated for having a superior argument, a more data-backed answer, a provable theory. But this seldom happens.<br />
<br />
I'm not going to explore any kind of moral, rational, logical relativism here. That's a different topic. I'm not suggesting that whether gravity or physics or hexagonal architecture are "true" are a matter of personal opinion. I'm not even playing with the idea of "personal realities" here.<br />
<br />
The fact is that being actually, provably, data-based, research-backed, iron-clad RIGHT is sometimes not the most important thing.<br />
<br />
"If the truth bothers you," one may say, "then you are overreacting or overly sensitive." This is a declaration of irresponsibility. It is the hyper-rational way of saying "I am not accountable for any damage, upset, or embarrassment I may cause."<br />
<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://i1.wp.com/www.laszlolaw.com/wp-content/uploads/2015/03/Broken-Windshield.jpeg?resize=468%2C351&ssl=1" style="margin-left: 1em; margin-right: 1em;"><img alt="Not Responsible For Broken Windshield" border="0" src="https://i1.wp.com/www.laszlolaw.com/wp-content/uploads/2015/03/Broken-Windshield.jpeg?resize=468%2C351&ssl=1" /></a></div>
<br />
It reminds me of the bumper stickers on trucks saying that vehicles must stay back at least 200 feet because the driver is not responsible for damage done to other vehicles by falling rocks.</div><div dir="ltr" style="text-align: left;" trbidi="on"><br /></div><div dir="ltr" style="text-align: left;" trbidi="on">A warning is a good thing in this case, and staying back is generally a good idea. <br /><br />My issue is with the statement "Not responsible for broken windshields." It's <b><a href="https://www.laszlolaw.com/responsible-broken-windshields-yeah/">nonsense</a></b> of course. <a href="https://www.ncconsumer.org/news-articles-eg/stay-back-200-feet-not-responsible-for-windshields-is-scare-tactic-to-avoid-insurance-claims.html">The sign on the truck does not let the company off the hook.</a> The company and the driver <b><i>are</i></b> legally responsible for the damage they do.</div><div dir="ltr" style="text-align: left;" trbidi="on">
<br />
The bottom half of the sign tells others "I am irresponsible. Whatever damage I do to you is your problem."<br /><br />When people claim that they are<i> just telling the truth</i> and <i>can't be blamed</i>, it is likewise nonsense. We are always responsible for the words we speak and the actions we take. We're not let off the hook just because it's true.<br />
<br />
<blockquote class="tr_bq" style="text-align: left;">
<b>Sometimes we crave the irresponsibility of Being Right.</b></blockquote>
<br />
Virginia Satir talks to us about being congruent and reminds us how our communication has different layers of meaning.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen="" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/vfkWnQNWCRE/0.jpg" frameborder="0" height="266" src="https://www.youtube.com/embed/vfkWnQNWCRE?feature=player_embedded" width="320"></iframe></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div style="clear: both; text-align: center;">
<br /></div>
<br />
Even if my words are accurate, rational, and true, the way I deliver them may color that truth with an entirely different message.<br />
<br />
Sometimes that message delivered with our "truth" is "screw you, I don't care what you think." That message is never helpful.<br />
<br />
There is the term that Satir used, and which I hinted would be revealed. That term is "super-reasonable."<br />
<br />
This is <a href="https://www.golf-hypnotist.com/virginia-satir-personality-categories/">described</a> by Andrew Fogg as:<br />
<blockquote class="tr_bq">
A super-reasonable person discounts himself and others and respects context only. He frequently knows lots of information and works solely from a logical or objective perspective. He says to himself things like “Everything is just a matter of logic, emotions are a waste of time” and “I must be more intelligent and show how intelligent I am.” Physiologically this stance is rather dry! The super reasonable person only respects the context, while disrespecting themselves and others.</blockquote>
This is explained well in <a href="http://www.satirworkshops.com/files/Stances.pdf">an article at Satir Workshops</a>, using a simple three-part circle diagram as a key.<br />
<br />
The three chunks are Self, Other, and Context.<br />
<br />
The same icon/diagram is used in this lovely sketch describing coherence and imbalance, which is from the 1972 edition of Virginia Satir's book <i><a href="https://www.amazon.com/s?k=9780285648722&i=stripbooks&linkCode=qs">Peoplemaking</a> (</i><span style="font-size: x-small;">original by Barry Ives, modified by Charles Lambdin to work better in this blog</span><i>):</i><br />
<i><br /></i>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://old.hltmag.co.uk/feb17/mart07_09.jpg" style="margin-left: 1em; margin-right: 1em;"><img alt="Image" height="146" src="https://pbs.twimg.com/media/EFaaYnOUwAAcaGl?format=jpg&name=small" width="400" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
Here you see people discounting the needs of the self, then the other, then both the self and the other, then all of the above. Finally, you see the Leveler who is considering all of these aspects and is likely to be successful in collaborations.<br />
<br />
Super-reasonability ignores the humanity of an interaction, assuming that facts and intelligence are all that is needed to make it all work out.<br />
<br />
Often when "objective truth" is presented in a conversation, it is given as a reason to NOT do things one is requested to do, or a reason that other people should do as they are told by the truth-teller.<br />
<br />
In this case, it is a <i>power move</i>. <br />
It is a <i>trump card, </i>an<i> argument-ender, </i>a<i> </i><i><a href="https://www.merriam-webster.com/dictionary/sockdolager" rel="nofollow" target="_blank">sockdolager</a>.</i></div><div dir="ltr" style="text-align: left;" trbidi="on">
It is closer to "blaming" than to "super-reasonable" in such a case.<br />
<br />
If the message is "screw you, I'm right" then likely you're not offending people with the truth but by demeaning or disregarding them. <br />
<br />
All people in positions of power (bosses, managers, consultants, public speakers, recognized experts) need to be careful. When you find yourself in this position, it's time to pause and think more deeply; being right is not enough.<br />
<br />
The truth-teller in this circumstance has been met with a request or a need, and rather than attending to the need or aligning with the person who has come asking, the truth-teller is instead asserting dominance/superiority and shutting down the conversation.<br />
<br />
Why would anyone <i>not</i> take offense at that?<br />
<br />
"I'm just telling the truth" is a mask frequently worn by callous self-centeredness.<br />
<br />
Ouch.<br />
<br />
That describes a great number of bad interactions I've had in the past. Having worked so hard to learn many things, I felt it important to deliver my well-studied truths -- more important than to care for the needs and ambitions and goals of the people around me.<br />
<br />
I said some things not only because I thought they were true at the time (and may have been), but because they gave me a shield from the upset of the others -- my own "stay back 200 ft" sign; my own "get out of responsibility free" card.<br />
<br />
As Michael Mendis described it:<br />
<blockquote class="tr_bq">
"we flee from what we fear, so it can be concluded that hyper-rationalists fear their irrationality and seek to escape from it by taking refuge in an excessive and exaggerated devotion to 'reason.'"</blockquote>
Sometimes we try <i>Being Right</i> to protect ourselves from our own irrationality, from engaging with other people's needs, and so that we can avoid dealing with the emotional and irrational side of other human beings (a side just as scary in them as in ourselves).<br />
<br />
But it's still there.<br />
<br />
Data doesn't make us less human. It should be used in service to humanity rather than as an escape.<br />
<br />
If we have an objective, context-free, helpful truth then why can't it be offered in a way that respects and honors other people?<br />
<br />
Why must it be a conversation stopper/winner, rather than incorporated into the context of the interaction that is focused on meeting the goals of all the people involved? Why can't it be helpful rather than off-putting?<br />
<br />
<blockquote class="tr_bq">
<span style="font-size: large;">Truth does not have to be delivered bluntly and brutally.<br />There is a tradition of "speak the truth in love" to consider.</span></blockquote>
<br />
<br />
A better <a href="https://xkcd.com/1053/">example of helpful truth-giving</a> is from Randall Monroe (AKA xkcd):<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://imgs.xkcd.com/comics/ten_thousand.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="316" data-original-width="462" height="218" src="https://imgs.xkcd.com/comics/ten_thousand.png" width="320" /></a></div>
<br />
<br />
<br />
When you think that others are being hyper-sensitive, perhaps it's a good time to consider whether you are being super-reasonable.<br />
<br />
Some questions to consider:<br />
<br />
<ul style="text-align: left;">
<li>Are you hiding behind rationality? </li>
<li>Are you discounting your place and the other person's place in the interaction? </li>
<li>Are you trying to take a shortcut that is not helpful to your collaborators? </li>
<li>Is it important to you to "win" the conversation?</li>
<li>Are you using rationality to escape responsibility?</li>
</ul>
<br />
<br />
<br /></div>
Agileotterhttp://www.blogger.com/profile/10773578598860454277noreply@blogger.com1tag:blogger.com,1999:blog-381129527146258002.post-23433699197468747862019-09-02T05:00:00.000-07:002019-10-08T17:29:50.612-07:00Q and A on Velocity, part X<div dir="ltr" style="text-align: left;" trbidi="on">
<br class="Apple-interchange-newline" />
In the <a href="http://agileotter.blogspot.com/2019/08/q-and-on-velocity-part-ix.html">last installment</a> we talked about communication between managers and employees, efficiency notions, and other key continuous improvement ideas.<br />
<br />
This installment let's pick up on the idea of doing great work quickly.<br />
<br />
<br />
<blockquote class="tr_bq">
A: You have said several times that something has to change for work to be done faster. Skills and stuff to make the work easier. Is that the right way?<br />
B: <i>If and only if </i>the bottleneck is actually in development, it will help.</blockquote>
<br />
There is some good material here from A. In fact, skills and tools and knowledge can make the work progress faster. A developer with deep knowledge of their tools and stack can get work done in a tiny fraction of the time it takes a less knowledgable developer to figure out how to get a result.<br />
<br />
This is often misinterpreted as "a 10x developer" but really it's a 1x developer surrounded by other 1x people who just don't know the stack, the code base, or the tools as well. If you like a 10x devs, invest in helping them learn to go faster. This is expressed in Modern Agile as <a href="http://modernagile.org/#guidingPrinciples">"Make People Awesome"</a>, and in the Agile Manifesto as "<a href="http://agilemanifesto.org/principles.html">give them the environment and support they need.</a>"<br />
<br />
But let's move on...<br />
<br />
<blockquote class="tr_bq">
A: Okay, then. Let's <i>assume</i> the bottleneck is development. What do we change?<br />
B: Whatever makes it difficult or risky to delivery working code now.<br />
A: How do we know what that is, or what to do instead?<br />
B: Experiment. Some changes help, some not.</blockquote>
<br />
Since I've started this blog series, I have had a series of workshops where I ask the team "what makes you go slow?" It really isn't a difficult question to ask. In the right (blameless) environment, teams are happy to tell you where the problems are.<br />
<br />
Most of the time, teams don't know how to fix the problems, or they don't know how to acquire the time and support they need (see <a href="http://modernagile.org/#guidingPrinciples">Agile Manifesto principles</a>, again) to solve the problem so that they can go fast. Here a <a href="https://agileotter.blogspot.com/2017/09/the-5-ts.html">manager</a> can make a real difference.<br />
<br />
Supporting experiments and other efforts to relieve bottlenecks isn't just good agile practice, or good empiricism, or good Modern Agile ("experiment and learn rapidly"), it's good management and good business. Leaving people stuck with drag-inducing problems while exhorting them to move faster isn't good form. Better to be effective, right?<br />
<br />
<br />
<blockquote class="tr_bq">
A: We can't afford to do that. I told you our schedule is tight. Can we only do things that work and not waste time?<br />
B: If you can't afford to experiment & learn, you can't improve. Do the best you can with the velocity you have. Order work by value. Descope.</blockquote>
<br />
If we can't afford to learn and experiment, then we can't afford to go faster. Full stop.<br />
<br />
Is it okay to be seen learning and trying things at work? What happens if you try something and it doesn't work? How does that line up on the annual review?<br />
<br />
We hope an experimental and informative, mindful approach to software development is seen as a positive by the organization. It has happened, though, that speed is rewarded and knowledge is rewarded, but no concession is made to the acquisition of speed and knowledge. This makes retaining motivated people very difficult.<br />
<br />
<br />
<blockquote class="tr_bq">
A: We can't descope. We can't miss the date. We can't experiment. What else do you have?<br />
B: <i>Fail as well as you can</i>. Give the best result you possibly can, considering that you'll fail.</blockquote>
<br />
We have referred to "the best possible failure" as a goal for timeboxed work. We slice work into pieces and then slice the slices. We find that if we can put a bunch of little slices into the timebox, ordered by importance/priority, then when time runs out and we're not fully finished we will have the most important work finished and integrated.<br />
<br />
The worst failure is to have 100% of the work 90% done. Nothing is deliverable or useful. It's a mess.<br />
<br />
To have 90% of the work 100% done is a qualified success. It's not 100% successful, but that 90% functionality is usable, functional, demonstrable, sellable. It may not satisfy everyone, but it can help some people. It gives partial value, and that's a damned sight better than zero value.<br />
<br />
If you can't go faster, then make the best of the speed you have. Fail as well as possible.<br />
<blockquote class="tr_bq">
<br />
A: Is that all?<br />
<span style="font-family: "times";">B: No. Remember </span><u style="font-family: times;">development may not be the bottleneck</u><span style="font-family: "times";">.</span></blockquote>
<span style="font-family: "times";"><br /></span>
<span style="font-family: "times";">Organizations are shocked and upset to find that their 45-days-to-market lead time can't be improved (much) by speeding up programming because programming isn't the primary consumer of time in their case. </span><br />
<span style="font-family: "times";"><br /></span>
In some cases halving coding time, if even <i>possible</i>, would produce results in 44 days instead of 45. <span style="font-family: "times";"><br /></span>
<span style="font-family: "times";">Software work spends most of its time waiting in queues. </span><br />
<br />
<ul style="text-align: left;">
<li><span style="font-family: "times";">Approval queues. </span></li>
<li><span style="font-family: "times";">Prioritization queues.</span></li>
<li><span style="font-family: "times";">Review queues. </span></li>
<li><span style="font-family: "times";">Waiting for other work to finish first. </span></li>
<li><span style="font-family: "times";">Waiting for testing. </span></li>
<li><span style="font-family: "times";">Waiting to be repaired. </span></li>
<li><span style="font-family: "times";">Waiting until the current production crisis is over. </span></li>
<li><span style="font-family: "times";">Waiting for an expert to answer a question or become available to consult on it. </span></li>
</ul>
<br />
<span style="font-family: "times";">And it's worse than it sounds because these queues are wrapped in loops. </span><br />
<br />
<ol style="text-align: left;">
<li><span style="font-family: "times";">Code waits for the programmer to be available, b/c they're busy on something else</span></li>
<li><span style="font-family: "times";">Programmers work on the code</span></li>
<li><span style="font-family: "times";">The code waits for a code review, b/c the reviewers are busy </span></li>
<li><span style="font-family: "times";">If the code review sends the code back to the programmer for changes, goto 1</span></li>
<li><span style="font-family: "times";">The code waits for a testing build on an official testing server, b/c servers are busy.</span></li>
<li><span style="font-family: "times";">The code waits for a tester to be available, b/c testers are busy.</span></li>
<li><span style="font-family: "times";">The tester waits for the code to be built and installed on an official testing server because the server has just been made available to the freshly-available tester and has to be prepared.</span></li>
<li><span style="font-family: "times";">The testers test the code.</span></li>
<li><span style="font-family: "times";">If any anomalies or improvements are noted, goto 1</span></li>
<li><span style="font-family: "times";">Code waits in a batch with other code to be deployed.</span></li>
<li><span style="font-family: "times";">If there is a problem with deployment, goto 1 for troubleshooting and remediation.</span></li>
</ol>
<br />
<span style="font-family: "times";">What if a change cycles at 4, then 9, then 4 again, then 9 again, then 9 one more time? How long are these waits? </span><br />
<span style="font-family: "times";"><br />If, as is often the case, 95+% of the time is waiting then programming twice as fast may yield you a 2.5% improvement in time-to-market. Whee. Not very impressive is it?<br /><br />But if this is your situation, then it is<i><b> very good news</b></i>. </span><br />
<span style="font-family: "times";"><br /></span>
<span style="font-family: "times";">You don't have to be a technical genius to fix human waits and queues. It only takes someone with some managerial chops and some systems thinking. </span><br />
<span style="font-family: "times";"><br /></span>
<span style="font-family: "times";">You can do it. You can make the BIG difference in time to market.</span><br />
<span style="font-family: "times";"><br /></span>
<span style="font-family: "times";">You can give your staff the<a href="https://agilemanifesto.org/principles.html"> environment and support they need</a>. Is it training? Information? Thought leadership? Faster computers? <a href="https://agileotter.blogspot.com/2014/01/bug-teams-well-meaning-foolishness.html">Learning to prevent defects?</a> Learning to use their programming stack more effectively? Eliminating silos (working together with people rather than queuing)? </span><br />
<span style="font-family: "times";"><br /></span>
<span style="font-family: "times";">You can change the system. You're a manager. You have <a href="http://agileotter.blogspot.com/2017/09/the-5-ts.html">skills and latitude</a>.<br /><br />Isn't that good news?</span></div>
Agileotterhttp://www.blogger.com/profile/10773578598860454277noreply@blogger.com0tag:blogger.com,1999:blog-381129527146258002.post-42696265977951411232019-08-26T07:55:00.001-07:002019-08-29T15:53:03.077-07:00No Common Sense in Agile <div dir="ltr" style="text-align: left;" trbidi="on">
<div style="font-family: Helvetica; font-size: 12px; font-stretch: normal; line-height: normal;">
<span style="font-size: 12pt;">People say that agile is “just common sense.” </span></div>
<div style="font-family: Helvetica; font-size: 12px; font-stretch: normal; line-height: normal;">
<span style="font-size: 12pt;"><br /></span></div>
<div style="font-family: Helvetica; font-size: 12px; font-stretch: normal; line-height: normal;">
<span style="font-size: 12pt;">I wish.</span></div>
<div style="font-family: Helvetica; font-size: 12px; font-stretch: normal; line-height: normal;">
<span style="font-size: 12pt;"><br /></span></div>
<div style="font-family: Helvetica; font-size: 12px; font-stretch: normal; line-height: normal;">
<span style="font-size: 12pt;">I mean, it’s well-precedented and everything makes sense. But there is nothing common about it. </span></div>
<div style="font-family: Helvetica; font-size: 12px; font-stretch: normal; line-height: normal;">
<span style="font-size: 12pt;"><br /></span></div>
<div style="font-family: Helvetica; font-size: 12px; font-stretch: normal; line-height: normal;">
<span style="font-size: 12pt;">It’s still a counter-cultural and counter-intuitive movement, to such an extent that most companies can’t tolerate it and have to compromise and cripple it immediately, even during adoption. Often before adoption.</span></div>
<div style="font-family: Helvetica; font-size: 12px; font-stretch: normal; line-height: normal;">
<span style="font-size: 12pt;"><br /></span></div>
<div style="font-family: Helvetica; font-stretch: normal; line-height: normal;">
Two problems with the “common sense” label:</div>
<div style="font-family: Helvetica; font-size: 12px; font-stretch: normal; line-height: normal;">
</div>
<ul style="text-align: left;">
<li><span style="font-size: 12pt;">It’s not common at all. </span></li>
<li><span style="font-size: 12pt;">It’s unpalatably sensible.</span></li>
</ul>
<br />
<div style="font-family: Helvetica; font-size: 12px; font-stretch: normal; line-height: normal;">
<span style="font-size: 12pt;"><br /></span></div>
<div style="font-family: Helvetica; font-size: 12px; font-stretch: normal; line-height: normal;">
<span style="font-size: 12pt;">Just the simple idea of forming teams with all the skills necessary to do the job — that’s so uncommon as to earn an “uncommonly sensible” label. </span></div>
<div style="font-family: Helvetica; font-size: 12px; font-stretch: normal; line-height: normal; min-height: 13.8px;">
<span style="font-size: 12pt;"></span><br /></div>
<div style="font-family: Helvetica; font-size: 12px; font-stretch: normal; line-height: normal;">
<span style="font-size: 12pt;">The idea of management “providing the environment and support they need” seems so backward to many companies as to be unthinkable (literally — they can’t think this way). </span></div>
<div style="font-family: Helvetica; font-size: 12px; font-stretch: normal; line-height: normal; min-height: 13.8px;">
<span style="font-size: 12pt;"></span><br /></div>
<div style="font-family: Helvetica; font-size: 12px; font-stretch: normal; line-height: normal;">
<span style="font-size: 12pt;">And let’s not even try to penetrate with the idea of producing code that works every week, instead of (traditionally) code that may work someday when all the (traditionally) not-cross-functional teams finish all the bits and pieces and we (traditionally) take time to integrate it all together and test it in the final days and hours before (traditional) release.</span></div>
<div style="font-family: Helvetica; font-size: 12px; font-stretch: normal; line-height: normal; min-height: 13.8px;">
<span style="font-size: 12pt;"></span><br /></div>
<div style="font-family: Helvetica; font-size: 12px; font-stretch: normal; line-height: normal;">
<span style="font-size: 12pt;">And stopping to reflect on how you can do a better job? Most companies lock into a pattern and continue without ever questioning the way they work. For people to not only inspect but reflect and adapt? People scream “too much change! Thrash! Inconsistency! Hard to predict!” ...and stop all forward progress. </span></div>
<br />
<div style="font-family: Helvetica; font-size: 12px; font-stretch: normal; line-height: normal;">
<span style="font-size: 12pt;">Every time someone says “it’s just common sense” I want to ask why people aren’t commonly doing it? Because even companies that identify themselves as “agile” aren’t doing these basic things.</span></div>
<div style="font-family: Helvetica; font-size: 12px; font-stretch: normal; line-height: normal;">
<span style="font-size: 12pt;"><br /></span></div>
<div style="font-family: Helvetica; font-size: 12px; font-stretch: normal; line-height: normal;">
<span style="font-size: 12pt;">And now the aggressively-sensible method is expanded out of software and into other industries where it is equally radical and hard to swallow, but still produces great results. </span></div>
<div style="font-family: Helvetica; font-size: 12px; font-stretch: normal; line-height: normal;">
<span style="font-size: 12pt;"><br /></span></div>
<div style="font-family: Helvetica; font-size: 12px; font-stretch: normal; line-height: normal;">
<span style="font-size: 12pt;">If you’re interested, consider how common and palatable and easy <a href="http://modernagile.org/">ModernAgile</a> is:</span></div>
<div style="font-stretch: normal; line-height: normal;">
</div>
<ul style="text-align: left;">
<li><span style="font-family: "helvetica";">Make (other) People Awesome</span></li>
<li><span style="font-family: "helvetica";">Make Safety The Prerequisite </span></li>
<li><span style="font-family: "helvetica";">Experiment and Learn Rapidly</span></li>
<li><span style="font-family: "helvetica";">Deliver Value Continuously</span></li>
</ul>
<div>
<span style="font-family: "helvetica";">Sensible? Yes.</span></div>
<div>
<span style="font-family: "helvetica";">Principled? Yes.</span></div>
<div>
<span style="font-family: "helvetica";">Common? Not.</span></div>
<br />
<div style="font-family: Helvetica; font-size: 12px; font-stretch: normal; line-height: normal;">
<span style="font-size: 12pt;"><br /></span></div>
<div style="font-family: Helvetica; font-size: 12px; font-stretch: normal; line-height: normal;">
<span style="font-size: 12pt;"><br /></span></div>
<div style="font-family: Helvetica; font-size: 12px; font-stretch: normal; line-height: normal;">
<span style="font-size: 12pt;"><br /></span></div>
<div style="font-family: Helvetica; font-size: 12px; font-stretch: normal; line-height: normal;">
<span style="font-size: 12pt;"><br /></span></div>
<div style="font-family: Helvetica; font-size: 12px; font-stretch: normal; line-height: normal;">
<span style="font-size: 12pt;"><br /></span></div>
<div style="font-family: Helvetica; font-size: 12px; font-stretch: normal; line-height: normal;">
<span style="font-size: 12pt;"><br /></span></div>
<div style="font-family: Helvetica; font-size: 12px; font-stretch: normal; line-height: normal;">
<span style="font-size: 12pt;"><br /></span></div>
</div>
Agileotterhttp://www.blogger.com/profile/10773578598860454277noreply@blogger.com0