Justin T. Sampson works as an independent software developer and coach, and has been an active member of the lean and agile software community in the San Francisco Bay Area for several years. He is a Certified ScrumMaster and leads the Prevayler open-source Java project. Justin is also a member of the National Coalition for Dialogue & Deliberation and the Applied Improvisation Network.
I have worked for half a dozen Silicon Valley software startups, as everything from a Java and C++ developer to an architect, a ScrumMaster, and a director of engineering. Through these experiences I have been involved in the whole range of Web application programming, from the database to the human interface and system integration, and I have seen a fair variety of team effectiveness and team dysfunction.
I first became excited by the Extreme Programming community as a learning community, a community of practitioners talking candidly about their experiences and ways in which they were learning to work more effectively. The real impact set in as I learned that the hardest challenges in software development are human challenges, not technical ones. Programmers, including myself, tend to be introverted, and Extreme Programming is a way for us to embrace communication and orient the continuous flow of our work so as to include the customer within a "whole team" awareness.
Starting with Extreme Programming, this community has guided me through the larger field of Agile Software Development, including Scrum, and on upwards to the cross-industry awareness of Lean Thinking. The foundation of Lean, as described by Taiichi Ohno in his book, Toyota Production System, consists of the complete elimination of waste coupled with the complete respect for humanity. Each will bend and crumble without the other, like an unreinforced foundation in a building.
My own conception of Lean Thinking as it applies to software development further recognizes the interconnection between lean process and lean product. Lean is about eliminating waste, so a lean product doesn't contain anything that's not of actual value to the user, and is designed in such a way as to not cause waste in deployment and maintenance. Duplication of code would be an example of something that causes waste in maintenance. Repetitive, error-prone manual installation steps would be examples of waste in deployment. My approach to both process and product is rooted in a holistic, object-oriented view of the entire system, using a minimum of languages and technologies to deliver the greatest value at the earliest responsible time.
Also see Justin's personal resume.