READING NOTE · UPDATED 2026
Read Kent Beck’s answers alongside engineering evidence
The interview below retains Kent Beck’s original answers. The conversation can inform how you think about software design and learning, but it is not a current endorsement of a particular tool or delivery process. Choose a concrete technical constraint and connect the discussion to a measurable feedback loop in your own development system.
A practical next step
- Identify a design or testing question in the interview.
- Inspect one real change and its feedback cycle.
- Try a bounded engineering change with existing quality checks intact.
This 2026 reading note is written by the Durnall editorial team. Richard Durnall’s original text follows below.
Historical references checked in 2026
The original words remain below. References without a verified useful destination are plain text rather than links to an error or unrelated website.
- Three Rivers Institute (TRI): The old domain now serves unrelated content.
- www.threeriversinstitute.org/LearningFromLean.html: The former article redirects to unrelated content; its text has not been recovered.
Original publication: .
Original WordPress feed timestamp, UTC; the old theme’s local date may differ. Check the date source ↗
The original words below retain their period and attribution. The reading note above is the current editorial addition.
Source capture · 2008-04-15 ↗About Kent :: Kent Beck is the creator of eXtreme Programming and author of Extreme Programming Explained: Embrace Change. Kent was also one of the original signatories of the Agile Manifesto in 2001 and is the founder and director of Three Rivers Institute (TRI).
Q. What influence, if any, did the Lean revolution taking place in the automotive industry have on the development of Agile XP during the C3 project?
None. It wasn’t until a few years later that I ran into Taiichi Ohno’s book “Toyota Production System”. Bob Charette was the first person I heard make the connection between lean production and software development, but again, this was several years after the C3 project.
Q. What do you feel the current view is within the IT community at large toward Agile and Lean software development?
I don’t think there is any one reaction. I hear healthy scepticism, which makes sense given the history of inflated claims in our industry. I hope that things really can be better. I hear curiosity and a willingness to try new things. I hear resistance to change.
Q. What are your thoughts on ‘Lean Thinking’ principles and their application to software development processes?
There are at least two levels of lessons for software development in lean production. One is the techniques themselves, something I explore in www.threeriversinstitute.org/LearningFromLean.html. Many of the techniques of both lean manufacturing and lean product development suggest techniques in software development. The second level of lessons comes from watching the triumphs and trials of manufacturing companies adopting lean production. I lurk on the NWLean mailing list and watch how companies try, sometimes succeed, and sometimes fail applying lean thinking and techniques.
Q. I believe the next stage of evolution for the Agile and Lean software development communities is working with our business partners to apply the same thinking that we have learned to apply to the software delivery process to the business processes and models that our systems support. Am I suffering from serious delusions or is the opportunity really there?
I think closer partnerships between suppliers and customers will happen eventually. Ohno tells the story of first getting operations inside Toyota in order before asking suppliers to change. I think most teams are still at the stage of getting their own house in order: working transparently, carrying very little inventory, working at high levels of quality, creating a flow of value. Once a team experiences flow, then they can improve further by helping their suppliers and customers achieve more flow as well.
Q. Where next for Agile and Lean software development processes?
I think they will be recast in business terms: accountability, transparency, and responsibility. Some rebranding and/or consolidation may go along with this shift in perspective. They will expand in scope to encompass more activities in the whole value chain that delivers value from software. On the minus side, I think we’ll see more people try to sell the benefits of agile development without making any fundamental changes. The difference between real agility and lip service is quite clear, though.
Q. Agile or Lean? Which is the best as a model for building great software? : )
I’m glad you know that’s a ridiculous question when put in black and white. I think both perspectives can be helpful. It depends on the circumstances and the background of the people involved. The great thing about lean software development is you can’t just copy it. Because it is focused on principles, you need to figure out for yourself how you are going to apply them. Extreme Programming, on the other hand, provides concrete advice with the primary and corollary practices while maintaining perspective by talking about values and principles.