Two of ThoughtWorks’ finest, Martin Fowler and Jez Humble, talk about the notion of Continuous Delivery, which enables organizations to build software that is production ready at all times. To do this, enterprises automate the build, deployment, and testing process, and improve collaboration between developers, testers, and operations. The duo discusses a variety of related issues.
In this interview Jez Humble discusses the concept of continuous delivery, which implies that software should always be production ready throughout its lifecycle. That means that every build could be released into production and run effectively. Continuous delivery involves build and deployment automation, continuous integration, test automation, managing infrastructure and environments and more.
In this interview, Cyndi Mitchell talks about ThoughtWorks’ concept of “Continuous Delivery,” which focuses on the last mile of software delivery. Mitchell also discusses the “adaptive” in ThoughtWorks Studios’ Adaptive ALM (Application Lifecycle Management) strategy, in which Agile solutions must be adaptive to users’ needs. And Mitchell describes ThoughtWorks Studios tools: Mingle, Go and Twist.
Mary and Tom discuss the history of Lean, and what they feel are the most important things for software teams and organizations to thrive.Results are not the point, the point is growing your people, converting them into effective problem solvers who are relentlessly improving. If everybody in the organization is a problem solver, you'll get steadily better and better.
Mary Poppendieck talks about her last book "Leading Lean Software Development", a book for the product, program and all C-level managers, showing them how to apply agile principles and practices starting from the realization that development teams are not successful if they are not in the same boat with their managers.
Pollyanna Pixton talks about leadership, especially leading Agile teams, but more importantly what senior leaders do to help support their Agile teams in their organizations. She focuses on how leaders that are command and control can stay out of the way, step back and let teams and everyone below them make their own decisions and take ownership and deliver.
Brian and dave discuss what it might mean to be a true craftsman and why the idea of craft has become so popular of late. Other issues discussed include the question of why craft seems to be focused almost exclusively on programming and why everyone does not aspire to be a craftsman? Programming as performance art, programs as literary artifacts, and code "habitability" round out the discussion.
Robin Dymond gives an overview of Lean, how it can help take Agile to the 'next level' and why organizations that fail to change will not have successful Agile teams. Robin describes an organizational mismatch between traditional hierarchies and team structures. He believes that organizations will need to reorganize around teams to get the most out of Agile.
Pollyanna Pixton tells us that within a culture of trust leaders must stand back and if they don't then they are hampering and restricting the productivity and the creativity and the innovation of teams. She discusses how leaders can foster a culture of trust and what they must do to get the most out of Agile teams.
In this interview made by Deborah Hartmann during Agile 2008, Diana Larsen and Jim Shore talk about patterns observed in CTOs' activity. CTOs emerge as real people caring for other people in their organization, and are put under a lot of pressure and constraints.
In this interview made by Floyd Marinescu, co-founder of InfoQ, Linda Rising talks about the book "Fearless Change: Patterns for Introducing New Ideas" and offers examples of how the patterns presented in the book can ease the stress of Agile adoption.
Joseph Pelrine was present when XP took its first steps, was Europe's first Certified Scrum Trainer, and today is still breaking new ground. In this 2007 InfoQ interview, Joseph talked about Network Analysis and how Social Complexity Science informs his work with teams; the usefulness of the Dilbert archetype; & a speed-dating technique to help teams get started (creating software, of course).