Example Of Agile Project Organization

This article is not intended to be a reference but an inspiration. Especially since an Agile project organization generally starts from a methodological framework such as Scrum and matures empirically from iteration to iteration. Each one thus ends up with a tailor-made methodology adapted to their context. At no time is the latter considered final.

Agile Project Organization

Roles

Product Owner

The Product Owner is the customer’s representative. He:

1. Defines product features.
2. Decides on delivery dates and content.
3. Responsible for product profitability (ROI).
4. Prioritize features based on business value.
5. Adjust features and their priority before each iteration of planning.
6. Accepts or rejects the functionalities carried out.
7. Facilitates the sprint planning meeting.

The role of the Product Owner is provided by a member of the business team (MOA) and, if necessary, assistance (AMOA).

Product Owner Support Team

It assists the Product Owner and, as such, may intervene in the context of activities associated with the latter’s responsibilities. More specifically, she:

1. Feeds and maintains the Product Backlog and pre-prioritizes the elements of the latter.
2. Adjusts the priority functionalities of the Product Backlog (candidates for the scope of the next Sprint) and ensures that the prerequisites for the associated developments will be available in due time (examples: business decisions, upstream IS data sets, etc.).
3. Writes User Stories associated with priority features and draws screen mock-ups as needed.
4. Responds to questions the ongoing Sprint development team raises and completes related User Stories as needed.
5. Verifies during Sprint the excellent coverage of the need for the finished functionalities in collaboration with the development team.
6. Write test plans.
7. She participates in the sprint review meeting and helps the Product Owner accept or reject the presented features.
8. Tests the conformity of the product as a whole before production.

Scrum Master

The Scrum Master belongs to the development team (MOE), he:

1. Ensures the unit is fully operational and productive.
2. Establishes close collaboration between all roles and functions.
3. Removes obstacles encountered by the development team.
4. Protects the team from outside interference.
5. Monitor the process.

Development Team

The development team:

1. Realizes product functionality.
2. Presents to the Product Owner the results of his work through demonstrations.
3. Maintains detailed product specifications.
4. Package and deliver the product.

Process

Overall Process

Summary

The iterative and incremental project process structures product development into ” Sprints ” work cycles. The duration of these sprints is fixed at two weeks within the framework of this project. The generic objective associated with each Sprint transforms the requirements constituting the latter’s scope into usable functionalities.

Just before starting a sprint, the development team selects items from the ordered list of requirements (Product Backlog) that they believe can be completed within the time frame associated with the Sprint. The Product Owner and the development team work closely during the latter to achieve the set objectives. Every day, the development team coordinates and measures its progress. 

At the end of the Sprint, she presents the results of her work to the Product Owner and the end users as a demonstration of the new functionalities. Feedback is collected. Immediately after the Sprint, the development team meets to learn from the past Sprint and consider ways to improve. Then follows the planning of the next Sprint.

Detailed Process

The following paragraph describes the steps in the process in chronological order.

Preparation

Before starting a Sprint, the Product Owner must ensure that the Product Backlog (List of expected requirements) is properly sequenced according to each requirement’s business value and cost. He can ask the development team to carry out estimation sessions for requirements without cost. 

He participates in these sessions – assisted by his team – by answering questions from the development team. He must also ensure that the need associated with the priority requirements of the Product Backlog (candidates for the scope of the next Sprint) is sufficiently mature (structuring business decisions taken, need to be formalized in the form of User Stories, etc.).

Sprint Planning

The Product Owner and the development team meet to share or re-share the project’s vision and the objectives associated with the elements of the Product Backlog. The development team then selects items from the Product Backlog starting at the top (priority requirements) based on their ability to do. Finally, the development team divides each condition into tasks and estimates the time needed to complete each. 

Sprint

The Sprint encompasses analysis, design, testing, and development activities. During the latter, the development team raises business questions. If necessary, the AMOA answers questions (turns to other actors such as the MOA) and completes the associated User Stories. The AMOA verifies during the Sprint the proper conformity of the developed functionality and issues feedback if required, which will allow the functionality to be adapted.

The development team meets every day during the daily Scrum to discuss the work done the day before and that of the day and to raise the obstacles encountered. Each team member updates his “Remaining To Do” on his current tasks to update the sprint progress graph. This point is limited to 15 minutes; other project actors can be present, but only the development team members have the floor.

Sprint Review

At the end of the Sprint, the development team presents the new functionalities produced as a demonstration to the Product Owner, accompanied by the AMOA (and other interested parties). The Product Owner – with the help of the AMOA – accepts or rejects the features presented. Feedback is noted. 

Depending on the results, the Product Owner can request a product delivery to test the entire product in anticipation of a production release. In this case, depending on the results of these tests, a few days of product consolidation may be necessary. If the Product Owner does not request a delivery, a new sprint is planned (see “Sprint Planning” paragraph).

