is to remove every barrier between our team and the success of our project, and fluidly adapt our approach as conditions change. To master the art of agile development, it takes 2 things: Experience ...helps us see how agile methods work. Mindfulness ...helps us understand our experiences.
the right decisions, even when they're difficult, and to tell stakeholders the truth when they need to hear it. Communication To give the right people the right information when they can use it to its maximum advantage. Simplicity To discard the things we want but don't actually need.
the appropriate lessons at every possible opportunity. Respect To treat ourselves and others with dignity, and to acknowledge expertise and our mutual desire for success.
feedback • From the code, the team, customers and stakeholders - so you can understand what's working and what's not working • Ask the team for their thoughts, there's an element of truth in every complaint • Always ask why - why do we follow this practice? why is it working? why isn't it working? Look at the process in practice • Root-cause & retrospectives = improve team's understanding • Sitting and working together = observe and absorb information • Standups & informative workspace = info-rich environment • Energized work, slack, pair programming = spread useful info, improve work • TDD, exploratory testing, customer involvement, iteration demos,
process require tuning • Do experiments; make small isolated changes so you can understand the results • View changes as sources of feedback and learning • Iterate the process Changing your process requires holistic view • New Agile teams don't have the experience necessary to give them holistic understanding of the process • You need to have a holistic view of what you do and why in order to change the process Use Retrospective • To give the team a more explicit venue for considering changes
you understand the rules, establish an underlying set of ideals based on practical results • "We want to avoid integration hell" == "We will never check in code that doesn't build or pass its tests" • With the guidance of your principles, question existing conventions - modify, work around, or break rules that prevent you from achieving success Ron Jeffries, one of XP's earliest proponents: "They're not rules, OK? They're techniques. They're tools we apply. They're habits. They're practices -- things we practice... They are, however, darn good things to know how to do, and do well."