InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

James Shore With More On Keeping It (Agile) Real

Posted by Mike Bria on Jun 02, 2009

Sections
Process & Practices
Topics
Agile ,
Agile in the Enterprise ,
Adopting Agile
Tags
Lean ,
Adoption ,
Kanban ,
Agile Manifesto

Registration is nearly full for next week's public courses from respected agile thought-leaders Jim Shore and Diana Larsen, and InfoQ got the opportunity to catch up with Jim as he prepares for them. In a casual interview, InfoQ got to talk with Jim about some of the topics he's been most vocal about lately, including his Art Of Agile book, recent waves of watered-down agile, and how Kanban might be less than the whole picture.

InfoQ first asked Jim about the Art of Agile book he and Shane Warden recently co-authored, particularly why the book matters and what readers can expect from it. Jim explained that many of the earlier comprehensive classics, such as those in the Extreme Programming series, target more of the "innovator and early adopter" audience (in Jeffrey Moore "crossing the chasm" terms), where as his book explicitly aims to be more pragmatic content for the many "early majority" types now looking for their introduction to agile. Jim went on to describe where the content comes from:

This book is really an amalgamation of my experiences with teams, which was based on me applying XP at first then bringing in pieces of Scrum because a lot of the teams I work with start with Scrum, and then also bringing in Lean concepts. All of this levied with a dash of Eli Goldratt's Theory Of Constraints model, which is very Lean-like. A final piece we brought in was Brian Marick's Agile Testing Directions.

More information about Jim's take on the book can be viewed in this interview filmed at Agile 2007 conference.

InfoQ talked then with Jim about his perception that agile adoptions are growing increasingly watered-down, as his well-known Stumbling Through Mediocrity and Decline and Fall Of Agile articles document. Summarizing his observation, he said this:

People are saying, 'we want to be agile', then finding the easiest, cheapest way to "be agile", and as a result are not making their lives any better. In many cases, in fact, they are making their lives worse.
...
What I see out there is that as agile has become a buzzword, and now agile itself has become the goal. But if agile is the goal, you can do all kinds of dysfunctional things, slap the word "agile" on what you're doing and declare success, but without actually ever making anybody's lives any better. The goal of agile isn't to "be agile", the goal is to produce great software that has value and that is fit for purpose in a way that is responsive, flexible, and humane.

When asked about what he thought the agile community can do to improve the situation, Jim offered this:

We need to stop saying agile is easy. We need to say agile is effective, its powerful, and that agile is going to deliver value - but its not necessarily easy. In fact, its hard. [Agile is an organizational change, and any] organizational change is hard.

As the conversation about the growing trend to take on agile methodology without really taking the whole methodology on continued, the topic of Kanban arose. Jim explained that he thinks Kanban is a great tool, but worries that focusing too much on Kanban in and of itself might be missing the bigger picture intended by Lean:

I think Kanban is a really interesting idea, and an excellent tool...but, the Lean Software Development ideas brought from the Toyota Production System over to the agile world [initially by Mary and Tom Poppendieck] have a lot more in there than just how you plan your work, which is largely what Kanban is about. Things like Continuous Flow, and a philosophy of improvement [a "Learning Culture"], and eliminating waste. Kanban though is only one of the tools used for creating a Continuous Flow environment, but it's not the whole picture. It would be similar to adopting XP and Scrum, but then only really talking about what goes on the planning board.

Many Kanban proponents will say to me, "no, Kanban is a whole philosophy" to which I ask, "why not talk about Lean as a whole then"? Because, we've already got a philosophy with Lean, and it fits in perfectly with agile.

If we're going to do Kanban, let's not just do Kanban, but let's take the whole Lean pie and embrace it because it fits in great with agile.

When asked more about what he finds great about Lean, Jim said this to close up our conversation:

When I first read the Poppendieck's book, I thought 'finally, here is something that explains why we're doing all this stuff we're doing in agile'. The Agile Manifesto of course has some principles associated with it, but in my opinion the Lean principles do better. Things like why we care about keeping our options open, and why we care about delivering frequently. Lean provides a lot of great explanation for that.

If you're interested in Jim's approach to and ideas about agile, be sure to consider checking out the Art of Agile Planning & Delivery public courses he and and Diana Larsen are offering June 8-12 .

  • This article is part of a featured topic series on Agile

No comments

Watch Thread Reply

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.