Nimble Software Systems

Back in 2007, Jean and I developed an evolutionary model of Agile adoption for teams and organizations seeking the benefits of “scaling software agility.”  We presented talks on this at the Agile 2007 and Agile 2008 conferences.  We call it Flow-Pull-Innovate based on the Toyota Lean principles of Flow-Pull-Perfect.

Productivity gains in Agile development teams come conceptually from eliminating waste.  Just getting to the first step of Agile maturity can lead to 10 to 20% productivity increases.  We want you to be successful taking the first step, and there is a ton of opportunity in most software development shops. According to Tom and Mary Poppendieck, most software development organizations are only spending 6% of their time doing value-added tasks.  The other time is wasted in these categories:

• Partially done work (coding features that get removed from release)
• Extra processes (elaborating requirements that do not get built)
• Extra features (features that are rarely used - more on this in another post)
• Task switching (across multiple projects - losing flow)
• Waiting (requirements, designs, feedback, builds, other teams, larger organization, customer)
• Motion (walking over to interrupt folks for a build or status)
• Defect (internal or external)

Agile works to systematically address these wastes as you mature.  In our white paper on moving to Program Pull, Jean and I characterize the steps, roadblocks and benefits found at each step in the Flow-Pull-Innovate maturation process.

Yesterday evening, I was listening to “Marketplace” on National Public Radio and a segment on “Choosing the Best Business Books”. Kai Ryssdal, interviewing Jack Covert and Todd Sattersten, asked the two if there is one book they’d recommend to survive a downturn economy. The two have just authored The 100 Best Business Books of All Time so they seemed like the right people to ask.  Their answer surprised me in a particularly wonderful way. Spoiler: it wasn’t my book Collaboration Explained But before I tell you which book it was, let me tell you a little about what made me so happy and amazed.

I teach a class called “Collaboration Explained” through Rally’s Agile University. In this class about facilitating Agile software teams to be truly collaborative, I also touch into how to tell when I team really isn’t collaborative. It could be about the project’s or organization’s leadership; it could be a fundamentally toxic environment. Whatever the cause, I talk about recognizing certain dysfunctions, why we should care about them in Agile software development, and what to do about them.  This brings us back to the book recommended by Covert and Sattersten. Both my source on Agile team dysfunctions and the business book they recommended for this difficult economy are the same: The Five Dysfunctions of a Team: A Leadership Fable by Patrick M. Lencioni. What? A book about teams and their dysfunctions as THE business book for surviving a downturn economy? Yes.