O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Building lean products with distributed agile teams


Confira estes a seguir

1 de 30 Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Semelhante a Building lean products with distributed agile teams (20)


Mais de Igor Moochnick (20)

Mais recentes (20)


Building lean products with distributed agile teams

  1. 1. Building lean products with distributed agile teams We believe that it is possible. Igor Moochnick Principal IgorShare Consulting [email_address] Blog: www.igorshare.com/blog
  2. 2. A/agile? L/lean? <ul><li>It’s not about: </li></ul><ul><ul><li>Methodology </li></ul></ul><ul><ul><li>Tools </li></ul></ul><ul><ul><li>Games </li></ul></ul><ul><ul><li>Protocols </li></ul></ul><ul><ul><li>Rituals </li></ul></ul><ul><ul><li>Manifests </li></ul></ul><ul><ul><li>Etc… </li></ul></ul><ul><li>It’s about </li></ul><ul><ul><li>doing the “right” thing for your customers and your team </li></ul></ul><ul><ul><li>Transparency </li></ul></ul>
  3. 3. Am I agile? <ul><li>Agile means the ability to respond quickly to any change </li></ul><ul><ul><li>Follow new business opportunities </li></ul></ul><ul><ul><li>Reflect rapid market changes or challenges </li></ul></ul><ul><li>Lightweight </li></ul><ul><li>It has nothing to do with the software development, but it really helps to rapidly exploit business potential </li></ul><ul><li>You have to have Agile company to really succeed </li></ul><ul><ul><li>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 </li></ul></ul>
  4. 4. Assumptions <ul><li>Life is unpredictable </li></ul><ul><li>Doesn’t matter what you do the statement #1 still holds true </li></ul><ul><li>Customers are unpredictable – deduction from #1 </li></ul><ul><li>Our goal is to make it safely to the delivery while reacting to the consequences from statement #1 </li></ul>
  5. 5. Communication <ul><li>Communication </li></ul><ul><li>Communication </li></ul><ul><li>Communication </li></ul><ul><li>… . </li></ul><ul><li>Constant Feedback and check yourself at every stage </li></ul><ul><li>The communication is THE KEY and the HOLY GRAIL of Success </li></ul><ul><ul><li>Customer should be aware of your progress at any point of time </li></ul></ul><ul><ul><li>Customers (The Stakeholders) should have control on the project timeline </li></ul></ul><ul><ul><li>Customers are 50% of the equation and you’re the other 50% </li></ul></ul><ul><ul><li>Develop a trusting and open relationship with your customer </li></ul></ul>
  6. 6. Feedback <ul><li>Decrease the distance between the customer and the developer </li></ul><ul><li>Decrease the time between the implementation and feedback </li></ul><ul><ul><li>From customer </li></ul></ul><ul><ul><li>From QA </li></ul></ul><ul><li>Constant feedback is crucial for success </li></ul><ul><ul><li>Feedback is the only way to know that you’ve done the right thing </li></ul></ul>
  7. 7. Value Proposition of Agile (or Lean) <ul><li>Return on Investment </li></ul><ul><li>Early and continuous feedback </li></ul><ul><li>Capitalize on learning </li></ul><ul><li>Flexible delivery options </li></ul><ul><li>Sustainable development </li></ul>
  8. 8. Stages (cyclical) <ul><li>Idea </li></ul><ul><li>Requirements gathering </li></ul><ul><li>Design </li></ul><ul><li>Development </li></ul><ul><li>Testing </li></ul><ul><li>Release/Deployment </li></ul><ul><li>Retrospective </li></ul>
  9. 9. Daily Communication <ul><li>What was done? </li></ul><ul><li>What is next? </li></ul><ul><li>Any issues? Blocks? Bottlenecks? </li></ul>
  10. 10. Agile leadership <ul><li>The managers should: </li></ul><ul><ul><li>Remove impediments </li></ul></ul><ul><ul><li>Train </li></ul></ul><ul><ul><li>Guide </li></ul></ul><ul><ul><li>Advise </li></ul></ul><ul><ul><li>Support </li></ul></ul><ul><ul><li>Empower </li></ul></ul><ul><ul><li>Recognize </li></ul></ul><ul><ul><li>Foster </li></ul></ul><ul><ul><li>Mitigate </li></ul></ul><ul><ul><li>Resolve conflicts </li></ul></ul><ul><ul><li>Encourage </li></ul></ul><ul><ul><li>Catch errors </li></ul></ul><ul><li>The managers should never: </li></ul><ul><ul><li>Discourage </li></ul></ul><ul><ul><li>Punish </li></ul></ul><ul><ul><li>Micro-manage </li></ul></ul><ul><ul><li>Downplay </li></ul></ul>
  11. 11. Retrospective – THE FEEDBACK <ul><li>Constant learning </li></ul><ul><ul><li>What worked? </li></ul></ul><ul><ul><li>What didn’t work? </li></ul></ul><ul><ul><li>What can be improved </li></ul></ul><ul><li>Constant improvement – KaiZen 改善 </li></ul>
  12. 12. Requirements <ul><li>Prioritized backlog </li></ul><ul><ul><li>Allows you to make decisions on what and when should be done </li></ul></ul><ul><li>Track progress (lifecycle of a requirement) </li></ul><ul><li>Ownership </li></ul>
  13. 13. Backlog management <ul><li>Order </li></ul><ul><li>Assignments </li></ul><ul><li>Estimates </li></ul>
  14. 14. Transparency - Feedback Not Started In Progress Testing Customer Review Done, Done, Done         Story #1         Story #2       Story #3       Story #4       Story #5           Story #6       Story #7         Story #8       Story #9         Story #10        
  15. 15. Design <ul><li>No large design upfront </li></ul><ul><ul><li>Not everything is known ahead of the time and will be discovered </li></ul></ul><ul><ul><li>Design continuously </li></ul></ul><ul><li>KISS/YAGNI/DRY </li></ul><ul><li>Delay commitment and complexity </li></ul><ul><li>Simplicity is hard </li></ul><ul><li>Avoid “Architect Hubris” </li></ul><ul><ul><li>If we just build the framework upfront, coding will be easy… </li></ul></ul><ul><li>Harvest Abstraction </li></ul><ul><ul><li>Make any abstraction earn its existence </li></ul></ul>
  16. 16. The Last Responsible Moment <ul><li>“… delay commitment until the last responsible moment, that is, the moment at which failing to make a decision eliminates an important alternative. “ </li></ul><ul><li>– Mary Poppendieck </li></ul>
  17. 17. Distributed Design <ul><li>Socialize the design </li></ul><ul><li>Know the why </li></ul><ul><li>Collectively challenge the design every day </li></ul><ul><li>Talk about the design </li></ul><ul><li>Keep the team abreast of changing design strategies </li></ul><ul><li>The “This is the way we do it” moment </li></ul>
  18. 18. Decide when to Decide <ul><li>Make decisions at the right time </li></ul><ul><li>Utilize continuous learning </li></ul><ul><li>Think ahead, yes! Act ahead, no! </li></ul><ul><ul><li>Don’t act on speculative design </li></ul></ul><ul><ul><li>Keep a queue of design ideas and possible refactorings </li></ul></ul><ul><li>Don’t go past the Last Responsible Moment </li></ul><ul><ul><li>Be cognizant of outstanding design decisions </li></ul></ul><ul><ul><li>Some decisions have to be made earlier than others </li></ul></ul>
  19. 19. Reversibility <ul><li>“ If you can easily change your decisions, this means it's less important to get them right - which makes your life much simpler. ” </li></ul><ul><ul><li>- Martin Fowler </li></ul></ul>
  20. 20. Design feedback? <ul><li>SMELL test </li></ul><ul><li>Mockups for customers </li></ul>
  21. 21. Work Vertically by Feature <ul><li>Design vertical slices of deliverable functionality </li></ul><ul><li>All design work should be traceable to immediate business need </li></ul><ul><ul><li>Includes architectural infrastructure </li></ul></ul><ul><ul><li>“ Pull” Design versus “Push” Design </li></ul></ul><ul><li>Minimize rework by integrating early </li></ul><ul><ul><li>Test early </li></ul></ul><ul><ul><li>User feedback early </li></ul></ul><ul><ul><li>Deployment feedback early </li></ul></ul><ul><ul><li>Shorten the time between doing and verifying </li></ul></ul>
  22. 22. Development <ul><li>Orthogonal Code </li></ul><ul><ul><li>Separation of Concerns </li></ul></ul><ul><ul><li>Cohesion </li></ul></ul><ul><ul><li>Coupling </li></ul></ul><ul><li>The Single Responsibility Principle </li></ul><ul><ul><li>“ A class should have only one reason to change” </li></ul></ul><ul><li>Open Closed Principle </li></ul><ul><li>Don’t Repeat Yourself Principle (DRY) </li></ul><ul><li>Refactor Relentlessly </li></ul><ul><li>Testability </li></ul>
  23. 23. Distributed development <ul><li>Separation of concerns </li></ul><ul><li>Hide responsibility </li></ul><ul><li>Abstract external dependencies </li></ul><ul><li>Decoupling teams </li></ul><ul><li>Self-sustained and self-sufficient teams </li></ul><ul><li>If possible, only divide teams by feature </li></ul><ul><ul><li>Externally facing API’s are NOT reversible </li></ul></ul><ul><li>Transparency on interfaces and contracts – demos and unit tests </li></ul>
  24. 24. Make your code easy to test <ul><li>“ 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.” </li></ul><ul><ul><li>Michael Feathers </li></ul></ul>
  25. 25. Development feedback? <ul><li>Continuous integration </li></ul><ul><li>Continuous deployment </li></ul><ul><li>Unit tests </li></ul><ul><li>Code coverage </li></ul><ul><li>Test automation </li></ul>
  26. 26. Testing <ul><li>When do we start testing? </li></ul><ul><li>Do we really need it? </li></ul><ul><li>Do we test the right thing? </li></ul><ul><li>What does the test testing? </li></ul><ul><li>Do we know what code is tested? Coverage? </li></ul><ul><li>If the test fails – what does this mean? </li></ul><ul><li>Do we know what failed? </li></ul>
  27. 27. Tests are all about confidence
  28. 28. Delivery <ul><li>Instant deployment </li></ul><ul><li>Constant deployment </li></ul>
  29. 29. Questions and Answers
  30. 30. Thanks for ideas <ul><li>Martin Fowler </li></ul><ul><li>Uncle Bob Martin </li></ul><ul><li>Jeremy D Miller </li></ul><ul><li>Others … </li></ul>