Next Amr talk about a learning cycle of 1) goal, 2) process, 3) test, stop, and learn, apply lessons learned, and repeat until success. He then simplifies agile software development to recognizing and responding to change (learning, requirements, team structure, new practices), feedback practices and communication practices for the team (iterations stand up meetings, retrospective), and technical practices for developers (TDD, refactoring, pair programming).
Next Amr gives examples of some business values: reduce time to market, increase quality, increase flexibility, increase product utility, increase visibility, reduce cost, increase product lifetime. This is followed with some examples of some smells: Us vs. Them, Customer asks for everything, direct input from customer unrealistic, management is surprised, bottlenecked resources, churning projects, hundreds of bugs, hardening phase needed.
Each of these problems is addressed by different set of practices or patterns. A pattern is a problem solution pair within a context.
Amr then goes through some patterns:
1. Decrease time to market: We need to apply Iterations. For that we need a product backlog and a well defined definition of done. The backlogs improve product utility and increase visibility by enabling high quality feedback as the goals are met and reviewed regularly. They decrease time to market because the prioritized list enables negotiation of scope and early release with the most valuable functionality.
- a. Backlog context: You are on a team that decides to adopt agile including iterations. You decide to go away from big upfront design. Team has needed expertise to expand and evolve requirements
- b. Backlog adoption: Customer flushes out coarse grained requirements ahead of the iteration planning meeting. At the beginning of each iteration, team should have enough info to roughly estimate and begin development. Items chosen for development make up the iteration backlog.
- c. Backlog smells: Estimation paralysis, techies take over, multiple non cross functional teams have trouble working from one backlog
2. Increase quality: implement test driven development which needs refactoring which in turn needs collective code ownership and automated developer tests (Test first development or test last development). Refactoring increases flexibility and the product lifetime by enabling and encouraging developers to change the design of the system as needed. Quality to market and costs are reduced because continuous refactoring keeps the design from degrading over time, ensuring that the code is easy to understand, maintain, and change.
- a. Refactoring context: Development team is practicing automated developer tests. Requirement is not well supported by the current design or you want to make the design cleaner.
- b. Refactoring adoption: Just do it keeping in mind that it is a practice not a tool. Start automated developer tests until you are comfortable writing tests for all of the code. Adopt team code ownership. Agree on how to handle broken tests that result from refactoring. Read Martin Fowler book on refactoring and a book on TDD that is exercise driven.
- c. Refactoring smells: don’t get carried away and refactor just for the sake of refactoring. It does not deliver direct business value. Many missed small refactoring build up over time causing the need for a large refactoring. Beware of code ownership issues and pride that might lead to “commit wars”.