Sprint Retrospective

After the Sprint review, the development team and the Product Owner meet to identify the adaptations likely to increase their productivity. Things that work, things that don’t work, and areas for improvement are identified in this meeting. Everyone’s ideas are used.

Summary Of Meetings

NB: the steering committees are not described in this organization. They generally differ little from a traditional approach (for example, weekly monitoring committee and monthly steering committee). However, it may be interesting to stick to the rhythm of the sprints or even to pool the sprint reviews with a steering committee, for example.

Sprint Planning

1. Objective(s): define the scope and objectives of the Sprint, then split them into development tasks.
2. Responsibility: Product Owner.
3. Participants: Product Owner, ScrumMaster, development team.
4. Frequency: Before the Sprint.
5. Maximum duration: 4 hours.
6. Input Document(s): Prioritized Product Backlog.
7. Output Document(s): Sprint Backlog.

Daily Scrum

1. Objective(s): coordination of the development team, identification of the obstacles it encounters, and measurement of the progress of the Sprint.
2. Responsible: Scrum Master.
3. Participants: development team, ScrumMaster, Product Owner/AMOA (optional).
4. Frequency: daily.
5. Maximum duration: 15 minutes.
6. Input document(s): Sprint Backlog.
7. Output Document(s): Updated Sprint Backlog and Progress Chart.

Sprint Review

1. Objective(s): presentation of the functionalities produced during the Sprint to the Product Owner and end users, reception of feedback.
2. Responsible: Development team.
3. Participants: development team, Product Owner, ScrumMaster, end users, and guests.
4. Frequency: At the end of the Sprint.
5. Maximum duration: 2 hours.
6. Output document(s): List of feedback.

Sprint Retrospective

1. Objective(s): improve the productivity (velocity) of the development team.
2. Responsible: Scrum Master.
3. Participants: development team, ScrumMaster, Product Owner/AMOA (optional).
4. Frequency: After Sprint review.
5. Maximum duration: 1h30.
6. Output document(s): meeting report (Sprint report + action plan).

Artifacts

Product Backlog

The Product Backlog centralizes the list of expected requirements (functionalities, non-functional requirements, defects to be corrected). The Product Owner takes ownership of this Product Backlog and prioritizes its elements based on the business value and estimated cost of each. The cost unit is the “point”.

The choice of such a unit avoids the confusion between time and cost, underlines the “estimated” (imprecise) character and facilitates release and sprint planning. These estimates are made initially from a not-very-detailed need. They can be revised during the iteration planning in case of deviation from the assumptions established during the first estimate.

Sprint Backlog

The Sprint Backlog includes the list of tasks (its scope) and the associated workload. Every day, the development team updates the To Do for each job to plot the Sprint progress graph.

Table Of Tasks

This table includes the list of Sprint Backlog tasks, which allows the development team to coordinate. It generally has four columns: “To do”, “In progress”, “To check”, and “Done”. It is wall-mounted and easy to interpret, allowing anyone involved in the project to know at a glance the “real-time” progress of the Sprint.

Sprint Progress Chart

Throughout the Sprint, anyone involved in the project can view the development team’s progress thanks to the progress graph updated daily. This graph shows the evolution of the Rest To Do (usually expressed in hours) as a function of time.

Specifications

Introduction

Based on the following observations:

1. Requirements are only entirely known once a project has started.
2. Users know what they want only after seeing the first version of the software (Humphrey’s Need Uncertainty Principle).
3. Requirements often change during the software development process (Hadar Ziv’s Uncertainty Principle – 1996)

Fully specifying an interactive system is impossible (Lemma by Peter Wegner – 1995) The project’s approach to specifications is to smooth out the work of writing specifications throughout the project and give them low contractual value. You are privileged instead to realize as soon as possible of software which functions at the end of each Sprint thanks to a collaboration between customer/supplier (business/technical, MOA/MOE) close.

Process

List Of Needs

The Product Owner establishes and maintains the list of expected requirements (functionalities, non-functional requirements or defects to be corrected). At this stage, the level of precision of the need is low. Each condition can be summed up in 1 to 3 sentences on average. The list of requirements feeds the Product Backlog.

Priority Needs

Before planning a new Sprint, the Product Owner digs deeper into the need associated with the priority features (at the top of the Product Backlog list). A good practice is to write a User Story for each expected functionality (the back describes the need, and the front lists the conditions or acceptance test to verify the market coverage). At the end of the Sprint planning meeting, the latter’s scope is fixed. It corresponds to the list of requirements selected by the development team materialized by a set of User Stories.

Design/Development

Once the Sprint has started, the developer appropriates the User Story, which will serve as a communication medium between him and the writer of the User Story (Product Owner, AMOA or user). As the questions are raised and the answers provided, the User Story will be completed until the end of the associated developments.

