Agile Learns From Open SourcePresentation Transcript
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
Assembla: Inspired by Open SourceStarted Assembla to bring to commercialsoftware development open source ideasrelated to:Distributed teamsNew development tools and workflowsScalabilityPractices evolved over 20 years
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
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
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
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.
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
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
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.
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
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.
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
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.
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
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
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.
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
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
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
Converge – Constant Contact
Stabilize – Google Chrome
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
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
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