<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="../../assets/xml/rss.xsl" media="all"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Barry Hawkins (Posts about agile-with-external-clients)</title><link>https://barryhawkins.com/</link><description></description><atom:link href="https://barryhawkins.com/blog/categories/agile-with-external-clients.xml" rel="self" type="application/rss+xml"></atom:link><language>en</language><copyright>Contents © 2026 &lt;a href="mailto:barry@barryhawkins.com"&gt;Barry Hawkins&lt;/a&gt; &lt;br /&gt;
&lt;a rel="license" href="https://creativecommons.org/licenses/by-nc-sa/4.0/"&gt;&lt;img alt="Creative Commons License" style="border-width:0" src="https://licensebuttons.net/l/by-nc-sa/4.0/88x31.png" /&gt;&lt;/a&gt;&lt;br /&gt;&lt;span xmlns:dct="http://purl.org/dc/terms/" property="dct:title"&gt;Barry Hawkins' website&lt;/span&gt; by &lt;a xmlns:cc="http://creativecommons.org/ns#" href="http://barryhawkins.com/about/" property="cc:attributionName" rel="cc:attributionURL"&gt;Barry Hawkins&lt;/a&gt; is licensed under a &lt;a rel="license" href="https://creativecommons.org/licenses/by-nc-sa/4.0/"&gt;Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License&lt;/a&gt;.</copyright><lastBuildDate>Fri, 07 Aug 2026 19:27:32 GMT</lastBuildDate><generator>Nikola (getnikola.com)</generator><docs>http://blogs.law.harvard.edu/tech/rss</docs><item><title>Agile with External Clients: Testing Is Not Optional</title><link>https://barryhawkins.com/blog/posts/agile-with-external-clients-testing-is-not-optional/</link><dc:creator>Barry Hawkins</dc:creator><description>&lt;div&gt;&lt;p&gt;Today's installment in the &lt;a title="Agile with External Clients" href="https://barryhawkins.com/blog/categories/agile-with-external-clients/"&gt;Agile with External Clients&lt;/a&gt; series covers the topic of testing. A decade after The Agile Manifesto and over 16 years since Scrum and XP came on the scene, I still encounter a large number of teams where the use of testing is lip service at best and non-existent all too often. In this context, testing means the use of frameworks like &lt;a title="xUnit on Wikipedia" href="http://en.wikipedia.org/wiki/XUnit" target="_blank"&gt;xUnit&lt;/a&gt; et al to create of a suite of unit, integration, and functional tests that exercise a body of code by executing it and making assertions about the outcome of that execution at multiple levels of focus and granularity. Of all the practices of Agile software development, both process and technical, testing is the one people most readily acknowledge the value of while at the same time avoiding it altogether. So, let me make this quite plain:&lt;/p&gt;
&lt;p&gt;&lt;em&gt;Testing is not optional.&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;&lt;a href="https://barryhawkins.com/blog/posts/agile-with-external-clients-testing-is-not-optional/"&gt;Read more…&lt;/a&gt; (3 min remaining to read)&lt;/p&gt;&lt;/div&gt;</description><category>agile</category><category>agile-with-external-clients</category><category>consulting</category><category>scrum</category><guid>https://barryhawkins.com/blog/posts/agile-with-external-clients-testing-is-not-optional/</guid><pubDate>Tue, 12 Jul 2011 17:51:10 GMT</pubDate></item><item><title>Agile with External Clients: Master User Story Facilitation</title><link>https://barryhawkins.com/blog/posts/agile-with-external-clients-master-user-story-facilitation/</link><dc:creator>Barry Hawkins</dc:creator><description>&lt;div&gt;&lt;p&gt;The &lt;a title="Agile with External Clients Series" href="https://barryhawkins.com/blog/categories/agile-with-external-clients/"&gt;Agile with External Clients&lt;/a&gt; series continues today with the topic of requirements facilitation and management, with user stories as the primary vehicle for the task. This article's mantra is captured by one of my favorite phrases around Agile, which comes from the last sentence of the &lt;a title="The Agile Alliance" href="https://www.agilealliance.org"&gt;Agile Alliance&lt;/a&gt; website's entry, &lt;a title="What is Agile Software Development?" href="https://www.agilealliance.org/agile101/" target="_blank"&gt;What is Agile Software Development?&lt;/a&gt;:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;…to craft the code and the team such that the inevitable requirements churn was not a crisis.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;This is the core difference for me between Agile Software Development approaches and the phased, non-iterative processes that dominate much, if not most, of the industry. Over the years, the most effective tool I have had in my arsenal for transitioning groups into more iterative, collaborative approaches to gathering, refining, and prioritizing requirements has been user stories. When I say user stories, I am referring to the format and philosophy laid out by &lt;a title="Mike Cohn" href="https://www.mountaingoatsoftware.com/company/about-mike-cohn" target="_blank"&gt;Mike Cohn&lt;/a&gt; in his indispensable book &lt;a title="User Stories Applied: For Agile Software Development" href="http://www.mountaingoatsoftware.com/books/user-stories-applied" target="_blank"&gt;User Stories Applied: For Agile Software Development&lt;/a&gt;. I am not referring to the user stories as defined in &lt;a title="Behavior-Driven Development" href="http://behaviour-driven.org" target="_blank"&gt;Behaviour-Driven Development&lt;/a&gt; (BDD), but that is another topic for another time.&lt;/p&gt;
&lt;p&gt;&lt;a href="https://barryhawkins.com/blog/posts/agile-with-external-clients-master-user-story-facilitation/"&gt;Read more…&lt;/a&gt; (3 min remaining to read)&lt;/p&gt;&lt;/div&gt;</description><category>agile</category><category>agile-with-external-clients</category><category>consulting</category><category>scrum</category><guid>https://barryhawkins.com/blog/posts/agile-with-external-clients-master-user-story-facilitation/</guid><pubDate>Fri, 27 May 2011 18:14:49 GMT</pubDate></item><item><title>Agile with External Clients: To Run It Agile, Sell It Agile</title><link>https://barryhawkins.com/blog/posts/agile-with-external-clients-to-run-it-agile-sell-it-agile/</link><dc:creator>Barry Hawkins</dc:creator><description>&lt;div&gt;&lt;p&gt;This installation of the &lt;a href="https://barryhawkins.com/blog/categories/agile-with-external-clients/"&gt;Agile with External Clients&lt;/a&gt; series shows the relationship between how an engagement is sold and how that affects a group's attempt to execute the project using an Agile approach. Let's start with a maxim for every member of a professional services group or consulting practice to burn into their mind:&lt;/p&gt;
&lt;p style="padding-left: 30px;"&gt;&lt;strong&gt;The Sold Destiny Principle&lt;/strong&gt;&lt;/p&gt;

