<?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 consulting)</title><link>https://barryhawkins.com/</link><description></description><atom:link href="https://barryhawkins.com/blog/categories/consulting.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>The Myth of Commoditized Excellence</title><link>https://barryhawkins.com/blog/posts/the-myth-of-commoditized-excellence/</link><dc:creator>Barry Hawkins</dc:creator><description>&lt;figure&gt;&lt;img src="https://barryhawkins.com/images/the-myth-of-commoditized-excellence.jpg"&gt;&lt;/figure&gt; &lt;div&gt;&lt;img alt="If you give it a name, people will expect you to hand it to them in a box. - Attributed to W. Edwards Deming, but unverified" class="align-center" src="https://barryhawkins.com/images/the-myth-of-commoditized-excellence.jpg"&gt;
&lt;nav class="contents" id="contents" role="doc-toc"&gt;
&lt;p class="topic-title"&gt;&lt;a class="reference internal" href="https://barryhawkins.com/blog/posts/the-myth-of-commoditized-excellence/#top"&gt;Contents&lt;/a&gt;&lt;/p&gt;
&lt;ul class="simple"&gt;
&lt;li&gt;&lt;p&gt;&lt;a class="reference internal" href="https://barryhawkins.com/blog/posts/the-myth-of-commoditized-excellence/#a-new-idea" id="toc-entry-1"&gt;A New Idea&lt;/a&gt;&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;a class="reference internal" href="https://barryhawkins.com/blog/posts/the-myth-of-commoditized-excellence/#desire-to-share" id="toc-entry-2"&gt;Desire to Share&lt;/a&gt;&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;a class="reference internal" href="https://barryhawkins.com/blog/posts/the-myth-of-commoditized-excellence/#affirming-response" id="toc-entry-3"&gt;Affirming Response&lt;/a&gt;&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;a class="reference internal" href="https://barryhawkins.com/blog/posts/the-myth-of-commoditized-excellence/#the-naming" id="toc-entry-4"&gt;The Naming&lt;/a&gt;&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;a class="reference internal" href="https://barryhawkins.com/blog/posts/the-myth-of-commoditized-excellence/#the-movement" id="toc-entry-5"&gt;The Movement&lt;/a&gt;&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;a class="reference internal" href="https://barryhawkins.com/blog/posts/the-myth-of-commoditized-excellence/#pressure-for-simplification" id="toc-entry-6"&gt;Pressure for Simplification&lt;/a&gt;&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;a class="reference internal" href="https://barryhawkins.com/blog/posts/the-myth-of-commoditized-excellence/#fear-of-stagnation" id="toc-entry-7"&gt;Fear of Stagnation&lt;/a&gt;&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;a class="reference internal" href="https://barryhawkins.com/blog/posts/the-myth-of-commoditized-excellence/#commoditizing-the-excellence" id="toc-entry-8"&gt;Commoditizing the Excellence&lt;/a&gt;&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;a class="reference internal" href="https://barryhawkins.com/blog/posts/the-myth-of-commoditized-excellence/#crescendo-of-disillusionment" id="toc-entry-9"&gt;Crescendo of Disillusionment&lt;/a&gt;&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;a class="reference internal" href="https://barryhawkins.com/blog/posts/the-myth-of-commoditized-excellence/#conclusion" id="toc-entry-10"&gt;Conclusion&lt;/a&gt;&lt;/p&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;/nav&gt;
&lt;section id="a-new-idea"&gt;
&lt;h2&gt;&lt;a class="toc-backref" href="https://barryhawkins.com/blog/posts/the-myth-of-commoditized-excellence/#toc-entry-1" role="doc-backlink"&gt;A New Idea&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;When we learn new things from grappling with problems, it is natural for us to want to share those learnings with others, in hopes that they will face similar challenges with less of a struggle.&lt;/p&gt;
&lt;p&gt;How do those well-intended new ideas so often evolve into movements that seem to lose their way, and at times do more harm than good?&lt;/p&gt;
&lt;p&gt;In the course of observing and at times being involved in this phenomenon, I sought to understand what I saw happening time and again. Almost a decade ago, I arrived at an explanation that I named The Myth of Commoditized Excellence. What follows are the steps that can lead down this unfortunate path.&lt;/p&gt;
&lt;p&gt;&lt;a href="https://barryhawkins.com/blog/posts/the-myth-of-commoditized-excellence/"&gt;Read more…&lt;/a&gt; (8 min remaining to read)&lt;/p&gt;&lt;/section&gt;&lt;/div&gt;</description><category>consulting</category><category>culture</category><category>engineering</category><category>process</category><category>product-development</category><guid>https://barryhawkins.com/blog/posts/the-myth-of-commoditized-excellence/</guid><pubDate>Wed, 06 Feb 2019 18:00:00 GMT</pubDate></item><item><title>Empirical Process Control: Why Scrum Works</title><link>https://barryhawkins.com/blog/posts/empirical-process-control-why-scrum-works/</link><dc:creator>Barry Hawkins</dc:creator><description>&lt;figure&gt;&lt;img src="https://barryhawkins.com/images/barry-hawkins-headshot-300x300.jpeg"&gt;&lt;/figure&gt; &lt;div&gt;&lt;p&gt;Being in my ninth year of applying the processes and technical practices of Agile and Lean software development, people are sometimes surprised to hear me say that Scrum is still my preferred process. Let me explain.&lt;/p&gt;
&lt;p&gt;&lt;a href="https://barryhawkins.com/blog/posts/empirical-process-control-why-scrum-works/"&gt;Read more…&lt;/a&gt; (2 min remaining to read)&lt;/p&gt;&lt;/div&gt;</description><category>agile</category><category>consulting</category><category>culture</category><category>lean</category><category>process</category><category>scrum</category><guid>https://barryhawkins.com/blog/posts/empirical-process-control-why-scrum-works/</guid><pubDate>Fri, 13 Apr 2012 20:05:25 GMT</pubDate></item><item><title>The Discipline Deficit</title><link>https://barryhawkins.com/blog/posts/the-discipline-deficit/</link><dc:creator>Barry Hawkins</dc:creator><description>&lt;figure&gt;&lt;img src="https://barryhawkins.com/images/the-discipline-deficit.jpg"&gt;&lt;/figure&gt; &lt;div&gt;&lt;img alt="Are we prepared to incur the costs in order to receive the benefits of this thing we are adopting?" class="align-center" src="https://barryhawkins.com/images/the-discipline-deficit.jpg"&gt;
&lt;p&gt;I consult with all sorts of companies looking to adopt elements of process and practice from the Agile/Lean offerings. Whether it's Scrum, Test-Driven Development, User Stories, Test Automation, Continuous Integration, Agile Estimation and Planning, Sprint Planning, or Sprint Retrospective facilitation, one challenge pervades across most scenarios. I have come to call it The Discipline Deficit.&lt;/p&gt;
&lt;p&gt;&lt;a href="https://barryhawkins.com/blog/posts/the-discipline-deficit/"&gt;Read more…&lt;/a&gt; (1 min remaining to read)&lt;/p&gt;&lt;/div&gt;</description><category>agile</category><category>consulting</category><category>culture</category><category>engineering</category><category>lean</category><category>process</category><category>product-development</category><category>scrum</category><guid>https://barryhawkins.com/blog/posts/the-discipline-deficit/</guid><pubDate>Wed, 22 Feb 2012 20:02:28 GMT</pubDate></item><item><title>Is Agile/Lean as good as it gets?</title><link>https://barryhawkins.com/blog/posts/is-agilelean-as-good-as-it-gets/</link><dc:creator>Barry Hawkins</dc:creator><description>&lt;figure&gt;&lt;img src="https://barryhawkins.com/images/barry-hawkins-headshot-300x300.jpeg"&gt;&lt;/figure&gt; &lt;div&gt;&lt;p&gt;I was recently catching up on episodes of &lt;a title="The Java Posse" href="http://javaposse.com/" target="_blank"&gt;The Java Posse&lt;/a&gt;, and came to the one that features an &lt;a title="Open Space Technology - WIkipedia" href="https://en.wikipedia.org/wiki/Open_Space_Technology" target="_blank"&gt;Open Spaces&lt;/a&gt; topic I convened at last year's Java Posse Roundup, &lt;a title="Java Posse #372 - Roundup '11 - Should We Shoot Agile in the Head?" href="http://javaposse.com/webpage/java-posse-372-roundup-11-should-we-shoot-agile-in-the-head-" target="_blank"&gt;Should We Shoot Agile in the Head?&lt;/a&gt; It was a vibrant conversation with plenty of input from experienced people. At the 49:50 in the recording, &lt;a title="D. J. Hagberg on LinkedIn" href="http://www.linkedin.com/pub/d-j-hagberg/0/906/42a" target="_blank"&gt;D. J. Hagberg&lt;/a&gt; posed an excellent question:&lt;/p&gt;
&lt;blockquote&gt;"Is Agile[/Lean] as good as it gets?"&lt;/blockquote&gt;

