Agile Methods and Process Improvement

When people say "process improvement", many people think of SEI CMM initiatives. It's a common misconception to think that CMM and process improvement are the antipathy of agile development processes. However we've found that process improvement is a key part of people adopting and using agile methods.

We've seen two main threads as we've worked with clients: 1) people new to agile methods (often new to any method) wanting to improve how they develop software by taking ideas and practices from agile processes, and 2) existing competent agile teams who use process improvement to further tune and and adapt how they work.

This session discusses some of the challenges facing agile processes and looks at ways to implement and improve processes in each of these contexts.

Transcript

1. Agile Methods and Process Improvement Martin Fowler and Dan North
2. © ThoughtWorks Ltd, 2004 2 Agenda • Introduction • Transitioning to an Agile process • Improving an existing Agile process
3. © 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
4. © 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”
5. © 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
6. © 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
7. © 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
8. © 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
9. © 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
10. © 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
11. © 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
12. © 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
13. © 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
14. © 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
15. © 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