&lt;p style="padding-left: 30px;"&gt;&lt;em&gt;The way something is packaged and sold frames the expectations of the customer.&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;One of my first questions when engaging with a new client is "How is your product/service sold?" This is an important question because of &lt;a title="The Sold Destiny Principle" href="https://barryhawkins.com/the-sold-destiny-principle/"&gt;The Sold Destiny Principle&lt;/a&gt;. If services are being sold in a way that does not dovetail seamlessly into how those services are delivered, the team builds friction into the way their work is done, heaping frustration upon all parties involved, including the customers.&lt;/p&gt;
&lt;p&gt;&lt;a href="https://barryhawkins.com/blog/posts/agile-with-external-clients-to-run-it-agile-sell-it-agile/"&gt;Read more…&lt;/a&gt; (3 min remaining to read)&lt;/p&gt;&lt;/div&gt;</description><category>agile</category><category>agile-with-external-clients</category><category>consulting</category><category>process</category><category>scrum</category><guid>https://barryhawkins.com/blog/posts/agile-with-external-clients-to-run-it-agile-sell-it-agile/</guid><pubDate>Wed, 25 May 2011 23:07:41 GMT</pubDate></item><item><title>Agile with External Clients</title><link>https://barryhawkins.com/blog/posts/agile-with-external-clients/</link><dc:creator>Barry Hawkins</dc:creator><description>&lt;div&gt;&lt;p&gt;I speak at conferences around the country each year, most often on the topic of real-world, full-blown application of &lt;a href="http://en.wikipedia.org/wiki/Agile_software_development"&gt;Agile Software Development&lt;/a&gt; using &lt;a href="http://en.wikipedia.org/wiki/Scrum_%28development%29"&gt;Scrum&lt;/a&gt;. I always appreciate when folks come to me after the end of a conference talk to ask questions about the topic of adopting or applying Agile in various scenarios. I usually end up having at least a couple new challenges to my assumptions, which helps me further inspect and adapt my approach to coaching and mentoring.&lt;/p&gt;
&lt;p&gt;I will almost always have at least one person who presents what they think is &lt;em&gt;the&lt;/em&gt; tough question, the one area where Agile and Scrum simply cannot work. The question, in the form an assertion, usually goes something like this:&lt;/p&gt;
&lt;p&gt;&lt;em&gt;"This stuff is all well and good when you are working inside a company and your clients are the people that work with you in the same company, but our clients are external customers, and we have fixed-bid projects, which is why we cannot use anything like this."&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;The embedded question in statements like the one above is, "Can Agile, and Scrum in particular, be used when you do professional services work for external clients, even with fixed-bid projects?"&lt;/p&gt;
&lt;p&gt;Yes, you can.&lt;/p&gt;
&lt;p&gt;&lt;a href="https://barryhawkins.com/blog/posts/agile-with-external-clients/"&gt;Read more…&lt;/a&gt; (1 min remaining to read)&lt;/p&gt;&lt;/div&gt;</description><category>agile</category><category>agile-with-external-clients</category><category>consulting</category><category>process</category><category>scrum</category><guid>https://barryhawkins.com/blog/posts/agile-with-external-clients/</guid><pubDate>Mon, 23 May 2011 16:51:32 GMT</pubDate></item></channel></rss>