cfbolz at codespeak.net cfbolz at codespeak.net
Fri May 5 20:39:33 CEST 2006

Author: cfbolz
Date: Fri May  5 20:39:25 2006
New Revision: 26827

Modified:
Log:
restify and use some raw latex to make result look nicer.

==============================================================================
Binary files. No diff available.

==============================================================================
+++ pypy/extradoc/talk/agile2006/draftpaper_agile2006.txt	Fri May  5 20:39:25 2006
@@ -3,9 +3,12 @@
===================================================================================

.. sectnum
+
+.. role:: raw-latex(raw)
+   :format: latex
+
.. raw:: latex

-   \author{Beatrice During, Change Maker, bea at changemaker.nu}
\begin{abstract}

PyPy is an Open Source project, partly funded by the European Union, employing
@@ -370,10 +373,11 @@

Here is what one of the new core developers of PyPy says about sync-meetings:

-"Sync-meetings are useful because they enable developers to discuss and clarify issues
-among themselves and to provide a common focus when working distributedly. They
-are also a lightweight way to syncronize activities, resolve blockers and to get an
-overview about who is currently doing what work."
+    *"Sync-meetings are useful because they enable developers to discuss and
+    clarify issues among themselves and to provide a common focus when working
+    distributedly. They are also a lightweight way to syncronize activities,
+    resolve blockers and to get an overview about who is currently doing what
+    work."*

Influencing factors: agile practices in PyPy
============================================
@@ -506,15 +510,16 @@
management team the strategy implemented was to delegate as much as possible of
the responsibilities and decision-making to the core developers.

-The strategy was to keep "conceptual integrity" [1] of the vision and the
-idea in the hands of the core developers. As Brooks stresses, a uniform system
-design is better than uncoordinated and independent design ideas. The core developers
-had a clear and agreed vision - but would they be allowed to implement it within a
-fixed contract workstyle, with new partners involved that had not been involved in
-the process from the start? The core developers were organized into a technical
-board, responsible for planning and coordinating the development work between
-the partners, with the mandate to make decisions. A somewhat negative result
-was the added workload and responsibility on developers regarding EU related work.
+The strategy was to keep "conceptual integrity" :raw-latex:\cite{key-1} of
+the vision and the idea in the hands of the core developers. As Brooks
+stresses, a uniform system design is better than uncoordinated and independent
+design ideas. The core developers had a clear and agreed vision - but would
+they be allowed to implement it within a fixed contract workstyle, with new
+partners involved that had not been involved in the process from the start? The
+core developers were organized into a technical board, responsible for planning
+and coordinating the development work between the partners, with the mandate to
+responsibility on developers regarding EU related work.

This structure was the most difficult to design and implement due to the very
different nature of its purpose compared to the collaborative, self-organized
@@ -559,8 +564,8 @@
development method as well as filming talks and discussion. Our film material
is planned to be released before summer 2006.

-=======================================
+Troubles in Paradise: striking a balance
+========================================

Developer driven versus formal project structure
------------------------------------------------
@@ -653,95 +658,114 @@

We believe so. The one clear dominating factor to make all this succeed is, as
always, the people factor, the CRACK performers as Boehm and Turner calls them
-("Collaborative, Representative, Authorized, Committed, Knowledgeable"). [2]
+("Collaborative, Representative, Authorized, Committed, Knowledgeable")
+:raw-latex:\cite{key-2}.

The core developers of the PyPy project had the right mix of various skills in
order to succeed in setting up a hybrid environment - enabling them to work
full time on a project they strongly believed in.  The most crucial mix of
skills for making this possible was/are:

