Agile approaches
Importance of agile approaches
Agile approaches are widely used in digital application design.
From the perspective of democratic dialogue, an important aspect of agile approaches is that, in principle, a permanent link is maintained with the users of the future software throughout the project. This would give them, at least in theory, the opportunity throughout the project to correct certain aspects of the application that could have a negative impact on well-being and citizenship at work.
However, these approaches have certain characteristics that can limit democratic dialogue and the consideration of requirements in terms of well-being and citizenship at work.
The examples given are taken from Scrum.
Standard presentation
APIDOR’s advice
Disclaimer: In this section, we only describe those aspects of Scrum1 that we consider essential for democratic dialogue. This presentation is therefore not intended to be exhaustive.
For more information on agile approaches, see the iterative and incremental models section on the IT project key points page.
Note: the challenges for senior management
Senior management is often very receptive to the promise of agile approaches in terms of the speed with which usable features can be produced. The challenge here is to save time, and therefore money.
The effects of ‘trends’ should not be overlooked either.
- Please note
Most of the advice already given for the sequential phases (Scoping to Maintenance phases) remains relevant. With a few exceptions, it will not be repeated here.
- Dogma to be challenged/New paradigm to be promoted
The ultimate goal often stated by agile approaches is to ‘maximise product value’ (i.e. the value of the software developed).
This goal is not being challenged, but ‘product value’ must be defined collectively, through democratic dialogue, in order to incorporate aspects of well-being at work.
Basic elements
Sprint
A sprint is an iteration (see iterative and incremental model). It generally lasts between one week and one month. During a sprint, the team develops a list of items from the product backlog, which is defined at the start of the sprint.
Backlogs
Product backlog
According to the definition in the Scrum Guide2: ‘The Product Backlog is an ordered, emerging list of what is needed to improve the product.’ ‘It is the single source of work undertaken by the Scrum Team.’
More specifically: ‘The Product Backlog lists all the features, functions, requirements, improvements and fixes that constitute changes to be made to the product in future versions’3.
It contains requirements expressed in the form of user stories (see below). It is hierarchical and tasks are prioritised.
A key point is that the backlog is constantly evolving throughout the project. Each sprint enriches it with feedback from end users, identified anomalies and new requirements that may have emerged. This inherently dynamic nature clearly differentiates it from a specification document.
Sprint backlog
This contains the list of tasks to be completed during a sprint in order to deliver the items in the product backlog that have been assigned to a sprint after being properly refined. ‘Refinement of the Product Backlog consists of breaking down and further defining the items in the Backlog into finer and more precise items. It is an ongoing activity aimed at adding details such as description, order and size. The attributes often vary depending on the field of activity’2.
The sprint backlog concerns the development team.
User story
A user story is a simple sentence in everyday language that defines the content of a feature to be developed with sufficient precision (see below).
- Point to note: writing user stories
If they did not write it themselves, the user(s) (who originated the user story) must be able to verify its wording before it is added to the product backlog.
- Point to note for democratic dialogue stakeholders
As the product backlog is constantly evolving, it is important to regularly check that requirements relating to well-being at work have not been unduly modified.
Furthermore, if new requirements on this topic emerge following user testing of elements of the application, care must be taken to ensure that they are included in the product backlog.
- Reminder: democratic dialogue log
This ‘democratic dialogue log’ (democratic dialogue backlog) should enable the monitoring of the consideration (but also the evolution) of needs arising from democratic dialogue, difficulties encountered, trade-offs made, etc.
It should be initialised at the start of the project.
Actors
The Product Owner (PO): represents the bulk of the project owner (the business side, requirements). Validates all decisions relating to the product and the content of the product backlog. Their role can sometimes also be that of project manager, with the latitude to make strategic decisions within the project.
The Scrum Manager (SM): the SM is responsible for the methodology used and supports the teams in using the components of Scrum (events, artefacts, etc.). This role can be roughly equivalent to that of the project manager, but can sometimes also be performed by the PO.
The development team: responsible for implementing the technical solution. Team members are responsible for the increment, the sprint backlog and therefore how the application will be implemented. They may also be responsible for estimating the workload and completion time for each item.
The PO, SM and development team constitute the Scrum Core team. This team works on the project alongside other stakeholders: the Sponsor (client), who initiates the project; the Financier (when distinct from the Sponsor), who provides financial support for the project; and the users for whom the software is intended. The latter play an essential role in validating and guiding decisions that will be made regarding the application’s features.
Process
General principle
The general principle is that sprints will follow one another throughout the project, with each sprint producing an increment to the application being developed.
However, it is important to distinguish between what precedes the first sprint (initialization phase) and the subsequent “cruise” sprints.
Initialization phase (pre-sprint, sprint 0, etc.)
Agile approaches can be used for the entire project, or only from the implementation (development) phase onwards.
In both cases, what is available at the start of Scrum implementation to develop a first version of the product backlog is quite different.
In the second case (agile approach only from the implementation phase onwards), the objectives of the application and the requirements (functional and non-functional) have been expressed and have undergone initial refinement. The first version of the product backlog will then be created on this basis.
In the first case (agile approach throughout the project lifecycle), the initial situation is comparable to the start of the Initiation phase in sequential methods. Work will therefore be required to produce and understand the purposes and objectives of the application, the main expected functionalities, the links between them, the associated risks, etc., in order to be able to build the first version of the product backlog.
- Dogma to combat: “speed = efficiency” (vs. generating social debt)
In communications about agile approaches, flexibility and reduced development time are widely touted as benefits.
However, reducing the duration of an IT project can hinder a proper understanding of how the work is actually carried out. This can be particularly true if user stories are written solely by the PO, without sufficiently in-depth interviews with future users of the application and without validation of the user stories on their part.
Furthermore, overly limited time will hinder (or even prevent) the consideration of non-technical non-functional requirements, particularly those relating to well-being and citizenship at work (which project teams generally have little or no experience in dealing with).
This reduction in the duration of the project can thus seriously hamper the effective prevention of health risks and well-being at work, thereby generating “social debt”.
- Dogma to be challenged: “speed = efficiency” (vs. generation of technical debt)
The quest for speed in project execution can also generate “technical debt”, which can lead to very significant future costs. This “technical debt” can also impact working conditions in the medium or long term by degrading the performance of the application.
User stories (requirements elicitation/expression)
Note: the concept of user stories originally comes from XP4 (not Scrum), but is widely used in many agile approaches.
A user story is a framework for expressing a user’s requirement in informal language that is simple and clear. It must be written in language that is understood by all project stakeholders.
User stories are the work units of the product backlog, expressed from the user’s point of view.
Although they represent the user’s point of view, they are not usually written by the users themselves, but by the Product Owner or the PO assistants/Business analysts (based on interviews with users, or sometimes solely on the PO’s own knowledge).
Classic template for a user story
A user story generally follows this template:
As [who, role], I want/I wish to [action] in order to [why: expected benefit, expected value]
Who: the user (in terms of the role they perform) or the type of user who has this need (we are looking at it from their point of view).
The concept of persona5, which comes from marketing, can be used.
Action: describes, usually quite briefly, the action that the user wants or needs to take, or the result they hope to achieve.
Why (expected benefit, value): the value or benefit that the user hopes to gain from their action. This is the reason why the user wants to perform the action or achieve the objective. It allows us to identify the value of the feature, justify its development, and help better assess the priority of the user story.
Epics, themes
A user story that is too complex (i.e., one that cannot be completed in a single sprint) is an epic and will be broken down into smaller user stories.
In the product backlog, epics can in turn be grouped into themes (groups of epics that share the same objective, etc.) or features (functionalities).
The case of non-functional requirements (NFR)
Agile approaches do not give much importance (if any) to the expression and processing of non-functional requirements (NFRs).
Since the product backlog is intended to contain everything that adds value to the software to be produced, it seems natural that it should deal with both functional and non-functional requirements. It should be noted that one of the advantages of including NFRs in the product backlog is that it provides a single source for all requirements.
However, it is sometimes difficult to ensure that a non-functional requirement can be achieved in a single sprint and is testable. In this case, a requirement that is too large (or cross-functional) must be broken down into smaller requirements. A good way to do this is to focus more on the criteria that will enable the smaller requirement to be validated than on its detailed description.
User story acceptance criteria
Each user story must be completed with acceptance criteria. Verifying these criteria confirms (or not) that the end-of-sprint delivery meets expectations. This validation can be performed by the PO, alone or in collaboration with the users concerned.
The acceptance criteria can be written by the PO, alone or in collaboration with the developers, but can also be written with other impacted or concerned parties.
- Proposals to be made: completed user story template
Those responsible for well-being and citizenship at work can propose a user story template completed with:
– the how: the task as it is actually performed
– the specific working condition issues posed by the task
– the risks to health, well-being, and citizenship at work, etc. associated with the task described, as identified by the user themselves.
- Point to note: work groups
In agile approaches, users (the “who” in user stories) are individuals. Work groups are not considered users in themselves.
Those responsible for expressing needs about well-being and citizenship at work must be able to put forward needs/requirements concerning work groups.
The same applies to needs that employees consider important for the organization as a whole (e.g., needs about organization’s missions that would be complementary to those set out by senior management).
- Points to note/Proposals to be made: personae
If the project team uses personae:
– need for overall vigilance: because personae can be performative
– beware of overly stereotypical personae, which would be mere clichés (carrying dominant representations that are sometimes unconscious)
– before starting interviews to write user stories, consult with the people concerned to propose personae that are representative of real work situations and the diversity of users’ real experiences.
- Point to note: proper consideration of NFRs relating to well-being and citizenship at work
Requirements relating to well-being at work can sometimes be, for the most part, non-functional requirements.
However, agile approaches sometimes encourage project teams not to take into account NFRs that are not strictly technical.
Those responsible for expressing needs about well-being and citizenship at work in the project must be very vigilant in ensuring that NFRs on these topics are taken into account.
- Democratic dialogue procedures: acceptance criteria definition
The acceptance criteria for user stories must be defined collectively through democratic dialogue.
- Proposals to be made: acceptance criteria
Those responsible for well-being and citizenship at work requirements can propose acceptance criteria that take these themes into account.
Notes & references
- ‘Scrum’ is not an acronym, it is an English rugby term. For the history of the metaphor, see https://en.wikipedia.org/wiki/Scrum_(project_management)#History
- Schwaber K. et Sutherland J. (2020) The Scrum Guide. https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf
- Schwaber K. et Sutherland J. (2016) The Scrum Guide. https://scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf
- https://en.wikipedia.org/wiki/Extreme_programming
- https://en.wikipedia.org/wiki/Persona#In_marketing_and_user_experience_design