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.