<p>If you don’t use automated acceptance tests, <strong>how do you clearly communicate</strong> desires (“requirements”) between the business, the developers, and the testers?</p><p>If you don’t use automated acceptance tests, <strong>how do you monitor the progress</strong> of development?</p><p>If you don’t use automated acceptance tests, <strong>how do you maintain confidence</strong> that the system still works?</p>

If you don’t automate acceptance tests?

<h2><a href="http://blog.gdinwiddie.com/2020/05/18/features-and-stories-large-and-small/" title="Permalink to Features and Stories, Large and Small" rel="bookmark">Features and Stories, Large and Small</a></h2><h3>Monday, May 18, 2020</h3><p>Imagine you work for a company that produces a videoconferencing system. You’ve done pretty well with it, but you’re middle of the pack of competition. Then there’s a worldwide pandemic, and the market for videoconference software explodes. There’s a silver lining in this terrible event. A rising tide lifts all boats, right?</p><p>Maybe not, if the competition has more of what the customers want. It’s critical to remain a viable choice in the eyes of customers.</p><h2><a href="http://blog.gdinwiddie.com/2020/05/17/accommodating-the-unexpected/" title="Permalink to Accommodating the Unexpected" rel="bookmark">Accommodating the Unexpected</a></h2><h3>Sunday, May 17, 2020</h3><p>As I write this, much of the world is in a state of disarray. Many businesses are shut down for fear of spreading the Covid-19 virus, and others have suddenly switched to distributed work over the internet. Most software developers are working in physical isolation. Even those accustomed to working remotely are reporting that the current situation is affecting their ability to get things done.</p><p>I think it is safe to say that no software development organization expected this to happen. No IT department accounted for the disruption in their estimates and plans. While epidemiologists could predict that there would eventually be a worldwide pandemic, even they could not predict the severity or timing of such a disruption.</p><p>How has this affected your work? Are you still expecting to meet the plans made before this happened? Have you given up planning altogether, just trying to get something, anything, done? Or have you looked at how things have been progressing in the last 2 or 3 months and adjusted your expectations?</p><h2><a href="http://blog.gdinwiddie.com/2020/03/29/the-order-of-tests/" title="Permalink to The Order of Tests" rel="bookmark">The Order of Tests</a></h2><h3>Sunday, March 29, 2020</h3><p dir="ltr">It’s been awhile since I’ve done much coding. That’s not my day job anymore, and I lose interest working by myself. In the past week, however, I’ve had a couple opportunities to mob program remotely with the <a href="https://cantoncoders.org/" rel="noreferrer noopener" aria-label="Canton Coders (opens in a new tab)" dir="ltr">Canton Coders</a>. With the COVID-19 restrictions on gathering in person, people are much more likely to work with you virtually.</p><p dir="ltr">So last week I found myself mobbing on the Roman Numeral kata and today on the Zeckendorf kata, both on <a rel="noreferrer noopener" aria-label="cyber-dojo (opens in a new tab)" href="https://cyber-dojo.org/" dir="ltr">cyber-dojo</a>. A lot of fun was had by all, and I rediscovered what I know about Test Driven Development with a bit more clarity.</p><h2><a href="http://blog.gdinwiddie.com/2020/03/05/more-about-development-culture/" title="Permalink to More About Development Culture" rel="bookmark">More About Development Culture</a></h2><h3>Thursday, March 5, 2020</h3><p dir="ltr">Josh Kerievsky <a rel="noreferrer noopener" aria-label=" (opens in a new tab)" href="https://twitter.com/JoshuaKerievsky/status/1235354050662547456" dir="ltr">called me to task</a> for not following up on his <a rel="noreferrer noopener" aria-label="third version of his story (opens in a new tab)" href="https://www.industriallogic.com/blog/one-defect-two-fixes/" dir="ltr">third version of his story</a> of providing a quick fix before a test-driven fix. As I said, I don’t want to be critical of Josh. I will, however, cast a critical eye on the code he has shared.</p><p dir="ltr">For those just tuning in, the <a href="http://blog.gdinwiddie.com/2020/02/14/tdd-options-and-culture/" dir="ltr">previous installment</a> talked about differences between the culture we espouse and the culture we practice. This installment will return to that. </p><h2><a href="http://blog.gdinwiddie.com/2020/02/14/tdd-options-and-culture/" title="Permalink to TDD, Options, and Culture" rel="bookmark">TDD, Options, and Culture</a></h2><h3>Friday, February 14, 2020</h3><p dir="ltr">The background for this post: Gil Zilberfeld posted a <a href="https://twitter.com/gil_zilberfeld/status/1227822517047484416" dir="ltr">link</a> to a blog post by Joshua Kerievsky. <a href="https://twitter.com/gdinwiddie/status/1228130343267586048" dir="ltr">I had some questions</a> and <a href="https://twitter.com/JoshuaKerievsky/status/1228142651225985024" dir="ltr">Josh’s response</a>, to me, seemed to change the story a bit. As I suspected, <a href="https://twitter.com/JoshuaKerievsky/status/1228338929780191233" dir="ltr">the story is hypothetical, and changes</a> to support the intended conclusion. This always makes it very slippery to talk about a story. The details matter. And in this case, the change overwrites the original, without any indication of what has changed. That makes it even harder to have a conversation about it.</p><h2>The Story</h2><p>I’ll give a synopsis of the story here, since it may change again. In brief,</p><UL><LI> “A customer reports a defect. It’s inhibiting them from getting some important work done.”</LI><LI> David finds the defect and test-drives a fix, including refactoring to re-design the code around the defect. He spends two hours doing so.</LI><LI> In a parallel universe, Sally finds the same defect, fixes it without an automated test, hand-tests the fix, pronounces it good and pushes it to production. There’s no indication of how long this took, but presumably it’s intended to be less than two hours. </LI></UL><h2><a href="http://blog.gdinwiddie.com/2019/11/23/daily-stand-up-meetings/" title="Permalink to Daily Stand-Up Meetings" rel="bookmark">Daily Stand-Up Meetings</a></h2><h3>Saturday, November 23, 2019</h3><p>It’s my observation from watching small groups of people working  together that it’s almost universally common that some people will take  charge and direct the common effort and others will get quiet,  abdicating any such role. </p><p dir="ltr">It’s also my observation that, even in a small team working together  daily, people notice different things, interpret the things they notice  differently, and assign different significance to those interpretations.  People often think that because they are immersed in a common experience  that there’s no need to talk about it. This appears to not be so. <br dir="ltr"> <br dir="ltr">Groups of technically oriented people often want to optimize the work  process to those activities needed for the technically oriented output,  and overlook those that are focused on the needs of humans and groups of  humans working together. Yes, you can have a standup and not get any  value from it. You can also not have a standup and avoid providing a  convenient mechanism for taking advantage of the differences in  observation, interpretation, and significance made by the entire team. <br dir="ltr"> <br dir="ltr">If you’ve got a really good team facilitator, they’ll likely notice this  and help bring it out. If they’re really excellent, they’ll convince the  team to work in a fashion where it can more easily come out without them  acting as a middleman to make it happen. They might use a simple  technique such as a daily standup to create such an opportunity. </p><h2><a href="http://blog.gdinwiddie.com/2019/09/11/i-wrote-a-book/" title="Permalink to I Wrote a Book" rel="bookmark">I Wrote a Book</a></h2><h3>Wednesday, September 11, 2019</h3><p>You may have noticed I haven’t been writing much on my blog. That’s because I’ve been writing a book, instead.</p><figure><img src="https://imagery.pragprog.com/products/563/gdestimate_xlargebeta.jpg?1560874794" alt="Book: Software Estimation Without Guessing" width="250" height="300"></figure><p dir="ltr">I’ve <a rel="noreferrer noopener" aria-label="self-published (opens in a new tab)" href="http://idiacomputing.com/publications/#Books" dir="ltr">self-published</a> before, both solo and with co-authors. This is my first professionally edited book, though. </p><p dir="ltr">It’s been a lot of work, but my editor, <a href="http://www.serendipity23editorial.com/" dir="ltr">Adaobi Obi Tulton</a>, has helped me create a much better book than I would have created by myself.</p><p dir="ltr">Take a stroll over to <a href="https://pragprog.com/book/gdestimate/software-estimation-without-guessing" rel="noreferrer noopener" aria-label=" (opens in a new tab)" dir="ltr">Pragmatic Bookshelf </a>where you can buy it. And after you read it, I’d love to hear what you think.</p><h2><a href="http://blog.gdinwiddie.com/2019/08/21/a-metric-for-story-readiness/" title="Permalink to A Metric for Story Readiness" rel="bookmark">A Metric for Story Readiness</a></h2><h3>Wednesday, August 21, 2019</h3><p>A friend asked for suggestions on a metric for backlog grooming. I’ve never written down these numbers, but this is the metric I use in my head.</p><h2><a href="http://blog.gdinwiddie.com/2018/08/12/audacious-salon-2018/" title="Permalink to Audacious Salon 2018" rel="bookmark">Audacious Salon 2018</a></h2><h3>Sunday, August 12, 2018</h3><p>Agile 2018 has come to an end. Once again, virtually all of my time was spent in the Audacious Salon, where I was a track chair. Once again, it was an immersive and powerful experience for me.</p><p>It‘s time, perhaps past time, for me to describe the salon to the world. To describe how it came to be, the intent, the evolution, and the magic I’ve seen flourish.</p><p dir="ltr">This description is, of course, the viewpoint of one man. Undoubtedly I‘m biased. Understandably, others will have different viewpoints based on different hopes and wishes, different experiences, and different knowledge. I invite you to share these differences in the comments, even if your viewpoint seems negative toward the concept. Perhaps particularly if you have some complaint, doubt, or fear about the Salon. I, or we, can learn most from a diversity of opinion from diverse people.  <a href="http://blog.gdinwiddie.com/2018/08/12/audacious-salon-2018/#more-1309" dir="ltr"><span dir="ltr">(Continued)</span></a>          </p><h2><a href="http://blog.gdinwiddie.com/2016/09/03/using-a-good-tool-for-the-wrong-thing/" title="Permalink to Using a good tool for the wrong thing" rel="bookmark">Using a good tool for the wrong thing</a></h2><h3>Saturday, September 3, 2016</h3><p dir="ltr">When I first met Andreas Schliep, he told me a consulting war story with the punch line, “Well, you can paint that wall with a screwdriver if you like…” There’s no stopping people who are intent to use the wrong tool for a job, or use it in the wrong way. Sometimes it even works. I’ve seen someone successfully, after a fashion, driving wood screws with a hammer. <a href="http://blog.gdinwiddie.com/2016/09/03/using-a-good-tool-for-the-wrong-thing/#more-1300" dir="ltr"><span dir="ltr">(Continued)</span></a>          </p>