&lt;p&gt;I added Lean, since the question really applies to both, their overlap being so great.&lt;/p&gt;
&lt;p&gt;The short answer is no.&lt;/p&gt;
&lt;p&gt;&lt;a href="https://barryhawkins.com/blog/posts/is-agilelean-as-good-as-it-gets/"&gt;Read more…&lt;/a&gt; (1 min remaining to read)&lt;/p&gt;&lt;/div&gt;</description><category>agile</category><category>consulting</category><category>lean</category><category>process</category><category>scrum</category><guid>https://barryhawkins.com/blog/posts/is-agilelean-as-good-as-it-gets/</guid><pubDate>Thu, 26 Jan 2012 18:29:04 GMT</pubDate></item><item><title>Agile: Your Mileage *Will* Vary</title><link>https://barryhawkins.com/blog/posts/agile-your-mileage-will-vary/</link><dc:creator>Barry Hawkins</dc:creator><description>&lt;div&gt;&lt;p&gt;There is one question I can guarantee someone will ask as I begin an engagement with a new client. It usually comes in the second half of the first major session I have, called the Agile Orientation. By that point in the initial training, we have covered the roles and components of Scrum, using it as the primary (and my favored) option for an effective Agile process in most businesses. The looks on at least a few faces at that point let me know that people are starting to process just how disparate their current work life is from what I am describing. One of the more outspoken folks usually asks something like this:&lt;/p&gt;
&lt;blockquote&gt;If Agile requires all these things, and we can only implement part of it, is it still worth doing?&lt;/blockquote&gt;

