Best practices, tips, and advice for surviving a week as a developer
In this short article, we want to explain what it’s like to work in an IT team: we’ll look at how work is organized, how releases work, and most importantly, how to respond to the problems that arise. All this while offering some practical tips.
We will start at the end of a sprint (see appendix at the end), with the presentation of the project’s demo to the client: we will collect feedback, open tickets, estimate the time required to resolve them, close them, manage emergencies, and release. The week will end with the completion of the new sprint and the next demo.
Table of content
- Project Demo
- Sprint Planning
- Tackling a Ticket
- Handling Emergencies
- Demo and Release
- Appendix: The Agile Methodology
Project Demo
The project demo is when the development team showcases the work completed during the sprint. It’s an important phase to align stakeholders on progresses and gather feedback from the Product Owner or the end client.
Frequency: The demo is usually held at the end of the sprint, depending on the sprint’s duration (in this case, one week).
Participants: This includes all development team members, the Product Owner, and other internal or external stakeholders, such as clients or high-level managers.
Purpose: To demonstrate the features or modifications made to the project and receive immediate feedback to confirm if the project is heading in the right direction and identify new features to add or bugs to fix. The demo is also an opportunity to celebrate the team’s progress. Often, working prototypes (Minimum Viable Product – MVP) or live builds of the software are presented.Benefits: It maintains a constant flow of communication between the team and other stakeholders, encouraging better alignment on future goals.
Sprint Planning
Following the demo, new features or bugs will need to be addressed. Sprint planning is crucial when the team defines which tasks will be completed in the next work cycle and in what order of urgency.
Preparation: We go to the project board on GitHub: in our repository (there can be multiple repositories associated with a single project), we add new issues, carefully describing what exactly needs to be done at the implementation level to avoid any doubts later.
Ticket Selection and Estimation: The team discusses which tickets can be completed within the given time frame. This requires balancing the team’s capacity with priorities. For example, if there are bugs that could prevent the next release, these should be fixed first.
Each ticket is estimated in terms of effort: the goal is to find a shared measure of workload, breaking large tasks into smaller, manageable ones. A Definition of Done is also established to ensure that each task is clearly defined.
The result of Sprint Planning is a list of tickets, ordered by priority, containing all the features or bugs that need to be addressed during our Sprint. Each developer will assign themselves a ticket from the To-Do List and move it to Doing, so the Tech Leader (TL) or Project Manager (PM) can immediately know who is working on what.Tools: For project boards, we usually use GitHub, but Jira, Trello, or Asana are also great tools for managing the backlog and keeping track of workflow and progress.
Tackling a Ticket
It’s time to start working on the code. As mentioned earlier, a ticket represents a single unit of work, which can be a user story (i.e. an informal description of the characteristics of a software system), a bug, or a technical task. Effectively managing these tickets is crucial for the team’s daily workflow.
Development: The developer moves the assigned ticket to the In Progress (or Doing) column and begins working on it, following the team’s best practices. Generally, our team adopts Test Driven Development (TDD), an approach where automated tests are written before the software to be tested. This method drives development, as the main goal is to make sure the code passes the predefined tests.
Once the tests are written, the developer focuses on writing clean, readable, and easily maintainable code, preferably with explanatory comments. Changes are never made directly on the main branch but on a separate branch, usually called feature branch, which is easily associated with the ticket from which it originated.
Pull Request and Code Review: Once the work is completed, the code is pushed, and the developer creates a pull request (PR) to merge the development branch with the main branch. Regardless of the tool used (GitHub, GitLab, etc.), it is recommended to use a PR template that guides the programmer in providing a brief description of the changes and instructions for testing them. This helps make the PR content clearer to the reviewer and future collaborators.
Another good practice is to reference the issue linked to the ticket. For example, on GitHub, using the symbol `#`, you can easily link the PR to the corresponding issue, automatically creating a connection between the two.
At this point, the ticket is moved to Review, and colleagues proceed to review the code, ensuring it meets the team’s standards and contains no errors.
Testing: A crucial part of the process is ensuring that no tests are compromised by the changes. On platforms like GitHub, we use a Continuous Integration (CI) system that runs the tests and blocks the merge into the main branch if any failures occur.
Automated tests (such as unit tests and integration tests) may not be exhaustive, so it’s a good practice to also run manual tests to spot any bugs that need to be fixed before merging the code into the main branch.Completion: After the code passes the review and tests, the ticket is marked as completed (Done).
Handling Emergencies
Emergencies always happen – this is the one certainty in a developer’s life! 🙂 These can be critical bugs in production or issues that require immediate attention, events that disrupt planned work. They must always be anticipated and managed.
Identification and Prioritization: When an urgent issue arises, the team must quickly assess the impact and criticality. Production issues that compromise service are addressed immediately.
Quick Resolution: The team members focus on a quick solution, usually bypassing the normal development processes. If the issue is a bug, a temporary patch or a revert of the change that introduced it may be applied.
Documentation: After resolving the emergency, a meeting is held to analyze what went wrong and how to prevent similar situations in the future. This phase is crucial for the team’s continuous improvement.
Retrospective: In many cases, emergencies are analyzed during sprint retrospectives to prevent recurrence.
Tools: Monitoring systems like Datadog or Sentry can be used to detect anomalies.
Demo and Release
At the end of the Sprint, we prepare for the new demo. The software release is a critical step when the code is deployed to users. This process can happen through scheduled releases or continuous integration and continuous deployment (CI/CD) practices.
The Demo: Once all feature branches are merged into the main branch, the running software is presented to the stakeholders, highlighting the features added during the sprint. Like at the beginning, the stakeholders will provide feedback, and the whole process will start again.
After the Demo, we can release our software.
Release Process: We open a release ticket. If we are using GitHub, we access our repository’s page and create a new release, assigning it a tag, which represents a “snapshot” of the current state of the codebase. We also add a summary of the changes included in the new version, with GitHub automatically generating a changelog from the pull requests.
This is just one way to manage a release. For example, in the world of web applications, we might have a branch dedicated to production. Since many web services are always live, changes are deployed directly into production, integrating them into the production branch. Part of the CD (continuous delivery) flow includes deploying to platforms like AWS, where the new features become immediately visible after a page refresh.
In other contexts, like industrial machines, releases occur through the creation of installers. There are many different approaches to releasing software, varying depending on the context and specific needs.
Release Planning: In an Agile team, releases can be continuous (thanks to continuous integration and continuous deployment techniques) or occur at the end of a sprint, as in this case.
Verifications and Testing: Before a release, thorough tests are run to ensure everything works as expected. This includes automated tests, manual QA, and sometimes releases in staging environments.
Gradual Release: In many cases, releases are made gradually, starting with a small percentage of users to monitor for potential issues before a full rollout.
Rollback: It’s essential to have a rollback (or revert) strategy in case something goes wrong during the release, allowing a return to a previous stable version.
Tools: Docker, Kubernetes, Jenkins, GitLab CI, and Buildkite are among the most commonly used tools for automating and monitoring releases.
*Appendix: The Agile Methodology
The Agile methodology is a project management approach that emphasizes flexibility, continuous collaboration, and the constant enhancement of product features. In an Agile context, work is divided into short, iterative cycles called sprints (usually lasting one or two weeks).
Key Values of Agile
1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.
Agile Rhythms
Daily Standup: Short daily meetings to discuss progress and any challenges faced.
Sprint: Weekly or bi-weekly meetings where product requests are analyzed, and corresponding tickets are created.
Retrospectives: After each sprint, the team reviews what went well and what could be improved.
Adopting Agile methodologies allows development teams to continuously improve, maintaining high software quality and enabling rapid responses to changes.
For more on this topic, read our article: Agile for Teams and Projects
Watch the video: How to work in an IT team – Alessandro Mamusa and Cristian Bianchi