Uploaded byProductCamp Boston
Building Lean Products with Distributed Agile Teams - Igor Moochnick at ProductCamp Boston, April 2011
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.
More Related Content
Similar to Building Lean Products with Distributed Agile Teams - Igor Moochnick at ProductCamp Boston, April 2011
Building Lean Products with Distributed Agile Teams - Igor Moochnick at ProductCamp Boston, April 2011
- 1. Building lean productswith distributed agile teamsWe believe that it is possible. Igor MoochnickPrincipalIgorShare Consultingigor@igorshare.comBlog: www.igorshare.com/blog
- 2. A/agile? L/lean?It’s notabout:MethodologyToolsGamesProtocolsRitualsManifestsEtc…It’s aboutdoing the “right” thing for your customers and your teamTransparency
- 3. Am I agile?Agilemeans the ability to respond quickly to any changeFollow new business opportunitiesReflect rapid market changes or challengesLightweightIt has nothing to do with the software development, but it really helps to rapidly exploit business potentialYou have to have Agile company to really succeedIf 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. AssumptionsLife is unpredictableDoesn’tmatter what you do the statement #1 still holds trueCustomers are unpredictable – deduction from #1Our goal is to make it safely to the delivery while reacting to the consequences from statement #1
- 5. CommunicationCommunicationCommunicationCommunication….Constant Feedback andcheck yourself at every stageThe communication is THE KEY and the HOLY GRAIL of SuccessCustomer should be aware of your progress at any point of timeCustomers (The Stakeholders) should have control on the project timelineCustomers are 50% of the equation and you’re the other 50%Develop a trusting and open relationship with your customer
- 6. FeedbackDecrease the distancebetween the customer and the developerDecrease the time between the implementation and feedbackFrom customerFrom QAConstant feedback is crucial for successFeedback is the only way to know that you’ve done the right thing
- 7. Value Propositionof Agile (or Lean)Return on InvestmentEarly and continuous feedbackCapitalize on learningFlexible delivery optionsSustainable development
- 8.
- 9. Daily CommunicationWhat wasdone?What is next?Any issues? Blocks? Bottlenecks?
- 10. Agile leadershipThe managersshould: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 – THEFEEDBACKConstant learningWhat worked?What didn’t work?What can be improvedConstant improvement – KaiZen改善
- 12. RequirementsPrioritized backlogAllows youto make decisions on what and when should be doneTrack progress (lifecycle of a requirement)Ownership
- 13.
- 14.
- 15. DesignNo large designupfrontNot everything is known ahead of the time and will be discoveredDesign continuouslyKISS/YAGNI/DRYDelay commitment and complexitySimplicity is hardAvoid “Architect Hubris”If we just build the framework upfront, coding will be easy…Harvest AbstractionMake any abstraction earn its existence
- 16. The Last ResponsibleMoment“…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 DesignSocialize thedesignKnow the whyCollectively challenge the design every dayTalk about the designKeep the team abreast of changing design strategiesThe “This is the way we do it” moment
- 18. Decide when toDecideMake decisions at the right timeUtilize continuous learningThink ahead, yes! Act ahead, no!Don’t act on speculative design Keep a queue of design ideas and possible refactoringsDon’t go past the Last Responsible MomentBe cognizant of outstanding design decisionsSome decisions have to be made earlier than others
- 19. Reversibility“If you caneasily 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 testMockupsfor customers
- 21. Work Vertically byFeatureDesign vertical slices of deliverable functionalityAll design work should be traceable to immediate business needIncludes architectural infrastructure“Pull” Design versus “Push” DesignMinimize rework by integrating earlyTest earlyUser feedback earlyDeployment feedback earlyShorten the time between doing and verifying
- 22. DevelopmentOrthogonal CodeSeparation ofConcernsCohesion CouplingThe Single Responsibility Principle“A class should have only one reason to change” Open Closed PrincipleDon’t Repeat Yourself Principle (DRY)Refactor RelentlesslyTestability
- 23. Distributed developmentSeparation ofconcernsHide responsibility Abstract external dependenciesDecoupling teamsSelf-sustained and self-sufficient teamsIf possible, only divide teams by featureExternally facing API’s are NOT reversibleTransparency on interfaces and contracts – demos and unit tests
- 24. Make your codeeasy 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 integrationContinuousdeploymentUnit testsCode coverageTest automation
- 26. TestingWhen do westart 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 allabout confidence
- 28.
- 29.
- 30. Thanks for ideasMartinFowlerUncle Bob MartinJeremy D MillerOthers …