&lt;p&gt;The answer is yes, with one caveat. A partial adoption results in partial benefits, so expectations should be adjusted accordingly.&lt;/p&gt;
&lt;p&gt;&lt;a href="https://barryhawkins.com/blog/posts/agile-your-mileage-will-vary/"&gt;Read more…&lt;/a&gt; (2 min remaining to read)&lt;/p&gt;&lt;/div&gt;</description><category>agile</category><category>consulting</category><category>process</category><category>scrum</category><guid>https://barryhawkins.com/blog/posts/agile-your-mileage-will-vary/</guid><pubDate>Fri, 11 Nov 2011 17:28:33 GMT</pubDate></item><item><title>Is it just my company that has a hard time with Agile?</title><link>https://barryhawkins.com/blog/posts/is-it-just-my-company-that-has-a-hard-time-with-agile/</link><dc:creator>Barry Hawkins</dc:creator><description>&lt;div&gt;&lt;p&gt;After an Agile adoption is underway and the feedback mechanisms of most Agile processes begin to function, one or more team members usually ask me something like the following:&lt;/p&gt;
&lt;blockquote&gt;Is it just my company that has a hard time with Agile?&lt;/blockquote&gt;

&lt;p&gt;No, it's not just your company. However, don't take comfort in that.&lt;/p&gt;
&lt;p&gt;I shared something on Twitter that I think sums up why companies have a hard time with Agile:&lt;/p&gt;
&lt;blockquote&gt;Agile practices and processes &lt;em&gt;serve&lt;/em&gt; motivated, self-directed teams who work hard. It does not &lt;em&gt;create&lt;/em&gt; them. &lt;a title="Original appearance of text on Twitter" href="https://twitter.com/barryhawkins/status/109663085882654720" target="_blank"&gt;@barryhawkins&lt;/a&gt;&lt;/blockquote&gt;

&lt;p&gt;&lt;a href="https://barryhawkins.com/blog/posts/is-it-just-my-company-that-has-a-hard-time-with-agile/"&gt;Read more…&lt;/a&gt; (2 min remaining to read)&lt;/p&gt;&lt;/div&gt;</description><category>agile</category><category>consulting</category><category>culture</category><category>scrum</category><guid>https://barryhawkins.com/blog/posts/is-it-just-my-company-that-has-a-hard-time-with-agile/</guid><pubDate>Fri, 14 Oct 2011 18:59:15 GMT</pubDate></item><item><title>Ask an Agile Coach: What is an Agile Coach?</title><link>https://barryhawkins.com/blog/posts/ask-an-agile-coach-what-is-an-agile-coach/</link><dc:creator>Barry Hawkins</dc:creator><description>&lt;div&gt;&lt;p&gt;This installment of the &lt;a title="Ask an Agile Coach Series" href="https://barryhawkins.com/blog/categories/ask-an-agile-coach/" target="_blank"&gt;Ask an Agile Coach&lt;/a&gt; series is a question normally asked by persons outside my field, but lately I have been asking it myself:&lt;/p&gt;
&lt;blockquote&gt;What is an Agile Coach?&lt;/blockquote&gt;

