Audrey Bassien-Capsa
By Audrey Sep 24, 2021
In collaboration with Mathieu

Agility According to Uzinakod

Throughout various articles, we have discussed the Agile method from the perspective of the Product Owner, and the comparison between Agile and Waterfall. Agility, as its name indicates, is a flexible concept with general principles, and not a rigid framework. Each organization therefore creates its own definition. What is Uzinakod’s definition? Let’s get to the heart of the matter with this article that tells you everything you need to know about the Agile method, Uzinakod style.

Let’s start with a question: what do Agile and athletics have in common? Sprints!

Sprints (or iterations) are development cycles during which the Uzinakod team works in partnership with the client on the delivery of features. It is the progress of each of these iterations that allows the project to move forward, like successive relays in athletics. Without being Usain Bolt, the Uzinakod team members and the client work together to cross the finish line. The time has come to introduce the Agile team, Uzinakod style.

The Agile Team, Uzinakod Style

Our Agile team takes the Scrum method as its starting point, and adds other roles. Depending on the project, a team member can formally or informally wear several hats. Conversely, certain responsibilities may be distributed among all the team members.

The Classic Scrum Roles

Product Owner, The Orchestral Conductor

The Product Owner, or “PO,” is an asset of the client’s company. Their role is an adapted version of the Product Owner role in the Scrum method. With the help of the Uzinakod team, they:

  • Have a global view of the application
  • Maintain focus on the company’s overall objectives for the application
  • Identify priorities

See this excellent article for more details on the Product Owner’s role.

Scrum Master, The Facilitator

  • Removes obstacles that could impede the team’s progress on the work being done
  • Keeper of the sprint scope and goals
  • Communicates on the progress of the sprint relative to the objectives
  • Ensures the application of Agile principles

The Delivery Team

The Delivery Team consists of three specialisations:

1. Business Analysis

  • Acts as a bridge between the client and the development team
  • Identifies needs, ensures understanding of end-user context, defines context and functionality objectives
  • Backup Product Owner: gives details on the needs users have expressed to help prioritize

See our article on the Business Analyst.

2. Development

  • Supervised by a team leader (“Team Lead”) at the technical and skills development levels
  • Defines and implements the technical solution that corresponds to a feature
  • Demonstrates the delivered features at the end of the sprint

3. Quality Assurance

Occasionally a shared responsibility with a QA analyst dedicated to the project

  • Definition of test scenarios according to the client’s reality
  • Definition of more elaborate scenarios and exceptional cases during development
  • Identification of anomalies

Also see this article on the QA Analyst.

Leadership Roles

Project Manager

  • Custodian of the scope and budget
  • Monitors overall project progress relative to the objectives defined for the project or project phase
  • Analyzes the impact of major priority changes and scope modifications on the schedule and/or budget
  • Identifies risks

Account Manager

  • Maintains the client’s relationship with Uzinakod
  • Permanent point of contact for the client in parallel with the projects
  • Attends to all billing, maintenance, and evolution needs of the application

The Agile Schedule, Uzinakod Style

In order for the team to move forward (and more importantly, move forward in the right direction), recurring checkpoints are kept to ensure that everyone is aligned with the same goals. These are the Agile meetings, also called “Agile Ceremonies,” which are held throughout the sprint. To make the best use of our Product Owner’s time, some of these meetings involve only the delivery team.

The Daily Stand-Up

Frequency: Daily, preferably at the beginning of the day
Purpose:
To communicate each team member’s progress
Key Players: Product Owner | Scrum Master | Delivery Team
Process:
Each team member goes over what they did the day before and what they will do today, and identifies any challenges they are encountering

As with jokes: the shorter the meeting, the better. 😉 The daily should last 15 minutes tops. Roadblocks that come up in the daily are just conversation starters… the rest will come in another meeting!

Prioritization

Frequency: Once or twice per sprint, depending on the project context
Purpose:
To guide the planning of the next sprints, and better follow the progress of the features by identifying priorities
Key Players: Product Owner | Project Manager | Business Analyst | Analyste d’affaires | Scrum Master
Process: Depending on the phase of the project, the discussions will be at a more or less detailed level

  • Define together the medium-term objectives of the application. (What activities do we want to be able to achieve in 3 months?)
  • Prioritize more precise functionalities brought by the end-users in the analysis meetings or by the delivery team

Groomings

Frequency: Once or twice per sprint, depending on the volume of features to evaluate
Purpose: Define the relative effort of features (“user story”) according to the defined priorities
Key Players: Project Manager | Delivery Team | Scrum Master
Process: The team reviews user stories (scope, context, expected results) and evaluates each one in terms of complexity and level of uncertainty with what are called “story points”

The number of story points delivered by the team in a sprint determines its rate of progress, called velocity. Velocity serves as a guide for planning quantity in future sprints.

Pre-Demo

Frequency: 1 time per sprint, before the demonstration
Purpose: Identify the elements that will be ready for presentation during the end of sprint demo, and define the scenario that will be presented
Key Players: Delivery Team | Scrum Master | Project Manager
Process: The team reviews the stories that have been completed and refines the scenario for the demo

Some adjustments may be identified at this stage, and made or prioritized with the PO depending on their scope and impact.

Sprint Planning

Frequency: Once per sprint, at the beginning of the sprint
Purpose: Define the content to which the delivery team is committed in the new the sprint
Key Players: Project Manager | Delivery Team | Scrum Master
Process: User stories and bugs are added to the sprint according to the priorities defined, the team’s velocity, and the team’s availability

A sprint goal will be determined by the team and communicated to the Product Owner.

In some cases, different features will be assigned to specific team members.

End-of-Sprint Evaluation / Demonstration

Frequency: Once per sprint, at the end of the sprint
Purpose: To present the PO with the elements that have been delivered during the sprint
Key Players: Product Owner | Project Manager | Delivery Team | Scrum Master | Other members of the client’s team, if applicable
Process: The end-of-sprint review and the demonstration can be the same meeting or two separate meetings. The sprint debriefing allows to review the results of the sprint (what has been delivered, what has not been delivered and why) and to identify if the defined objective has been reached.

During the demo, as the name implies, one or more team members demonstrate the completed features in the application.

Comments from the PO or their team are collected and added to the backlog for prioritization.

Post-Mortem

Frequency: Once per sprint, after the demonstration
Purpose: To promote continuous improvement of the team’s operations
Key Players:
Delivery Team | Scrum Master | Project Manager
Process: Each team member identifies what went well in the sprint, as well as what went poorly, either with “post-its” or verbally. The team then decides on an action plan for what went wrong

Conclusion

Agility is an adaptive and evolving practice. Our definition is therefore not only bound to change over time, but also to scale with the size of the project and the reality of our clients. While this article outlines our method, it does not mean that everything you read here will be applied to the letter. Our goal is to take a pragmatic approach that facilitates the quality of our applications and the satisfaction of our customers.

Recommended Articles
Published on May 12, 2022

Agile Anti-Patterns and How to Deal with Them - Part 1/2

Several bad practices can make a team less effective. First, you need to be well equipped to recognize them. The anti-patterns presented in this article can be part of your team's current workflows. In this practical article, of a series of 2, we will explore the anti-patterns that make collaboratio

Read more
Published on March 30, 2021

The Business Analyst’s Role in 5 Questions

Business analysts are increasingly sought after in the information technology field: we can explain this trend in part by the general growth in business software spending (which more than doubled between 2009 and 2019*), but this is not the only factor. It is also because IT companies are increasing

Read more
Share on