๐ซ Build a team
Manage client projects the Agile way
Task lists get lost in endless email exchanges. Complicated ticketing software drives us to madness. Over time, we have learned to embrace smart, well-made work tools designed to facilitate asynchronous collaboration. Regardless of the chosen tool, what really matters is creating a space, virtual or physical, where the work to be done is easily visible.
At Moze, we use the project management tool as a reference point for tasks. We value discussions on what needs to be done among team members. We follow the principles of the Agile philosophy, which prioritize "working software over comprehensive documentation." However, this does not mean starting from vague specifications. For example, a developer appreciates being assigned a task that has already been explored in various scenarios and cases; they feel comfortable starting with concise but comprehensive documentation. On the other hand, if the task is exploratory in nature, it's important to specify it clearly in advance, allowing team members to interpret it flexibly.
Organize Work in Sprints
At the beginning of our journey, we used to organize work by creating long to-do lists on Basecamp. When dealing with projects that span several months, this approach can be counterproductive. This is because progress projection is solely based on the deadlines set for various tasks. In the end, you end up working like hamsters on a wheel, always chasing the next deadline, with an endless list of things to do. We've been there, and we know it well.
By starting to work in an Agile manner, we organized internal project activities into sprints, which are predefined iterations, typically lasting two or three weeks. In practice, this means breaking down a larger project into smaller sub-projects. Each iteration leads to an incremental version of the product being worked on. The goal of each sprint is to develop something โ a part of the product โ that is complete and functional, at least in terms of basic functionality. Of course, there will always be time to make improvements or add new features to the product later on. However, at the end of each sprint, we share with the client a new, albeit small, working part.
This goal is not always easy to achieve. When working for clients, the first sprints are often the most critical. For example, the entire first sprint is often focused on the technical setup of the project and the development of basic user interface components. While this may give the impression of a slower initial phase, it actually allows us to be much faster in the subsequent implementation sprints. It is crucial to be transparent from the beginning and set clear expectations; otherwise, a non-technical client may worry that the project is already behind schedule from the start.
Define a Process
It is also important to clearly define the work process to be followed during the sprints. Over the years, we have developed a very simple process that allows us to maintain a sufficient level of organization. Using a Project Management tool, we divide project tasks into columns. The first one is the Backlog, where we enter all the tasks to be completed. Then we have a column for tasks to be addressed in the current sprint. This is followed by a Quality Assurance (QA) column, where another team member can assist in reviewing design or development work. Finally, we have a column for tasks completed during the sprint, which will be presented to the client.
Perhaps it's due to the shorter time horizon or the fact that people tend to work better when tasks are organized in "timeboxes," but by following this approach, we feel that projects are more manageable. This process also seamlessly integrates with Agile contracts, where it is agreed with the client that the unit of progress (and compensation) is the individual sprint, along with the value produced at its conclusion.