Agile Methods and Process Improvement Martin Fowler and Dan North

© ThoughtWorks Ltd, 2004 2 Agenda • Introduction • Transitioning to an Agile process • Improving an existing Agile process

© ThoughtWorks Ltd, 2004 3 The Agile manifesto is a set of comparative values Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan “That is, while there is value in the items on the right, we value the items on the left more.” www.AgileAlliance.org

© ThoughtWorks Ltd, 2004 4 Process is about repeatability • Repeating successes • Avoiding repeating mistakes • Avoiding repeating others’ mistakes “Fear leads to Risk, Risk leads to Process, Process leads to Hate”

© ThoughtWorks Ltd, 2004 5 Introduce process improvement in terms of benefits • To the team (Programmers, BAs, QAs) – Making life easier • To the Project/Program Manager (Assurance) – Managing risk • To Business stakeholders (Governance) – Business value proposition Adapt the message as appropriate

© ThoughtWorks Ltd, 2004 6 Principle 1: Actively solicit feedback • Release high-value software early and often • Early releases are only useful if someone is watching • Watching is only useful if someone is listening

© ThoughtWorks Ltd, 2004 7 Principle 2: Automate everything • Automate everything you can – Automate your revision control – Automate your build and deployment – Automate your system verification • Automation reduces risk – Automate boring, repetitive tasks • Automation reduces waste – Manual, labour-intensive processes

© ThoughtWorks Ltd, 2004 8 Principle 3: Plan collaboratively • Everyone should be involved in the planning • Everyone understands the domain and the scope • Everyone commits to the project • Visible consequences of decisions – Both business and technical

© ThoughtWorks Ltd, 2004 9 Principle 4: Adapt your process for now • A process should be optimized for the current team on the current project • Retrospectives are a formal way to change the process – Heartbeat retrospectives – Release retrospectives • Daily standups allow fine tuning • Pairing is an informal way to share best practices – Technical idioms, development activities, good habits – Not just pair programming

© ThoughtWorks Ltd, 2004 10 Process improvement is about getting the balance right • Understand how much is enough • Do enough, but no more • Understand why we are changing the process • Being prepared to try things

© ThoughtWorks Ltd, 2004 11 Pitfall 1: Pay attention to design – avoid design rot • Non-agile developers use The Process to mandate design • Agile developers use features and tests to evolve the design • During the transition, beware of having no design! – Especially people new to Agile and new to the project

© ThoughtWorks Ltd, 2004 12 Pitfall 2: Keep the build time short • A slow build is a productivity killer • Longer intervals between check-ins – More code means exponentially more complexity – Less likely to remember all the changes • Lots of dead time – Waiting for the green light – Backlog of check-ins • Kills motivation

© ThoughtWorks Ltd, 2004 13 Pitfall 3: Keep team sizes small • Face-to-face communication doesn’t scale – Delivery teams should be a dozen programmers or fewer • Have several small teams rather than one large one – Large delivery teams should be in subteams of half a dozen programmers or fewer • BUT: Ensure adequate communication between teams – Avoids duplicating local solutions – Daily stand-ups with tech leads

© ThoughtWorks Ltd, 2004 14 Pitfall 4: Do enough up-front thinking • Agile doesn’t mean “just start coding” • Planning, analysis and design are vital – So do all of them, all of the time

© ThoughtWorks Ltd, 2004 15 Summary • Use the values and principles to improve your process – Remember: People and Interactions over Processes and Tools • Understand why you are changing your process • Do not be afraid to try things – and to reject the ones that don’t work • Be careful to avoid the pitfalls – Learn from others' experience