To be effective with agile software development, you need to have solid technical practices. But many organizations are still only implementing process changes to their software delivery cycles. Rachel and Martin discuss why you need technical practices like testing, refactoring, continuous delivery and evolutionary architecture. They cover a brief history of these practices and explain how, without them, you end up with "ball of mud architectures" that slow you down no matter what process changes you make. Viewers will enjoy the contrast in perspectives between Rachel's up to date reality of working on projects with Martin's fading memories of past glories.
You Can't Be Agile When You're Knee-Deep in Mud
Rachel Laycock
Head of Technology, North America
Rachel is the Head of Technology for North America at Thoughtworks and is based in New York. She has over 12 years of experience in software delivery, having worked on a wide range of technologies and the integration of many disparate systems. At Thoughtworks, she has coached teams on Agile and Continuous Delivery technical practices. She contributes to and drives the regional technology strategy, and is a conduit between the technical teams on the ground and global technical leadership. She is also a member of the Technical Advisory Board to the CTO, which regularly produces the Thoughtworks Technology Radar. She is fascinated by problem solving and has discovered that people problems are often more difficult to solve than software ones.
Martin Fowler
Chief Scientist, Thoughtworks
Martin, renowned author, software consultant and speaker, brings two decades of experience helping corporations utilise object technology for mission-critical information systems. He was one of the authors of the Manifesto for Agile Software Development, and has written seven books on software development and collected awards for them. He's also a highly regarded speaker at international conferences, although these days he prefers to stay off the stage.
His main interest is to understand how to design software systems, so as to maximize the productivity of development teams. In doing this he has looked to understand the patterns of good software design, and also the processes that support software design. He finds he learns a lot from listening to the experiences of his fellow Thoughtworkers: digging for useful ideas and communicating them to the wider world.