Successful Open Source, with Little or No Agile

I’ll be participating in the panel “Successful Open Source, with little or no Agile” at Agile 2008 in Toronto, Canada, on August 7th, 2008.

Successful Open Source, with Little or No Agile

Agile adoption in the Open Source community ranges from some to none for most successful teams.

• Can these communities learn anything from each other?
• Are these two communities one in the same?
• Do Open Source projects and Agile projects succeed or fail for the same reasons?

The panelists, Dennis Byrne, Dirk Riehle, Christian Robottom Reis and Naresh Jain, will use their collective experience to answer these and many other questions. We’ll also have one empty chair for anyone from the audience to be a part of the panel temporarily.

Agile adoption in the Open Source community ranges from some to none for most successful teams. Can these communities learn anything from each other? Are these two communities one in the same? Do Open Source projects and Agile projects succeed or fail for the same reasons? The panelists will use their collective experience to answer these questions.

This session will compare and contrast Open Source projects with Agile projects along many key dimensions. These dimensions include team size, co-location, communication, feedback loops, risk management, testing, time to market, and leadership structure. Drivers for project success and failure will be discussed.

Many successful Open Source software projects take advantage of a subset of tools and practices found within Agile methodologies: continuous integration, tight feedback loops, lightweight processes, high visibility, collective code ownership and a tendency to “release soon, release often”.

There is also a handful of Agile tools and practices that are almost never used on Open Source projects. This includes pair programming and daily stand up meetings. Many successful Open Source projects have a top down leadership structure; some have been successful without test driven development or face to face communication.

The Panel consists of Dennis Byrne, Dirk Riehle, Christian Robottom Reis and Naresh Jain.

This panel will use the following as a conceptual starting point of what Agile is.

• Thinking Pair Programming, Energized Work, Informative Workspace, Root cause analysis, Retrospective
• Collaborating Trust, Sit together, Real Customer Involvement, Ubiquitous Language, Stand-up meeting, Coding Standards, Iteration Demo, Reporting
• Releasing Done Done, No Bugs, Version Control – Single Code Base, 10 min build, Continuous Integration, Collective Code Ownership, Documentation
• Planning Vision, Release Planning, Deployments, Planning Game (Prioritization), Risk Management, Iteration Planning, Slack, Stories, Estimating
• Developing Incremental Requirements, Customer tests, Test Driven Development, Refactoring, Simple Design, Incremental Design and Architecture, Spike Solutions, Performance optimization, Exploratory testing

The panel will use the following set of questions to gauge various open source teams.

• How do developers share knowledge? In Agile we use Pair Programming as an effective way to share knowledge between the team members.
• What tools and techniques are used to keep everyone in the project on the same page? How do team members share statues? On Agile Teams we use Informative Workspace and Standup meetings.
• Do they conduct regular Retrospectives?
• Do the team have a common Coding Standards? How are standards like code format, architectural styles/guidelines, etc communicated across the team? When someone violates these guidelines or standards, how and when do they get the feedback?
• How are new features demonstrated to the rest of the team and to potential customers?
• What kind of metrics and reports are used by the team to communicate progress and status of the team?
• When a feature is considered done or accepted? Is there any acceptance criteria layout before development starts?
• What version control system do you use? Do you maintain a Single Code Base or a distributed code base?
• Do you have an automated build system? And how long does it take?
• Do you practice Continuous Integration?
• How is Collective Code Ownership handled?
• What kind of Documents are written and maintained for development?
• Does everyone on the project have the same Vision for the project? If so, how do you manage that?
• Is there any kind of Release Plan or Milestones setup for the project? If yes, how do you go about putting it into place?
• What are the type of deployment environments are setup by your project? Do you have different staging environment for testing?
• Who prioritizes the features?
• How requirements are captures? In Agile we use Stories to capture them and then use the same for planning and tracking. How is it managed on your project?
• Do your requirements have any form of estimates on them? If yes, who estimates them and how?
• What types of tests do you write? Unit tests, Integration Tests, Acceptance tests, UI tests, etc?
• Do you follow the practice of Test Driven Development?
• As the project goes on, the code base must be getting complicated. Is there any technique used by the team to keep the code/design simple? In agile we use the practice of Refactoring and Simple Design to do the same.
• Who and how is the design and architecture of the project decided? Is it done upfront or do you believe in Incremental Design and Architecture
• Who and when is performance optimization done? What tools and techniques are used for the same?
• What kind of testing do you do on the project before you make a release or before the code is checked in?
• What is the structure of the team? Is it flat or hierarchal? Do you have lead developers to whom junior developers report?
• How is release management handled on the project? Who makes the releases? Is there any process around configuration management?