remotework

Remote Work

corporateculture

Corporate Culture

business

Business

creativity

Creativity

humanresources

Human Resources

<p>Imagine you work for a company that produces a videoconferencing system. You’ve done pretty well with it, but you’re middle of the pack of competition. Then there’s a worldwide pandemic, and the market for videoconference software explodes. There’s a silver lining in this terrible event. A rising tide lifts all boats, right? </p>

<p>Maybe not, if the competition has more of what the customers want. It’s critical to remain a viable choice in the eyes of customers. </p>

<p>As I write this, much of the world is in a state of disarray. Many businesses are shut down for fear of spreading the Covid-19 virus, and others have suddenly switched to distributed work over the internet. Most software developers are working in physical isolation. Even those accustomed to working remotely are reporting that the current situation is affecting their ability to get things done. </p>

<p>I think it is safe to say that no software development organization expected this to happen. No IT department accounted for the disruption in their estimates and plans. While epidemiologists could predict that there would eventually be a worldwide pandemic, even they could not predict the severity or timing of such a disruption. </p>

<p>How has this affected your work? Are you still expecting to meet the plans made before this happened? Have you given up planning altogether, just trying to get something, anything, done? Or have you looked at how things have been progressing in the last 2 or 3 months and adjusted your expectations? </p>