Specification Update

At the end of the Sprint, the development team updates the product documentation.

Agile Change Management

The need may change throughout the project (even late). In particular in the following cases:

1. Discovery of a new need corresponding to a new functionality to achieve.
2. Modification of functionality already realized.
3. Removal of an ultimately useless or infeasible need.

Principle Of Barter

As a reminder, the Product Backlog centralizes all the requirements (or needs) expected from the project. Each element of the latter has a cost estimate in points. Therefore, the sum of the forecast makes it possible to determine the project’s cost (estimate). Suppose the budget or even time constraints of the project are vital in discovering a new need or modification of functionality already carried out. 

In that case, a new item is added to the Product Backlog to remove another of the exact cost and more business value (see bottom of the list). Conversely, in the case of the disappearance of an ultimately useless need, the associated element is removed from the Product Backlog, thus freeing up a provision for new needs or future modifications.

Change During A Sprint

The sprint scope set at the end of the planning meeting must remain the same. In force majeure, the Product Owner can cancel the current Sprint, which can have costly consequences. Recent developments are stopped, and the development team is cut off in its tracks. A new sprint must then be planned.

Defect Management

Defect Management Process

A defect that could not be corrected during the Sprint is logged in the “Bug Tracker” by the tester. According to the information provided by the tester, the AMOA and the development team qualify the defects observed to know if a correction is necessary and possible. Confirmed defects are then prioritized by the Product Owner, assisted by the AMOA. 

The Product Owner identifies the list of defects to fix in the next Sprint. He will communicate this list to the development team during the sprint planning meeting and the priority requirements to be achieved. Critical defects (blocking the AMOA test work or presenting a significant risk in using the product soon to be put into production) can be added to the scope of the current Sprint as needed.

Production Incident Management Process

The development team can consider production incidents in the current Sprint.

Schedule

The project is driven by value and deadlines. Each year has four releases of 3 months to create a regular rhythm, promote the birth of project automatisms, and reduce the effort of project planning and coordination of internal actors and project partners. This principle of releasing the same duration also makes it possible to construct comparable indicators more efficiently to improve the development process and the organization regularly. 

The releases can therefore be considered as trains leaving and arriving at a fixed time with no possible delay. The perimeter is consequently the only adjustment variable to secure the quality, the budget and the deadlines.

Agile Practices

Poker Schedule

Planning Poker is a requirements cost estimation technique. This technique is practiced in a team and makes it possible to make rapid and precise estimates according to the level of precision of the available need. During the estimation sessions, the Product Owner (assisted by the AMOA if necessary) submits one by one to the development team the requirements for which he wishes to know the cost estimate. 

He answers questions from the development team and establishes hypotheses without an answer (need still needs to be clarified). The cost estimates (whose unit is the point) thus obtained feed the Product Backlog and help the Product Owner prioritize his requirements. The Planning Poker technique can also be used to estimate the business value in points of the Product backlog requirements as a team (Product Owner, AMOA, users, marketing, etc.).

User Story

The User Story is a specification technique allowing the synthesis of the need related to functionality in a few short and simple sentences using the business vocabulary (absence of technical connotation or description of GUI) exclusively. On the other hand, a User Story lists the functional tests known to date to verify the coverage of the need for the associated functionality. The advantages are many:

1. A User Story is quickly understandable by both a developer and a user,
2. It promotes interactions between developer and editor, thus promoting a good understanding of the need (face-to-face communication),
3. The tests listed reinforce the quality of the developments.

Here is another article to deepen the subject: Agile specifications.

Agile Development Practices

Continuous Integration

The role of continuous integration is to detect code integrity defects as soon as possible (the earlier a defect is corrected, the less expensive it is). It is materialized by a software tool recovering the latest code available on the version manager, compiling it and running the existing unit tests. 

It performs this task automatically with each code modification submitted to the version manager or several times daily. An alert is triggered if a fault is detected (email, audible or visual signal, etc.). Therefore, this tool makes it possible to reinforce the quality of developments and promote the essential work of regular code refactoring.

Test-Driven Development

Test-driven development involves making the developer aware of the tests upstream of his actions. Concretely, the User Story associated with a feature to be developed lists the tests that will confirm that this feature covers the need. This approach limits the interpretation of the developer’s needs.

Pair Programming / Pair Programming

Pair programming involves bringing two developers together on the same workstation to accomplish the same development task. This approach brings several advantages:

1. Allows to carry out advanced developments efficiently,
2. Better code quality (few defects, uniformity, maintainability),
3. speed of development,
4. The pace ​​of skills development (cf. new developers, especially junior).

Appendices

1. Agile values ​​and principles
2. Scrum Guide

Read Also: The Art Of Becoming An Ace In HR Reporting