Clarify the "agile" section

[Bisaloo]

When it was initially drafted, the section endorsing an agile approach

blueprints/principles.qmd

Lines 45 to 55 in 07c074f

	## Lean and Agile collaboration framework
	The main objective of our collaboration framework will be to optimize interactions between users and developers. We thus naturally embrace the agile philosophy in which projects progress iteratively through short cycles focusing on delivering and reviewing MVPs. We foresee that each cycle should have three main phases:
	1. *Planning*: users and developers write a backlog of tasks to complete, identify top priorities, and define which MVPs will be worked on in the production phase
	2. *Production*: developers produce MVPs; if pair-programming is used, users could be involved at this stage too
	3. *Review*: presentation of MVPs and collection of feedback; the backlog is updated accordingly; this is also the opportunity for a retrospective assessment of the process: What was done well? What caused problems? How can the team improve the work process?
	To maximize agility, we recommend also adopting the lean principle in which the amount of work in progress (WIP) at any time is minimized. In other words, it is more efficient to work on a few MVPs and deliver value quickly, rather than working on many MVPs at the same time, resulting in a lot of WIP and low completion rates. We recommend using Kanban boards ([which can be created through the **Projects** tab on GitHub](https://docs.github.com/en/issues/planning-and-tracking-with-projects/creating-projects/creating-a-project)) to keep track of progress, and as a tool for identifying long-lasting WIP, likely indicative of blockage or issues which need addressing. These boards should be fully public to encourage and facilitate external visibility and contributions.
	 during the Epiverse-TRACE Summit 2023 in Bogotá, CC BY.](figures/agile.png){fig-alt="The Epiverse-TRACE agile strategy is graphically represented as a workflow composed of 7 steps connected by arrows. The steps are: 1. Pitch the idea; 2. Seek feedback; 3. Create the design document; 4. Seek feedback; 5. Create repository from packagetemplate; 6. Start initial development; 7. Seek feedback on MVP. The figure has a cartoonish style, with lilac and purples hues and was create by Melissa Avila during the Epiverse-TRACE Summit 2023 in Bogotá."}

was not intended as a requirement to adopt a specific, well-defined agile methodology, but as a general encouragement for rapid iteration, with regular feedback checkpoints.

And indeed, as reported in subsequent discussions, this would have not be possible to be implement in all teams, especially when some team members are only involved part-time in the project.

The intent here was to encourage regular feedback from users, which relatively short release cycles. As far as I can tell, this is indeed what all teams are currently doing, albeit under different formats, either with explicit user feedback sessions, or through rapid general availability releases. Is there a general agreement to list this as a principle?

In all cases, the lack of a shared understanding when reading this section is a clear signal it needs to be rephrased.

[joshwlambert]

In general I think it's a good principle for a way we can work, but as you say, it's more of an aim than enforced. Perhaps rephrasing:

We thus naturally embrace the agile philosophy

will remove the implication that our whole team is working in an agile way.

the lack of a shared understanding when reading this section is a clear signal it needs to be rephrased.

This lack of understanding may also stem from not being aware of the agile way of working. Linking to some documentation that more thoroughly explains agile could alleviate some of this issue. Also dedicating an upcoming development meeting to explaining agile and the benefits may help the team.

[Bisaloo]

In the cases I have encountered, I don't think this resulted from a lack of understanding of agile, maybe even the opposite.

The term "agile" tends to be used in a strong or in a weak sense depending on the context and audience:

• generally, in industry, if someone says "we're doing agile", there is an expectation that they are following a specific agile framework and associated practices (e.g., daily standups, sprints, etc.)
• generally, in the research software world, agile is used in a much weaker sense. There is a general expectation to have relatively short feedback cycles, but no strict framework.

In the blueprints, "agile" has been used in the latter, weaker, sense. We generally want to keep close contacts with users or potential users and try to iterate rapidly.
There was no expectation that we would necessarily start enrolling everyone on a specific framework.

But because of the diversity of backgrounds in Epiverse, and because the blueprints are a public document that can be read by a diverse range of people, I can easily see how people would potentially interpret it in different manners.

We should rephrase in a way that is not generating different understandings. Maybe removing the actual "agile" term is the best way since this term tends to be thrown around in a variety of contexts and its definition keeps loosening. Otherwise, we need to be very clear the meaning we give to this term here.