As a project manager, I’m very keen to use methods for organizing work which get the job done while keeping the team energized and engaged. If you’re in a similar situation, maybe you would benefit as much as I did from applying the Scrum framework to your projects. Here are some takeaways based on my experience of using it to manage some of my projects.


If an IT team has to be coordinated towards a single objective, Scrum is one of the most popular ways to go. If you go to the App Store or Google Play to buy or download a mobile app, you can be sure that Scrum is more than 75% of the apps you see. Scrum provides a framework for developing and delivering software products which allow development teams (and their leaders) to optimize work and control risk through regular, iterative and transparent processes. Why in apps in particular? Well, software products are almost never finished products, and mobile apps are typical insofar as they need to be updated all the time for fixes or updates. Therefore, apps are characterized by an iterative developing process to which Scrum is particularly suited. I first encountered Scrum when I was working in a software house developing apps. The funny thing is that I met only a part of Scrum, but the part I met was really useful. Now that I know Scrum in its entirety, I appreciate that parts of its framework can be used by themselves in any project to get specific things done, e.g. to push through peripheral development under a short deadline.


No matter how many people are involved there are only three roles: two roles to be performed by single individuals and a third role which can be performed by many people at once.


Often described as „The voice of the customer”, the PO identifies the customer or the market needs and communicate them to the team. They set the objectives and the priorities for the product, and theirs is the deciding voice in what gets done.


Part slave, part slave driver, the Scrum Master does both whatever the PO wants and delegates duties to the team. When necessary, the Scrum Master supports the individual team members, helping them complete their tasks when absolutely necessary, but normally providing oversight and coordination, which requires them being in the loop on every activity. One of their most important functions is to resolve conflicts among team members e.g. who should be responsible for completing a task.


The team exists to achieve its objective, normally the creation of a piece of software. Although achievement of the team’s ultimate goal is a shared responsibility, each member of the team has specific skills, different from those of other members. Teams are best kept small e.g. 7 people because there is no hierarchy: with more people, the team may lose focus on their goal and the daily meetings would be very time-consuming.


Scrum consists of many processes, some for planning, some for execution and some for analysis. In this article I’m focusing on implementation, so let me tell you about the key framework for implementation, which is the Sprint. A Sprint is a part of the overall project consisting of a limited time frame in which certain actions have to be performed. A Sprint can be considered as a mini-project with definable outcomes. Sprints are organized around 3 types of meetings: Sprint Planning: a meeting which involves everybody from the Scrum Team, in which the PO identifies the task be achieved, the team breaks it down and responsibility is allocated for completing the component parts. Daily Stand-up: what it says on the box — this is a daily meeting during which the team stands up to keep things short. The purpose of this meeting is a quick status update, where each member of the Development Team (who has their own task) needs to answer 3 questions posed by the Scrum Master:

  • What have you accomplished since the last meeting?
  • What will you be working on until the next meeting?
  • What is getting in your way or keeping you from doing your job?

Daily meetings make the team more productive and efficient: because the meeting ends after 15 minutes, there is no place for wasting time! Sprint Review: Coming at the end of the Sprint, this meeting gives an overview of how the latest Sprint went, what items can be considered completed, and which items are now part of the Product Backlog. The most important aspect of this review meeting is to encourage conversation between everyone in the SCRUM team. The whole team looks back over what has been done in the current Sprint and discusses what needs to be done to improve performance in the future Sprints.


First of all, my experience of the meetings is that the daily ones are very high energy, perhaps as a result of the fact that people are only allowed to stand! The energy level is a little lower in the review meetings, as they generally occur at the end of the week when everyone is already thinking about going home. Apart from that, from my point of view of a project manager, using the SCRUM framework has 4 big advantages:

  • Thanks to the daily meetings, problems are visible early. As a result, they can be contained early and their effect limited.
  • The focused questions for the daily meetings place an obligation on team members to find solutions to their problems.
  • Scrum’s flat structure means that everybody feels equally responsible.
  • The daily meetings make processes really transparent and team members very approachable. As a result, as a project manager, I can see what’s going on without getting too deeply involved.

At the project level, the SCRUM methodology provides:

  • flexibility for changing the scope of a project when it already underway [because the project components are broken down into very digestible but standardized elements (Sprints)],
  • control over getting things done (thanks to intense sprints rather than drawn-out quarterly milestones),
  • control over resources (time, money and manpower), which can, therefore, be used efficiently.
Warning: because SCRUM works best with iterative processes and encourages everyone to drill down into the details, there is sometimes a danger of losing sight of the big picture, or finding yourself in a never-ending project with constantly shifting goals. Being aware of these dangers has helped me to avoid them. If you try SCRUM out for yourself, I’m sure you’ll find your own coping mechanisms.