The document discusses principles and practices for building lean products with distributed agile teams, including: 1. The focus should be on doing what's right for customers and the team, with transparency. 2. Communication is key - constant feedback at every stage from customers and within the team is vital for success. 3. Design and development should be done iteratively in small vertical slices to get working functionality into customers' hands quickly and incorporate early feedback. 4. Testing should start early and continuously to build confidence, with a focus on testability and automation.

1. Building lean products with distributed agile teams We believe that it is possible. Igor Moochnick Principal IgorShare Consulting igor@igorshare.com Blog: www.igorshare.com/blog

2. A/agile? L/lean? It’s not about: Methodology Tools Games Protocols Rituals Manifests Etc… It’s about doing the “right” thing for your customers and your team Transparency

3. Am I agile? Agile means the ability to respond quickly to any change Follow new business opportunities Reflect rapid market changes or challenges Lightweight It has nothing to do with the software development, but it really helps to rapidly exploit business potential You have to have Agile company to really succeed If your software team is agile and produces a ton of features but the sales and the marketing teams are not performing – it’ll not help you to grow your revenue as quickly as you’d like

4. Assumptions Life is unpredictable Doesn’t matter what you do the statement #1 still holds true Customers are unpredictable – deduction from #1 Our goal is to make it safely to the delivery while reacting to the consequences from statement #1

5. Communication Communication Communication Communication …. Constant Feedback and check yourself at every stage The communication is THE KEY and the HOLY GRAIL of Success Customer should be aware of your progress at any point of time Customers (The Stakeholders) should have control on the project timeline Customers are 50% of the equation and you’re the other 50% Develop a trusting and open relationship with your customer

6. Feedback Decrease the distance between the customer and the developer Decrease the time between the implementation and feedback From customer From QA Constant feedback is crucial for success Feedback is the only way to know that you’ve done the right thing

7. Value Proposition of Agile (or Lean) Return on Investment Early and continuous feedback Capitalize on learning Flexible delivery options Sustainable development

8. Stages (cyclical) Idea Requirements gathering Design Development Testing Release/Deployment Retrospective

9. Daily Communication What was done? What is next? Any issues? Blocks? Bottlenecks?

10. Agile leadership The managers should: Remove impediments Train Guide Advise Support Empower Recognize Foster Mitigate Resolve conflicts Encourage Catch errors The managers should never: Discourage Punish Micro-manage Downplay

11. Retrospective – THE FEEDBACK Constant learning What worked? What didn’t work? What can be improved Constant improvement – KaiZen改善

12. Requirements Prioritized backlog Allows you to make decisions on what and when should be done Track progress (lifecycle of a requirement) Ownership

13. Backlog management Order Assignments Estimates

14. Transparency - Feedback

15. Design No large design upfront Not everything is known ahead of the time and will be discovered Design continuously KISS/YAGNI/DRY Delay commitment and complexity Simplicity is hard Avoid “Architect Hubris” If we just build the framework upfront, coding will be easy… Harvest Abstraction Make any abstraction earn its existence

16. The Last Responsible Moment “…delay commitment until the last responsible moment, that is, the moment at which failing to make a decision eliminates an important alternative. “ – Mary Poppendieck

17. Distributed Design Socialize the design Know the why Collectively challenge the design every day Talk about the design Keep the team abreast of changing design strategies The “This is the way we do it” moment

18. Decide when to Decide Make decisions at the right time Utilize continuous learning Think ahead, yes! Act ahead, no! Don’t act on speculative design Keep a queue of design ideas and possible refactorings Don’t go past the Last Responsible Moment Be cognizant of outstanding design decisions Some decisions have to be made earlier than others

19. Reversibility “If you can easily change your decisions, this means it's less important to get them right - which makes your life much simpler. ” - Martin Fowler

20. Design feedback? SMELL test Mockups for customers

21. Work Vertically by Feature Design vertical slices of deliverable functionality All design work should be traceable to immediate business need Includes architectural infrastructure “Pull” Design versus “Push” Design Minimize rework by integrating early Test early User feedback early Deployment feedback early Shorten the time between doing and verifying

22. Development Orthogonal Code Separation of Concerns Cohesion Coupling The Single Responsibility Principle “A class should have only one reason to change” Open Closed Principle Don’t Repeat Yourself Principle (DRY) Refactor Relentlessly Testability

23. Distributed development Separation of concerns Hide responsibility Abstract external dependencies Decoupling teams Self-sustained and self-sufficient teams If possible, only divide teams by feature Externally facing API’s are NOT reversible Transparency on interfaces and contracts – demos and unit tests

24. Make your code easy to test “I don't care how good you think your design is. If I can't walk in and write a test for an arbitrary method of yours in five minutes, it’s not as good as you think it is, and whether you know it or not, you're paying a price for it.” Michael Feathers

25. Development feedback? Continuous integration Continuous deployment Unit tests Code coverage Test automation

26. Testing When do we start testing? Do we really need it? Do we test the right thing? What does the test testing? Do we know what code is tested? Coverage? If the test fails – what does this mean? Do we know what failed?

27. Tests are all about confidence

28. Delivery Instant deployment Constant deployment

29. Questions and Answers

30. Thanks for ideas Martin Fowler Uncle Bob Martin Jeremy D Miller Others …