Speaker: Pascal Fares Agile Tour Beirut 2014

1. OpenAgile: Is Free And Open
Source communities Agile?
Produce something useful for
someone

2. Open Source is subversive?
world-class products by:
● part-time hacking
● several thousand developers
● scattered all over the planet, connected
only by Internet?

4. Agile subversive too?
● Individuals and interactions*
(communications) over processes and tools
● Working products over comprehensive
documentation
● Customer collaboration over contract
negotiation
● Responding to change over following a plan

5. Our highest priority is
to satisfy the customer
through early and
continuous delivery of
valuable products.
Open source does not
talk about the customer,
but in general, x

6. ● Welcome changing
requirements, even
late in development.
Agile processes
harness change for
the customer's
competitive
advantage.
● Open-source projects
resist major changes
as time goes on, but
there is always the
possibility of forking
a project if such
changes strike
enough developers as
worthwhile.

7. Deliver working
software frequently,
from a couple of weeks
to a couple of months,
with a preference to the
shorter time scale.
Open source delivers
working code every
night, usually, and an
open-source motto is
"release early, release
often

8. Business people and
developers must work
together daily
throughout the project.
Open-source projects
don't have a concept of a
business person with
whom they work, but
users who participate in
the project serve the
same role.

9. "Build projects around
motivated individuals.
Give them the
environment and
support they need, and
trust them to get the job
done."
All open-source projects
do this, almost by
definition.

10. The most efficient and
effective method of
conveying information
to and within a
development team is
face-to-face
conversation.
Open source differs
most from agile
methodologies here.

11. Working software is the
primary measure of
progress.
This is in perfect
agreement with open
source.

12. Agile processes promote
sustainable
development. The
sponsors, developers,
and users should be able
to maintain a constant
pace indefinitely.
Although this uses
vocabulary that open-source
developers would
not use, the spirit of the
principle is embraced by
open source.

13. Continuous attention
to technical excellence
and good design
enhances agility.
Open source is
predicated on
technical excellence
and good design.

14. Simplicity--the art of
maximizing the
amount of work not
done--is essential.
Open-source developers
would agree that
simplicity is essential,
but open-source
projects also don't have
to worry quite as much
about scarcity as agile
projects do.

15. The best architectures,
requirements, and
designs emerge from
self-organizing teams.
Possibly open-source
developers would not
state things this way,
but the nature of open-source
projects depends
on this being true.

16. At regular intervals, the
team reflects on how to
become more effective,
and then tunes and
adjusts its behavior
accordingly.
This is probably not
done much in open-source
projects,
although as open-source
projects mature, they
tend to develop a richer
set of governance
mechanisms.

17. GNU, Linus values...
release early and often,
delegate everything you can,
be open to the point of
promiscuity

18. Treating your users as co-developers
Release early. Release often.
listen to your customers
Having good ideas is
recognizing good ideas from
your users.

19. Perfection (in design) is
achieved
not when there is nothing more
to add, but rather when there is
nothing more to take away.

20. To solve an interesting problem,
start by finding a problem that
is interesting to you

21. Managing Open Source
Be agile to minimise lost effort
Adapt Scrum and Kanban rules to a
distributed large scale team of co-developer
(co-client)
Orchestrated by a team moderator /
integrator / leader [By doocracy]

22. Do Ocracy
is an organizational structure
. individuals choose roles and tasks for
themselves and execute them.
. Responsibilities attach to people who do
the work, rather than elected or selected
officials.

23. Work-in-progress limits
Open Source likely driven by issues.
Issue is a story?
Issue must be solved

24. Planning meetings
Issue tracker => Milestones (sprint like)
iced issue (not planified)
Tag the issues (todo in a milestone no tag,
Assigned (working), done, finished
(accepted))

25. Review meetings.
Comments on issues

26. Standup meetings
On regular basis publish in public forum
a) what he/she do in previous quantum,
b) what he/she is working on actual
quantum, and
c) what is blocking any of that work
(assigned issues).

27. Retrospective reviews
Open Source essence
When something must be done will find
someone to do it! not done? it probably not
important!

28. Metrics.