<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Ed Willis on O&apos;Reilly Broadcast</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/" />
<link rel="self" type="application/atom+xml" href="http://broadcast.oreilly.com/atom.xml" />
<id>tag:broadcast.oreilly.com,2008-08-07://53</id>
<updated>2009-12-09T22:46:08Z</updated>

<generator uri="http://www.sixapart.com/movabletype/">Movable Type Pro 4.21-en</generator>

<entry>
<title>Requirements Development Techniques and Agile Projects</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2009/12/requirements-development-techn.html" />
<id>tag:broadcast.oreilly.com,2009://53.38687</id>

<published>2009-12-09T22:46:08Z</published>
<updated>2009-12-09T22:46:08Z</updated>

<summary>This article is about developing requirements for agile projects.  I&apos;ve used a number of different techniques and have recently happened upon one that&apos;s been the best of the bunch for me - hopefully it will prove useful to you as well.  Along the way, I&apos;ll sketch out a couple of other techniques for comparison. </summary>
<author>
<name>Ed Willis</name>

</author>

<category term="agilerequirements" label="agile requirements" scheme="http://www.sixapart.com/ns/types#tag" />

<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
This article is about developing requirements for agile projects.  I&apos;ve used a number of different techniques and have recently happened upon one that&apos;s been the best of the bunch for me - hopefully it will prove useful to you as well.  Along the way, I&apos;ll sketch out a couple of other techniques for comparison. 
</content>
</entry>

<entry>
<title>The CMMI in 2500 words or less</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2009/11/the-cmmi-in-2500-words-or-less.html" />
<id>tag:broadcast.oreilly.com,2009://53.38459</id>

<published>2009-11-09T20:22:10Z</published>
<updated>2009-11-09T20:22:10Z</updated>

<summary>This article provides a brief introduction to the Capability Maturity Model Integration (CMMI) that aims to cover most of the ground, if at a fairly shallow depth.  The CMMI is a process-based model that sketches out a comprehensive picture of development.  It builds on that to define a method for developing organization standard processes and for keeping them relevant.  Those processes are leveraged to ultimately deploy statistical process control to improve organizational performance.  The model is supported by a standard method for assessing an organization, SCAMPI appraisals.  My hope is that after reading this article, the reader will be able to make an informed decision on whether or not digging into the CMMI further is warranted.    Note that the notion of the &quot;organization&quot; in the CMMI allows for smaller groups within a company to be the focus of CMMI-based process improvement - so you don&apos;t have to wait for your whole company to get on board to get started.</summary>
<author>
<name>Ed Willis</name>

</author>

<category term="softwaredevelopment" label="software development" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="softwareengineering" label="software engineering" scheme="http://www.sixapart.com/ns/types#tag" />

<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
This article provides a brief introduction to the Capability Maturity Model Integration (CMMI) that aims to cover most of the ground, if at a fairly shallow depth.  The CMMI is a process-based model that sketches out a comprehensive picture of development.  It builds on that to define a method for developing organization standard processes and for keeping them relevant.  Those processes are leveraged to ultimately deploy statistical process control to improve organizational performance.  The model is supported by a standard method for assessing an organization, SCAMPI appraisals.  My hope is that after reading this article, the reader will be able to make an informed decision on whether or not digging into the CMMI further is warranted.    Note that the notion of the &quot;organization&quot; in the CMMI allows for smaller groups within a company to be the focus of CMMI-based process improvement - so you don&apos;t have to wait for your whole company to get on board to get started.
</content>
</entry>

<entry>
<title>Hiring Developers - Why &quot;Smart and Gets Things Done&quot; is not Enough</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2009/09/hiring-developers---why-smart.html" />
<id>tag:broadcast.oreilly.com,2009://53.37877</id>

<published>2009-09-04T01:29:32Z</published>
<updated>2009-09-04T01:29:32Z</updated>

<summary>Back in 2000, Joel Spolsky published the first version of his &quot;Guerrilla Guide to Interviewing&quot; about hiring developers.  Since then, he&apos;s published revisions to that article as well as including it in a book on hiring developers.  I don&apos;t know when I first read it but it certainly stayed with me.  Given how frequently people around me reference these sources - especially the guidance about the people to target (&quot;smart and gets things done&quot;) - it seems to have resonated with many others out there also.  That said, over the last few years I&apos;ve managed a group that&apos;s done a fair bit of hiring and, while I love the confidence of that article, it&apos;s not enough for us.  </summary>
<author>
<name>Ed Willis</name>

</author>

<category term="development" label="development" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="hiring" label="hiring" scheme="http://www.sixapart.com/ns/types#tag" />

<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
Back in 2000, Joel Spolsky published the first version of his &quot;Guerrilla Guide to Interviewing&quot; about hiring developers.  Since then, he&apos;s published revisions to that article as well as including it in a book on hiring developers.  I don&apos;t know when I first read it but it certainly stayed with me.  Given how frequently people around me reference these sources - especially the guidance about the people to target (&quot;smart and gets things done&quot;) - it seems to have resonated with many others out there also.  That said, over the last few years I&apos;ve managed a group that&apos;s done a fair bit of hiring and, while I love the confidence of that article, it&apos;s not enough for us.  
</content>
</entry>

<entry>
<title>Review:  &quot;Scaling Lean &amp; Agile Development&quot;, by Craig Larman and Bas Vodde</title>
<link rel="alternate" type="text/html" href="http://broadcast.oreilly.com/2009/08/review-scaling-lean-agile-deve.html" />
<id>tag:broadcast.oreilly.com,2009://53.37737</id>

<published>2009-08-14T19:48:04Z</published>
<updated>2009-08-14T19:48:04Z</updated>

<summary>I&apos;ve managed a group that ran software projects using Scrum but also provided Scrum support to the wider R&amp;D organization by developing Scrum templates and procedures, developing and delivering Scrum training and providing coaching and mentoring for groups taking their first steps down the Scrum path.  So, to be honest, I pretty much figured I had Scrum licked.  Then I read &quot;Scaling Agile &amp; Lean Development&quot; by Craig Larman and Bas Vodde.   I&apos;d yet to scratch the surface of lean and so the excellent treatment lean gets in this book was expected to be new to me, but it was pretty embarrassing how much I learned about Scrum and agile development along the way.  If anything it left me feeling a bit of an agile fraud.</summary>
<author>
<name>Ed Willis</name>

</author>

<category term="agile" label="agile" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="extremeprogramming" label="extreme programming" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="lean" label="lean" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="review" label="review" scheme="http://www.sixapart.com/ns/types#tag" />
<category term="scrum" label="scrum" scheme="http://www.sixapart.com/ns/types#tag" />

<content type="html" xml:lang="en" xml:base="http://broadcast.oreilly.com/">
I&apos;ve managed a group that ran software projects using Scrum but also provided Scrum support to the wider R&amp;D organization by developing Scrum templates and procedures, developing and delivering Scrum training and providing coaching and mentoring for groups taking their first steps down the Scrum path.  So, to be honest, I pretty much figured I had Scrum licked.  Then I read &quot;Scaling Agile &amp; Lean Development&quot; by Craig Larman and Bas Vodde.   I&apos;d yet to scratch the surface of lean and so the excellent treatment lean gets in this book was expected to be new to me, but it was pretty embarrassing how much I learned about Scrum and agile development along the way.  If anything it left me feeling a bit of an agile fraud.
</content>
</entry>

</feed> 
