Agile Learns fromOpen Source

Andy Singleton

Agile New EnglandNovember 3, 2011

Why Learn From Open Source?Some premises of traditional Agile don’t fit

everyoneMany teams are distributed, not co-located Many organizations use contractors,

outsourcers and temporary partnersNot all work can be done by small teams

Open Source projects are effective

With totally distributed teamsOn projects with thousands of contributors

Assembla: Inspired by Open SourceStarted Assembla to bring to commercial software development open source ideas related to:Distributed teamsNew development tools and workflowsScalabilityPractices evolved over 20 years

Team TopologiesAgile Open Source

Teams of 5-10.Teams clustered for large

releases.Some team members are

employees, some “outsourced.”

A single global team.One person up to thousands.

No distinction between employees and outsourced

members.

People work for one organization. People work for many organizations.

Co-located teams recommended. Always distributed.

Daily meetings, calls or chats.Never meet; communicate by

exchanging codes and comments about code.

Ideally “self managing” peers. Team members coordinate with each other, decide what to do.

Code flow is structured – Hierarchical -pyramid with

maintainers and contributors.People are not managed

Learning: Distributed Agile

1. 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

work

1. Travel2. Architect in Advance (ALAP controversy)3. Add project managers4. Conference Call5. Interview6. Estimate

Agile Projects

Project CharacteristicsAgile Open Source

Big projects have multiple small teams, with meetings to resolve

dependencies. Consensus is very desirable.

One benevolent “dictator” or a small number of “maintainers”

make key decisions. Don’t agree? Fork.

Release in iterations with fixed time.

Release when ready. Publish “latest 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 beginning. Assemble release at the END!

Team LeadershipAgile Open Source

Product owner reports on user requests and represents users.

Users submit requests and bug reports 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 encourages consistent

performance.

Feedback from the community encourages visible contributions.

Business managers hire and fire.Benevolent dictator or

maintainers control what code goes into the release.

Manage People Manage Code

Learning: Budget for variable scopeAgile 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 deliverablesBuild credibility with frequent releasesStart projects faster with less “fuzzy front end” timeRelease on scheduleGet the high-value deliverables you need now, not the

ones you planned for last year

Learning: Technical LeadsTechnical lead – Developer who leads the

development team, manages the immediate stack of tasks

Needs some simple management trainingRequired for distributed teams. They

communicate by committing code and designs.

Learning: Manage codeOpen source teams manage code, not peopleCode is easier to manage than peopleContribution processes: Patches, fork and

merge, code review systemsCode management is much more scalable.

Take contributions from thousands

Tools and LibrariesAgile Open Source

Specialized environments. Some developers may have access to

only part of the code, build processes and tools.

Shared environments. All developers have access to all code and tools and can do a

complete build.

Some tools licensed per seat.Tools never licensed per seat

(because 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 toolsDocument, maintain, and share developer

setupDocument, maintain, and share build

instructions and environments

ScalingAgile Open Source

Divide into small teams. One team made up of many individual code contributors.

Teams send representatives to “Scrum of Scrums” to plan releases and get status of

dependencies. (More teams more meetings.)

Fix it yourself. Team members who break dependencies make

fixes themselves.

Coordinate teams as peer groups.

Code passed up a hierarchy of maintainers, who accept or

reject.

Frequent integration or continuous integration of code.

Regular daily builds and alpha release cycles.

Issue:Planning in advance is hard, and

limits scalability

Issue: Major features can be hidden in personal repositories for a long time before they are

contributed and 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 BuildingAgile Open Source

Hiring and onboarding new team members is a serious job with

high risk.

New team members submit code to prove themselves.

Hire based on interviews – lots of work.

Dictator or maintainers accept or ignore code (and team members).

Learning: Use trials, not interviews

Release PlanningAgile Open Source

Priorities set by product owners. Priorities are set by team and user votes.

Team members do estimates, then teams do estimates. No estimates.

Measure progress against estimates.

Measure progress through user feedback on release candidates.

Group selects do-able tasks as a commitment for the iteration.

No commitments. Code and features are included when ready,

or when accepted.

All tasks should be finished in the iteration.

Features which are not ready can be moved to later iterations.

Release at a fixed time. Release when ready.

LearningsDo prioritizeDo release on a fixed time cycleDon’t invest in estimates. Difficult,

inaccurate, unusedUse code contribution processes to accept

code near release time

Putting it all together: RDDRelease Driven DevelopmentInspired by learning from open sourceMatches what people actually do

commerciallySolves some problems of Scrum. RDD is:

ScalableDistributes wellDoesn’t require estimatingAllows 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 requestBUILD: Contributors build. Kanban style

process that includes design and planning.CONVERGE: Tech leads remove unfinished

features, accept finished featuresSTABILIZE: Same or different team prepares

a release

Converge – Constant Contact

Stabilize – Google Chrome

RDD Versus ScrumLess planning and estimating at the

beginning of iterationsMore planning inside an iterationConverge, don’t burn downSmall teams are not required. You can

accept code from individuals or contributors of any size.

Tech lead is a real leader

RDD Versus Kanban, TDDThe build phase is a Kanban process that includes all

the steps for planning, design, build, test, and stageKanban 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 SourceFixed time cycles, not release when readyDaily and weekly schedules for team

communicationsFixed schedule for qualifying a release

candidate

Switches in the code allow turning features off during stabilization phase