<?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 lean)</title><link>https://barryhawkins.com/</link><description></description><atom:link href="https://barryhawkins.com/blog/categories/lean.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 API for Teams</title><link>https://barryhawkins.com/blog/posts/the-api-for-teams/</link><dc:creator>Barry Hawkins</dc:creator><description>&lt;figure&gt;&lt;img src="https://barryhawkins.com/images/the-api-for-teams-whiteboard.jpg"&gt;&lt;/figure&gt; &lt;div&gt;&lt;img alt="The API for Teams in an IDE" class="align-center" src="https://barryhawkins.com/images/the-api-for-teams-whiteboard.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-api-for-teams/#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-api-for-teams/#a-common-contract-for-teams" id="toc-entry-1"&gt;A Common Contract for Teams&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-api-for-teams/#team-getbacklog" id="toc-entry-2"&gt;Team.getBacklog()&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-api-for-teams/#team-getthroughput" id="toc-entry-3"&gt;Team.getThroughput()&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-api-for-teams/#team-getroadmap" id="toc-entry-4"&gt;Team.getRoadmap()&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-api-for-teams/#team-getstakeholdermap" id="toc-entry-5"&gt;Team.getStakeholderMap()&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-api-for-teams/#conclusion" id="toc-entry-6"&gt;Conclusion&lt;/a&gt;&lt;/p&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;/nav&gt;
&lt;section id="a-common-contract-for-teams"&gt;
&lt;h2&gt;&lt;a class="toc-backref" href="https://barryhawkins.com/blog/posts/the-api-for-teams/#toc-entry-1" role="doc-backlink"&gt;A Common Contract for Teams&lt;/a&gt;&lt;/h2&gt;
&lt;p&gt;In evolving toward greater agility, we must strike a balance between uniformity across teams and allowing flexibility for process tailored to unique team contexts.&lt;/p&gt;
&lt;p&gt;As your organization grows from 2 to 10 to 50 teams, you have to be able to coalesce their delivery queues into an overall picture of what is being developed. However, if you push for too much uniformity, the process is no longer &lt;a class="reference external" href="https://barryhawkins.com/blog/posts/four-outcomes-of-effective-development-process/"&gt;effective&lt;/a&gt; for all the types of work that go into developing your product, often to the detriment of quality and timely delivery.&lt;/p&gt;
&lt;p&gt;Seeking that balance, I asked myself years ago what is the minimal commonality needed across teams. Coming from a (mostly back-end Java) programming background, I was inclined to express this in terms of an &lt;a class="reference external" href="https://en.wikipedia.org/wiki/Application_programming_interface"&gt;API&lt;/a&gt;. I call it The API for Teams.&lt;/p&gt;
&lt;p&gt;&lt;a href="https://barryhawkins.com/blog/posts/the-api-for-teams/"&gt;Read more…&lt;/a&gt; (3 min remaining to read)&lt;/p&gt;&lt;/section&gt;&lt;/div&gt;</description><category>agile</category><category>lean</category><category>process</category><category>product-development</category><category>scrum</category><guid>https://barryhawkins.com/blog/posts/the-api-for-teams/</guid><pubDate>Tue, 15 Jan 2019 19:30:00 GMT</pubDate></item><item><title>IBM developerWorks Podcast: Barry Hawkins on agile software development</title><link>https://barryhawkins.com/blog/posts/ibm-developerworks-podcast-barry-hawkins-on-agile-software-development/</link><dc:creator>Barry Hawkins</dc:creator><description>&lt;div&gt;&lt;p&gt;Earlier this year, my friend &lt;a title="Andrew Glover" href="https://www.linkedin.com/in/ajglover/" target="_blank"&gt;Andrew Glover&lt;/a&gt; interviewed me for season 4 of his &lt;a title="IBM developerWorks Java technical podcast series: Season 4" href="https://itunes.apple.com/us/podcast/barry-hawkins-on-agile-software-development/id153607292?i=1000112447106&amp;amp;mt=2" target="_blank"&gt;IBM developerWorks Java Technical Podcast series (iTunes)&lt;/a&gt; on the topic of Agile software development. The episode is titled "Barry Hawkins on agile software development" and runs 41:03 in length.&lt;/p&gt;
&lt;p&gt;This was an enjoyable interview; I've known Andy for years, and his style as an interviewer is quite comfortable and flows conversationally. What I really enjoyed about the venue is that it afforded me the chance to talk about software development, the Agile ecosystem, and the primacy of a healthy company culture in ways that I typically do in one-on-one or small group discussions, or talks at conferences that don't get recorded.&lt;/p&gt;
&lt;p&gt;&lt;a href="https://barryhawkins.com/blog/posts/ibm-developerworks-podcast-barry-hawkins-on-agile-software-development/"&gt;Read more…&lt;/a&gt; (1 min remaining to read)&lt;/p&gt;&lt;/div&gt;</description><category>agile</category><category>culture</category><category>lean</category><category>process</category><category>scrum</category><guid>https://barryhawkins.com/blog/posts/ibm-developerworks-podcast-barry-hawkins-on-agile-software-development/</guid><pubDate>Fri, 20 Apr 2012 19:20:05 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></channel></rss>