Menu
27 Mar 2023 | 4 min read
Managing a dev team can be a complex task, especially when there are multiple teams working on different projects. In such scenarios, using Agile and Scrum methodologies can help streamline the development process and ensure everyone is on the same page. I would like to discuss with you today how our company 2hire, and specifically the Phoenix development team, manages our workload and collaborates using Agile and Scrum methodologies.
It is no secret that managing dev work is hard, with lots of unknown and unexpected issues coming up when you least need them. Many great people tried to figure out the best way to schedule dev work, keep track of the progress, and react immediately to the unforeseen. Finally, it is the early 2000s when the Agile Manifesto is actually released. Agile is a software development methodology that focuses on delivering value to the customer through iterative and incremental development. It emphasizes collaboration, flexibility, and rapid response to change. Scrum is a particular Agile framework that provides a structured approach to software development. It involves a set of ceremonies that help teams organize and manage their work. As it sets a guideline to implement Agile, it is not uncommon to find many different versions or variations of Scrum, and we are no exception.
The Phoenix team is one of several dev teams in 2hire. Like most dev teams we are structured as: Team Leader, Team Product Manager, Developers, and Product Owner. The Team Leader oversees the development process, while the Team Product Manager communicates with stakeholders. The developers work on completing the stories, and the Product Owner prioritizes the product backlog. At this moment, we can count 5 developers, 1 Team Leader, 1 Product Manager and 1 Product Owner, making up a team of 8 members.
We follow most of the Scrum ceremonies but we are not very strict to apply every single rule. As an example, we work in a one-week “Sprint”. In Scrum, a Sprint is a fixed period of time during which the team works to deliver a potentially releasable increment of product functionality. It involves several other fixed meetings to define the stories and tasks from the Backlog to be completed during the Sprint (Sprint Planning) and finally to present the results (Sprint Review). We as a team are not too focused on strictly following the Sprint definition, we use it more as a tool to keep track of the work in progress.
Instead of a Sprint Planning meeting, we hold our Refinement meetings on Mondays: this is a 1 hour meeting in which we discuss new stories to be added from the Backlog to the To-Do list. The stories are presented to the team and prioritized based on their importance and urgency. Then, the team decides the commitment for the week, which includes both hard and soft commitments: we are not compelled to a strict pledge of completing all the tasks within the week, rather it is more of a challenge we pose to ourselves as a team to meet our desired goal. We set in hard commitment all the stories we feel confident about, and use the soft commitment for the stories that may have some unknown issues or blockers.
In Scrum, a “story” is a high-level requirement for a feature or functionality that is being developed. User stories are written on index cards or in a digital tool and added to a Backlog, which is a prioritized list of all the features and requirements for the product. Typically, during Sprint planning meetings, the team selects a subset of stories from the Backlog to work on during the upcoming Sprint.
In our case, we define stories by giving a background or general description of the requirement, and then we describe in detail the Acceptance Criteria (AC), which are a set of conditions that must be met to consider the story complete. We are mostly flexible while working on a story, so whenever we find some AC cannot be met or must be changed for any reason, we steadily talk about it during our daily standups and take action.8
Every day of the week, we hold a quick daily standup meeting (from 15 to 30 minutes at most) to check the progress on the stories and coordinate our work. During the meeting, we discuss any blockers or issues we are facing, as well as offer help to team members who need it. This ensures that everyone is aware of what is going on and that we are all working towards the same goal.
Each story in our “Sprint” goes through several phases. First, during the Refinement meeting, it is added from the Backlog to the To-Do column of our Kanban board. Then, we move it to the Analysis column and start analyzing it, planning subtasks, and identifying possible blockers. Next, we move it to the In-Progress column, where we work on it and update the subtasks as we go.
Once all the subtasks are done, we go through a few additional but mandatory steps, such as tests, review, deployment, monitoring, and documentation. The only exception is for Spike stories, which are stories involving only study cases, investigations or analysis that would skip the test, review and deployment steps. Before concluding the story, we always spend some time contributing to the test coverage of our app. Most of the time we will add significant test cases to our end to end test suites, but on other occasions we may find it useful to add unit tests. It is important to always pay attention to any edge cases, as well as including regression tests to prevent future bugs. The review is usually done by a team member who did not work on the story. This ensures that the code is of high quality and meets our standards, as well as double checking all the requirements. The deployment is the process of moving all the changes to production. We also monitor the changes to ensure everything is working as expected. Finally, we document all our stories in our company Notion account: we write a new document for every story, reporting the story description, how we implemented it, any error or problem we encountered and often concluding with next steps to follow up, which may lead to new stories to be added in the Backlog.
In a typical Scrum fashion, every two weeks we hold Demo meetings to present all the stories completed over the two-week period. This 1-hour meeting has the same purpose as the classic Sprint Review meeting, even though we cannot always present our work to stakeholders. Instead, we take the chance to share important information between team members, to make sure we are all informed about every new feature so that anyone can take over working on different projects or epics. Moreover, it often becomes the right occasion to discuss together the proposed next steps for the stories, even drafting new follow up stories entirely.
I would like to spend a few more words on what I find the most interesting approach we put up in our team, which is also what makes the whole system work. In addition to working on stories individually, the Phoenix team often works in pairs to speed up the development process and reduce the likelihood of errors. This helps us to achieve our commitments more efficiently and effectively. Moreover, we have developed the concept of being “collaboratively selfish“, where we strongly encourage team members to ask for help directly when they need it. Even when we think we may disturb others or be a burden, we think it is better to call out to someone rather than keep trying alone. This attitude helps us work together as a team and avoid unnecessary delays or bottlenecks. It also helps us to maintain a positive work environment where everyone feels supported and valued. We understand that sometimes we may be too focused on our own tasks, but it’s important to take time out to help team members as needed. This collaborative approach ensures that everyone is working towards the same goal and helps us to achieve better outcomes. By working collaboratively and promoting this “collaboratively selfish” culture, we can continue to achieve our goals and deliver high-quality work.
The Phoenix dev team worked hard to find the right balance to manage our work efficiently, creating our own framework to handle all the workload and the unexpected. Our daily standups, story phases, and mandatory steps ensure that our work is of high quality and meets our standards. The demos allow us to get feedback and share among us the knowledge we mature while working on the stories. But, most importantly, we found a way to collaborate that puts first the wellness and the success of the whole team, without leaving anyone behind.
Senior Engineer at 2hire
Computer engineer with a passion for art. When not coding, you may find me painting, reading, binge-watching tv shows, or, most probably, sleeping.
