Starting Scrum

In today's era of software development, agile project management methods are often adopted. More often than not, SCRUM emerges as the preferred choice. Embarking on a new project with a fresh team can quickly lead to frustration. Initially, gauging the pace of developers, or even the entire team, within an unfamiliar project and team, as well as assessing the complexity of functions with the selected framework, can be challenging.

Every beginning is difficult

When you begin with such a new setup, it's crucial to understand these parameters as early as possible. This doesn't mean making assumptions based on other teams or projects. Instead, it requires testing over two to three sprints, monitoring how many story points, as estimated by the team, can be achieved within those sprints. The responsibility of project management and the Product Owner is clear: they shouldn't hold the team accountable for misestimations. Especially in the first sprints—most notably the very first one—it's vital to accept these deviations. Often, we've found success starting our initial iteration with a Kanban System instead of SCRUM.

The team is key

SCRUM is designed for teams that work full-time or predominantly on a single project. It's rare for one team to tackle multiple sprints simultaneously. At the inception of various projects, we've frequently noticed that project roles weren't defined clearly enough. At the outset of every project, it's essential to distinctly specify who the Product Owner, SCRUM Master, and Developers are. Moreover, having an experienced Project Manager on board is crucial—one who supports the team and remains calm even when things don't go by the book.

Another point we'd like to make is that very small teams—those with one or two members—shouldn't necessarily rely on SCRUM. By this, we aren't referring to developers but "regular" full-time staff.