<p>It’s been awhile since I’ve done much coding. That’s not my day job anymore, and I lose interest working by myself. In the past week, however, I’ve had a couple opportunities to mob program remotely with the <a href="https://cantoncoders.org/">Canton Coders </a>. With the COVID-19 restrictions on gathering in person, people are much more likely to work with you virtually. </p>

<p>So last week I found myself mobbing on the Roman Numeral kata and today on the Zeckendorf kata, both on <a href="https://cyber-dojo.org/">cyber-dojo </a>. A lot of fun was had by all, and I rediscovered what I know about Test Driven Development with a bit more clarity. </p>

<p>Josh Kerievsky <a href="https://twitter.com/JoshuaKerievsky/status/1235354050662547456">called me to task </a>for not following up on his <a href="https://www.industriallogic.com/blog/one-defect-two-fixes/">third version of his story </a>of providing a quick fix before a test-driven fix. As I said, I don’t want to be critical of Josh. I will, however, cast a critical eye on the code he has shared. </p>

<p>For those just tuning in, the <a href="http://blog.gdinwiddie.com/2020/02/14/tdd-options-and-culture/">previous installment </a>talked about differences between the culture we espouse and the culture we practice. This installment will return to that. </p>

<p>The background for this post: Gil Zilberfeld posted a <a href="https://twitter.com/gil_zilberfeld/status/1227822517047484416">link </a>to a blog post by Joshua Kerievsky. <a href="https://twitter.com/gdinwiddie/status/1228130343267586048">I had some questions </a>and <a href="https://twitter.com/JoshuaKerievsky/status/1228142651225985024">Josh’s response </a>, to me, seemed to change the story a bit. As I suspected, <a href="https://twitter.com/JoshuaKerievsky/status/1228338929780191233">the story is hypothetical, and changes </a>to support the intended conclusion. This always makes it very slippery to talk about a story. The details matter. And in this case, the change overwrites the original, without any indication of what has changed. That makes it even harder to have a conversation about it. </p>