-- Social
-The ability to communicate open and transparent, to mentor and tutor dispersed
-as well as reinventing different collaborative workstyles of the sprint method,
-"manage" groups and community as well as consortium, and handle conflicts)
-
-The ability to step into formal leadership roles in technical board structures, manage
-sprints and sync-meetings as well as the more informal management of the community
-of developers. Managing the balance between encouraging participation but still holding
-true to their vision, their "conceptual integrity".
-
-- Ability to network
-To be open to other communities, inviting new partners in order to create a working
-consortium structure in the EU-project, curious and collaborative towards other Python
-implementations and other languages and research approaches, sharing knowledge and
-experiences and seeking bets practices of other projects.
-
-- Entrepreneurs
-To risk the community through pursuing the idea of EU-funding in order to fullfill the
-ambitious vision, managing to not only create a consortium with innovative
-structures of cooperation but also to create new companies.
-
-- Technical skills
-Programming language and implementation aspects,frameworks, mathematics, computer
-science - core skills for the project. Also the ability to design, setup and effectively manage
-supporting infrastructure for the development process.
-
-- Managing the balance between encouraging participation but still holding
-true to their vision, their "conceptual integrity"
-This while working agile with open and transparent communication through sprints,
-documentation, tutorials, mentoring, sync-meetings. Resulting in a lively and growing
-the F/OSS community around the project.
-
-So, could it be said that for an agile software development process, especially one that is
-distributed and community oriented, within a framework of EU-funding, that it is heavily
-people dependent? Or to stress it even further, sprint-driven development as a methodology
-does not exist and function without an agile group of people, Crack performers. The people
-are the methodology in some sense and if you wish to draw upon the experience of the PyPy
-team you need to look at the supporting practices around the people in order to find what can be
-duplicated and tested in another project environment. This conclusion matches what Alistair
-Cockburn writes in his paper "Characterizing People as Non-Linear, First-Order Components in
-Software Development" [3]:
-
-"The fundamental characteristics of "people" have a first-order
-effect on software development, not a lower-order effect."
-
-If we accept this conclusion then we can also, thanks to the people, start to get innovative
-regarding practices. Designing the project process based on the specific needs of the unique
-project environment you are facing. In the case of PyPy this means that we are exploring
-the methodology as we go along, adjusting and finetuning the process as well as the software.
-
-So, when drawing from these different skills within the community of developers, the people, in
-the PyPy project one possible conclusion would be that a truly agile approach
-dominating the work style of an Open Source project will increase the ability of
-the community to spread the strategy of agility to other domains.
-
-By this we mean that what started as agile practices in the development process
-quickly became influencing factors when designing other project processes. Examples of
-this in PyPy is how the sprint-driven development acts as a focal point not just for the
-development work (co-located as well as dispersed) but also for the formal and informal
-management of the project. Sprints together with the CRACK performers was what made
-the community grow and evolve. It was the foundation for a hybrid project where agile
-practices and EU-funding can fit within a distributed Open Source context.
+- **Social:** The ability to communicate open and transparent, to mentor and
+  tutor dispersed as well as reinventing different collaborative workstyles of
+  the sprint method, "manage" groups and community as well as consortium, and
+  handle conflicts)
+
+- **Leadership abilities:** The ability to step into formal leadership roles in
+  technical board structures, manage sprints and sync-meetings as well as the
+  more informal management of the community of developers. Managing the balance
+  between encouraging participation but still holding true to their vision,
+  their "conceptual integrity".
+
+- **Ability to network:** To be open to other communities, inviting new
+  partners in order to create a working consortium structure in the EU-project,
+  curious and collaborative towards other Python implementations and other
+  languages and research approaches, sharing knowledge and experiences and
+  seeking bets practices of other projects.
+
+- **Entrepreneurs:** To risk the community through pursuing the idea of
+  EU-funding in order to fullfill the ambitious vision, managing to not only
+  create a consortium with innovative structures of cooperation but also to
+  create new companies.
+
+- **Technical skills:** Programming language and implementation
+  aspects,frameworks, mathematics, computer science - core skills for the
+  project. Also the ability to design, setup and effectively manage supporting
+  infrastructure for the development process.
+
+- Managing the balance between encouraging participation but still holding true
+  to their vision, their "**conceptual integrity**" This while working agile with
+  open and transparent communication through sprints, documentation, tutorials,
+  mentoring, sync-meetings. Resulting in a lively and growing the F/OSS
+  community around the project.
+
+So, could it be said that for an agile software development process, especially
+one that is distributed and community oriented, within a framework of
+EU-funding, that it is heavily people dependent? Or to stress it even further,
+sprint-driven development as a methodology does not exist and function without
+an agile group of people, Crack performers. The people are the methodology in
+some sense and if you wish to draw upon the experience of the PyPy team you
+need to look at the supporting practices around the people in order to find
+what can be duplicated and tested in another project environment. This
+conclusion matches what Alistair Cockburn writes in his paper "Characterizing
+People as Non-Linear, First-Order Components in Software Development"
+:raw-latex:\cite{key-3}:
+
+    *"The fundamental characteristics of "people" have a first-order
+    effect on software development, not a lower-order effect."*
+
+If we accept this conclusion then we can also, thanks to the people, start to
+get innovative regarding practices. Designing the project process based on the
+specific needs of the unique project environment you are facing. In the case of
+PyPy this means that we are exploring the methodology as we go along, adjusting
+and finetuning the process as well as the software.
+
+So, when drawing from these different skills within the community of
+developers, the people, in the PyPy project one possible conclusion would be
+that a truly agile approach dominating the work style of an Open Source project
+will increase the ability of the community to spread the strategy of agility to
+other domains.
+
+By this we mean that what started as agile practices in the development process
+quickly became influencing factors when designing other project processes.
+Examples of this in PyPy is how the sprint-driven development acts as a focal
+point not just for the development work (co-located as well as dispersed) but
+also for the formal and informal management of the project. Sprints together
+with the CRACK performers was what made the community grow and evolve. It was
+the foundation for a hybrid project where agile practices and EU-funding can
+fit within a distributed Open Source context.
+
+Acknoledgements
+===============
+
+The author would like to thank the following people who have in various ways
+helped with the creation of this paper: Angela Martin, Emily Bache, Tres
+Seaver, Carl Friedrich Bolz.