&lt;p&gt;Good question. I am not sure anymore.&lt;/p&gt;
&lt;p&gt;&lt;a href="https://barryhawkins.com/blog/posts/ask-an-agile-coach-what-is-an-agile-coach/"&gt;Read more…&lt;/a&gt; (2 min remaining to read)&lt;/p&gt;&lt;/div&gt;</description><category>agile</category><category>ask-an-agile-coach</category><category>consulting</category><category>culture</category><category>scrum</category><guid>https://barryhawkins.com/blog/posts/ask-an-agile-coach-what-is-an-agile-coach/</guid><pubDate>Sat, 08 Oct 2011 00:15:41 GMT</pubDate></item><item><title>Ask an Agile Coach: What Team Members can be shared across multiple Scrum teams?</title><link>https://barryhawkins.com/blog/posts/ask-an-agile-coach-what-team-members-can-be-shared-across-multiple-scrum-teams/</link><dc:creator>Barry Hawkins</dc:creator><description>&lt;div&gt;&lt;p&gt;Welcome to another installment of &lt;a title="Ask an Agile Coach" href="https://barryhawkins.com/blog/categories/ask-an-agile-coach/"&gt;Ask an Agile Coach&lt;/a&gt;. Today's question centers around how to structure teams in light of constrained skill sets in an organization:&lt;/p&gt;
&lt;blockquote&gt;What technical roles, other than QA, can be successfully shared across scrum teams? DBA, UX, etc.? - &lt;a title="Jake Gordon on Twitter" href="https://twitter.com/jakejgordon/status/114692587209760769" target="_blank"&gt;@jakejgordon&lt;/a&gt;&lt;/blockquote&gt;

&lt;p&gt;Strive to have people in dedicated teams; only share in order to get work from &lt;a title="The Rule of Concept to Customer" href="https://barryhawkins.com/the-rule-of-concept-to-customer/"&gt;concept to customer&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;&lt;a href="https://barryhawkins.com/blog/posts/ask-an-agile-coach-what-team-members-can-be-shared-across-multiple-scrum-teams/"&gt;Read more…&lt;/a&gt; (2 min remaining to read)&lt;/p&gt;&lt;/div&gt;</description><category>agile</category><category>ask-an-agile-coach</category><category>consulting</category><category>scrum</category><guid>https://barryhawkins.com/blog/posts/ask-an-agile-coach-what-team-members-can-be-shared-across-multiple-scrum-teams/</guid><pubDate>Fri, 30 Sep 2011 17:53:26 GMT</pubDate></item><item><title>Ask an Agile Coach: Should I count partially complete user stories in my velocity?</title><link>https://barryhawkins.com/blog/posts/ask-an-agile-coach-should-i-count-partially-complete-user-stories-in-my-velocity/</link><dc:creator>Barry Hawkins</dc:creator><description>&lt;div&gt;&lt;p&gt;Hello readers, apologies for the lack of posts lately; lots of work at hand. Today's &lt;a title="Ask an Agile Coach" href="https://barryhawkins.com/blog/categories/ask-an-agile-coach/"&gt;Ask an Agile Coach&lt;/a&gt; question comes from a comment on the &lt;a title="Ask an Agile Coach: How do I handle the effect of carryover on velocity?" href="https://barryhawkins.com/blog/posts/ask-an-agile-coach-how-do-i-handle-the-effect-of-carryover-on-velocity/"&gt;last installment&lt;/a&gt;, which is rephrased here. In one form or another, I have gotten this question for years now:&lt;/p&gt;
&lt;blockquote&gt;Should I count partially complete user stories in my velocity? For example, if I have a 100-point story that's almost done, should I add 80 points to my delivered points total for this sprint?&lt;/blockquote&gt;

&lt;p&gt;The answer is no, you should not.&lt;/p&gt;
&lt;p&gt;&lt;a href="https://barryhawkins.com/blog/posts/ask-an-agile-coach-should-i-count-partially-complete-user-stories-in-my-velocity/"&gt;Read more…&lt;/a&gt; (2 min remaining to read)&lt;/p&gt;&lt;/div&gt;</description><category>agile</category><category>ask-an-agile-coach</category><category>consulting</category><category>scrum</category><guid>https://barryhawkins.com/blog/posts/ask-an-agile-coach-should-i-count-partially-complete-user-stories-in-my-velocity/</guid><pubDate>Fri, 05 Aug 2011 19:55:25 GMT</pubDate></item><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></channel></rss>