Scrum is a framework for learning how to work and the processes we use to do it. Its implementation demands increasing rigor in the definition of something that’s “done” and empowering teams to take ownership of their own processes. It is intended to answer the unanswerable: how to master uncertainty. But with every passing sprint and continuous feedback from the team, we have the opportunity to discover the right process that works for us. Collaboration is at the root of our success and has enabled us to learn from our mistakes and continue growing as a team and company. Yet, as more and more agencies adopt Agile, particularly Scrum as a project management and collaboration modus operandi, they can be susceptible to misunderstand the role of collaboration within a team.
When we first made the move to a Scrum system, we strictly followed the rules and tried to involve everyone at every stage of the product, design, development, and testing processes—because that’s what Agile is about: business people, designers, developers, and testers working together daily throughout the life cycle of a project. Every member, regardless of which team they are customarily a part of, is accountable to meet the specifications and deadlines required of the project, as they are the owners of their processes. For us, the most common way to bring everyone together was by putting meetings on the calendar, that ranged from 15-minute daily team standups to hour long Sprint Retrospective meetings. (And this applies to both remote and non-remote teams) By following a pure Scrum framework, we realized that we had to have fit in a sprint’s worth of work a minimum of 4.25 hours of meetings, without taking into account additional Tech Lead check-ins, general company standups, and any miscellaneous meeting that will come up, because as we all know, tech projects are unpredictable and chaotic in nature.
In the long term, we noticed that involving everyone in the plethora of Scrum’s “suggested meetings” was unsustainable. We realized, based on the feedback of multiple team members, that there were too many meetings on the calendar, and many developers tended to be overwhelmed with the work specced out for the sprint because most of the sprintly meetings were not conducive to their productivity. We realized collaboration does not mean you have to share everything; you are allowed to consult or coordinate with specific members of the team on a case by case basis to ensure that the right person is involved. This certainly removes pressure from other team members to participate in meetings that are not directly pertinent to them, and allows for better individual productivity in order to meet the project’s timeline.
After various iterations we also learned that certain meetings, such as the Sprint Review Meeting, which entails a live product demonstration in which the Product Owner’s confirms that items are done and a retrospective discussion of the product, and the Sprint Retrospective Meeting, which is intended to gain an understanding of each team member’s perspective of what went well and what could be improved in the process and discuss the process itself retrospectively, were meetings that did not need to happen on a sprintly basis. Two weeks, which is the length of our sprints, did not allow us to gather meaningful data about how the product and process were managed and how they could be improved. It became apparent that on a biweekly basis, the feedback was repetitive and not instrumental in improving our company processes.
For our projects to run smoothly, it is imperative that we collaborate with each other at all times. We do not depend solely on meetings to set action items and get updates from each other. We also leverage Jira, a notable project management software tool, and Slack, a team messaging app, to enhance our team’s communication and collaboration, lessen meeting times, and be available to each other at all times. Collaboration is at the core of how our agency works, and this is not just an internal mindset; we also bring this perspective and inclusiveness to all our clients, as they are the key stakeholders in all the products that we develop. In sum, it is not to say that collaboration does not hold the key to a project’s success, because it does. But it is also important to understand that there needs to be a balance, and that means you do not have to share and involve the whole team at every moment and Scrum’s recommended meetings are subject to each team’s discretion. So please, collaborate responsibly.