+I would like to dedicate this paper to my dear friend and mentor of the Open
+Source Python and PyPy community Holger Krekel.

-References:
-==========
+..   References:
+..   ===========
+
+.. raw:: latex
+
+   \begin{thebibliography}{1}
+   \bibitem{key-1} Fredrick P. Brooks, Jr, "The mythical man-month, anniversary
+
+   \bibitem{key-2} Barry Boehm,Richard Turner, "Observations on Balancing
+   Discipline and Agility", (drawn from the book "Balancing Agility and
+   Discipline: A Guide to the Perplexed", Addison Wesley, 2003)
+
+   \bibitem{key-3} Alistair Cockburn, "Characterizing People as Non-Linear, First-Order
+   Components in Software Development", Presented at the 4th International
+   Multi-Conference on Systems, Cybernetics and Informatics, Orlando,
+   Florida, June, 2000, \texttt{http://alistair.cockburn.us/crystal/\\
+   articles/cpanfocisd/\\
+   characterizingpeopleasnonlinear.html}

-[1] Fredrick P. Brooks, Jr, "The mythical man-month, anniversary edition",
+   \end{thebibliography}

-[2] Barry Boehm,Richard Turner, "Observations on Balancing Discipline and Agility",
-(drawn from the book "Balancing Agility and Discipline: A Guide to the Perplexed",
-
-[3] Alistair Cockburn, "Characterizing People as Non-Linear, First-Order Components in
-Software Development", Presented at the 4th International Multi-Conference on Systems,
-Cybernetics and Informatics, Orlando, Florida, June, 2000,
-http://alistair.cockburn.us/crystal/articles/cpanfocisd/characterizingpeopleasnonlinear.html

-The author would like to thank the following people who have in various ways helped with the
-creation of this paper: Angela Martin, Emily Bache, Tres Seaver, Carl Friedrich Bolz.

-I would like to dedicate this paper to my dear friend and mentor of the Open Source Python and
-PyPy community Holger Krekel.
\ No newline at end of file