<p>I’ll give a synopsis of the story here, since it may change again. In brief, </p>

<ul><li>“A customer reports a defect. It’s inhibiting them from getting some important work done.” </li><li>David finds the defect and test-drives a fix, including refactoring to re-design the code around the defect. He spends two hours doing so. </li><li>In a parallel universe, Sally finds the same defect, fixes it without an automated test, hand-tests the fix, pronounces it good and pushes it to production. There’s no indication of how long this took, but presumably it’s intended to be less than two hours. </li> </ul>

<p>It’s my observation from watching small groups of people working together that it’s almost universally common that some people will take charge and direct the common effort and others will get quiet, abdicating any such role. </p>

<p>It’s also my observation that, even in a small team working together daily, people notice different things, interpret the things they notice differently, and assign different significance to those interpretations. People often think that because they are immersed in a common experience that there’s no need to talk about it. This appears to not be so. <br><br>Groups of technically oriented people often want to optimize the work process to those activities needed for the technically oriented output, and overlook those that are focused on the needs of humans and groups of humans working together. Yes, you can have a standup and not get any value from it. You can also not have a standup and avoid providing a convenient mechanism for taking advantage of the differences in observation, interpretation, and significance made by the entire team. <br><br>If you’ve got a really good team facilitator, they’ll likely notice this and help bring it out. If they’re really excellent, they’ll convince the team to work in a fashion where it can more easily come out without them acting as a middleman to make it happen. They might use a simple technique such as a daily standup to create such an opportunity. </p>

<p>You may have noticed I haven’t been writing much on my blog. That’s because I’ve been writing a book, instead. </p>

<p>I’ve <a href="http://idiacomputing.com/publications/#Books">self-published </a>before, both solo and with co-authors. This is my first professionally edited book, though. </p>

<p>It’s been a lot of work, but my editor, <a href="http://www.serendipity23editorial.com/">Adaobi Obi Tulton </a>, has helped me create a much better book than I would have created by myself. </p>

<p>Take a stroll over to <a href="https://pragprog.com/book/gdestimate/software-estimation-without-guessing">Pragmatic Bookshelf </a>where you can buy it. And after you read it, I’d love to hear what you think. </p>

<p>A friend asked for suggestions on a metric for backlog grooming. I’ve never written down these numbers, but this is the metric I use in my head. </p>

<p>Agile 2018 has come to an end. Once again, virtually all of my time was spent in the Audacious Salon, where I was a track chair. Once again, it was an immersive and powerful experience for me. </p>

<p>It‘s time, perhaps past time, for me to describe the salon to the world. To describe how it came to be, the intent, the evolution, and the magic I’ve seen flourish. </p>

<p>This description is, of course, the viewpoint of one man. Undoubtedly I‘m biased. Understandably, others will have different viewpoints based on different hopes and wishes, different experiences, and different knowledge. I invite you to share these differences in the comments, even if your viewpoint seems negative toward the concept. Perhaps particularly if you have some complaint, doubt, or fear about the Salon. I, or we, can learn most from a diversity of opinion from diverse people. <a href="http://blog.gdinwiddie.com/2018/08/12/audacious-salon-2018/#more-1309"><span>(Continued) </span> </a> </p>

<p>When I first met Andreas Schliep, he told me a consulting war story with the punch line, “Well, you can paint that wall with a screwdriver if you like…” There’s no stopping people who are intent to use the wrong tool for a job, or use it in the wrong way. Sometimes it even works. I’ve seen someone successfully, after a fashion, driving wood screws with a hammer. <a href="http://blog.gdinwiddie.com/2016/09/03/using-a-good-tool-for-the-wrong-thing/#more-1300"><span>(Continued) </span> </a> </p>

George Dinwiddie's blog

If you don’t automate acceptance tests?

Related collections

Other curated ideas on this topic: