Agile Learns From Open Source


Published on

Published in: Technology
1 Comment
1 Like
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Agile Learns From Open Source

  1. 1. Why Learn From Open Source? Some premises of traditional Agile don’t fit everyone  Many teams are distributed, not co-located  Many organizations use contractors, outsourcers and temporary partners  Not all work can be done by small teams Open Source projects are effective  With totally distributed teams  On projects with thousands of contributors
  2. 2. Assembla: Inspired by Open SourceStarted Assembla to bring to commercialsoftware development open source ideasrelated to:Distributed teamsNew development tools and workflowsScalabilityPractices evolved over 20 years
  3. 3. Team Topologies Agile Open Source Teams of 5-10. A single global team. Teams clustered for large releases. One person up to thousands.Some team members are employees, No distinction between employees and some “outsourced.” outsourced members. People work for one organization. People work for many organizations. Co-located teams recommended. Always distributed. Never meet; communicate by Daily meetings, calls or chats. exchanging codes and comments about code. Code flow is structured – Hierarchical -Ideally “self managing” peers. Team pyramid with maintainers andmembers coordinate with each other, contributors. decide what to do. People are not managed
  4. 4. Learning: Distributed Agile1. Share a daily or continuous build2. Release on a fixed schedule3. Write it down in tickets4. Daily report and chat at same time every day5. Watch a team activity stream6. Recruit good people
  5. 5. Learning: 6 Things to skipIncreased productivity comes from doing less work1. Travel2. Architect in Advance (ALAP controversy)3. Add project managers4. Conference Call5. Interview6. Estimate
  6. 6. Agile Projects
  7. 7. Project Characteristics Agile Open SourceBig projects have multiple small teams, One benevolent “dictator” or a smallwith meetings to resolve dependencies. number of “maintainers” make key Consensus is very desirable. decisions. Don’t agree? Fork. Release when ready. Publish “latest Release in iterations with fixed time. stable build” each day or week. Work from a backlog of requests. Work from a backlog of requests.Plan and estimate each iteration at the Assemble release at the END! beginning.
  8. 8. Team Leadership Agile Open SourceProduct owner reports on user requests Users submit requests and bug reports and represents users. directly.Product owner may control the budget. Budget is for developer time, not deliveries. Scrum master is a “coach.” No coach. How is that related to code? Peer pressure within the team Feedback from the community encourages consistent performance. encourages visible contributions. Benevolent dictator or maintainers Business managers hire and fire. control what code goes into the release. Manage People Manage Code
  9. 9. Learning: Budget for variable scope Agile project scope must be variable so that teams can work on emerging priorities, deliver on fixed schedule Biggest problem with agile: People paying those teams expect a fixed scope deliverable for a fixed amount of money Budget for developer time, not for deliverables  Build credibility with frequent releases  Start projects faster with less “fuzzy front end” time  Release on schedule  Get the high-value deliverables you need now, not the ones you planned for last year
  10. 10. Learning: Technical Leads Technical lead – Developer who leads the development team, manages the immediate stack of tasks Needs some simple management training Required for distributed teams. They communicate by committing code and designs.
  11. 11. Learning: Manage code Open source teams manage code, not people Code is easier to manage than people Contribution processes: Patches, fork and merge, code review systems Code management is much more scalable. Take contributions from thousands
  12. 12. Tools and Libraries Agile Open Source Specialized environments. Some Shared environments. All developersdevelopers may have access to only part have access to all code and tools and can of the code, build processes and tools. do a complete build. Tools never licensed per seat (because Some tools licensed per seat. the number of potential part-time contributors is infinite). May license commercial libraries. Almost never use commercial libraries.
  13. 13. Learning: Sharing is scaling All developers should have access to all code and tools Document, maintain, and share developer setup Document, maintain, and share build instructions and environments
  14. 14. Scaling Agile Open Source One team made up of many individual Divide into small teams. code contributors.Teams send representatives to “Scrum Fix it yourself. Team members who of Scrums” to plan releases and get break dependencies make fixes status of dependencies. themselves. (More teams  more meetings.) Code passed up a hierarchy of Coordinate teams as peer groups. maintainers, who accept or reject. Frequent integration or continuous Regular daily builds and alpha release integration of code. cycles. Issue: Major features can be hidden in Issue: personal repositories for a long timePlanning in advance is hard, and limits before they are contributed and scalability accepted.
  15. 15. Learnings: Sharing enables “fix it yourself” The Mythical Man Month is wrong. The problem is dependency, not communication. Code contribution and acceptance is more scalable than release planning
  16. 16. Team Building Agile Open Source Hiring and onboarding new team New team members submit code tomembers is a serious job with high risk. prove themselves. Dictator or maintainers accept or ignoreHire based on interviews – lots of work. code (and team members).Learning: Use trials, not interviews
  17. 17. Release Planning Agile Open Source Priorities set by product owners. Priorities are set by team and user votes. Team members do estimates, No estimates. then teams do estimates. Measure progress through user feedbackMeasure progress against estimates. on release candidates. Group selects do-able tasks as a No commitments. Code and features are commitment for the iteration. included when ready, or when accepted.All tasks should be finished in the Features which are not ready can be iteration. moved to later iterations. Release at a fixed time. Release when ready.
  18. 18. Learnings Do prioritize Do release on a fixed time cycle Don’t invest in estimates. Difficult, inaccurate, unused Use code contribution processes to accept code near release time
  19. 19. Putting it all together: RDDRelease Driven Development Inspired by learning from open source Matches what people actually do commercially Solves some problems of Scrum. RDD is:  Scalable  Distributes well  Doesn’t require estimating  Allows enough time for planning and design
  20. 20. Release Driven DevelopmentPlan the release at the end by qualifying and assembling the pieces that work REQUEST: Product owners request BUILD: Contributors build. Kanban style process that includes design and planning. CONVERGE: Tech leads remove unfinished features, accept finished features STABILIZE: Same or different team prepares a release
  21. 21. Converge – Constant Contact
  22. 22. Stabilize – Google Chrome
  23. 23. RDD Versus Scrum Less planning and estimating at the beginning of iterations More planning inside an iteration Converge, don’t burn down Small teams are not required. You can accept code from individuals or contributors of any size. Tech lead is a real leader
  24. 24. RDD Versus Kanban, TDD The build phase is a Kanban process that includes all the steps for planning, design, build, test, and stage Kanban aims for continual release, but this may not be practical without a stabilization phase Use Test Driven Development in the build phase to get more tests, reduce release testing and cycle time. This will shorten cycle time but maybe not increase release quality. It’s developer testing, not release testing RELEASE Driven Development needs to focus on actual release testing and quality
  25. 25. RDD Versus Open Source Fixed time cycles, not release when ready Daily and weekly schedules for team communications Fixed schedule for qualifying a release candidate Switches in the code allow turning features off during stabilization phase