How to use scrum on the go? And how can we apply it on our work effectively?
If you work with project management or software development, you have certainly heard about Scrum. And probably about some of the famous success cases with your application, like for example, the Spotify storie.
Although we always see the scrum defined as “a simple framework for managing complex projects”. In fact is that it is quite prescriptive, and it takes time for the team to adjust to all of its practices. But we can certainly achieve good results with.
In this article I will talk about the concepts of this framework. This will be the first of a path that I will write, which will go from theory to scrum in practice. Let’s go!
PILLARS
Transparency
All the time you can and should have access to all information related to the project. The idea is for information to be shared, so that managers, customers and stakeholders can access it at any time.
That is why it is important for the team to define which tools they will use to communicate, and which documents they will generate during the process. Since this is not defined by Scrum, which leaves this part up to its own time, so that you can do the best.
A tool that can help with this, originated from another agile methodology or kanban board. Which can give the answers of how all the tasks of the team are.
Inspection
Both the development of activities and the execution of the process itself can be inspected at any time. The inspection intent is that everyone is always aligned on the project situation. But this inspection should not be excessive in the point of hindering or in the development of activities, or in micro-management as people.
In terms of development there are two events to carry out the inspection part, they are the “Daily Scrum” and the “Sprint Review”. The process, on the other hand, can be inspected during a “Sprint Retrospective”. All of these events will be explained below.
Adaptation
The last pillar, guarantee that the Scrum process will always be adapted when necessary. The same is true for the product guidelines, which have shorter cycles of interaction with the customer, also have the possibility of being adapted more easily.
ROLES
Product Owner (P.O.)
Responsible for directing the product, it is he who defines which features will be developed. It also prioritizes them for the team. In addition, he must always make it clear what the objectives of that project are and pass the product on to his team.
Scrum Master (S.M.)
It is the team member who must master Scrum practices. Known as a facilitator, he always assists and ensures that the team is performing the process correctly.
Development Team
Is who develops the product in fact, and has the power to decide the best way to do this. In Scrum, the development team has the autonomy to choose how to develop their tasks, to achieve the project’s objectives. The team must be self-organized and multifunctional.
EVENTS
Sprint Planning
At this meeting, the dev team talks about the items in the product backlog and selects what will enter the sprint backlog. Always respecting the prioritization order defined by the P.O.
In addition, the team also takes the opportunity to debate how the demand will be developed, and at that time the P.O. can explain the requirements and objectives of that user story. Thus, the team will be able to have a clearer understanding, and will be able to jointly define the best way to meet the demand.
Daily Scrum
Meeting that must take place daily so that the whole team is aligned on the progress of the project. It should be done with all members standing, as it needs to be something fast, lasting a maximum of 15 minutes.
Usually developers answer 3 questions:
What was done yesterday?
What do you plan to do today?
Was there or is there any impediment?
Sprint Review
Held at the end of every sprint, this meeting serves to assess whether all work items are in accordance with what the customer expects. Here the team presents what was developed for the P.O., and he will rate the delivery.
In this meeting, the participation of product stakeholders is usual. It is also there that we can keep the product backlog updated.
Sprint Retrospective
Held after the review, the retrospective meeting serves for the team to assess how it is working with the framework itself. That is, how they are using the scrum in practice and what the results are.
Some articles talk about raising negative and positive points of the sprint. But I prefer the authors who suggest using the following questions:
What did we do good?
What do we need to improve?
And for everything that needs to be improved, the team must define an action plan.
ARTIFACTS
Product Backlog
List of product features is created, prioritized and maintained by the P.O., used by the team during the sprint planning.
Sprint Backlog
Functionalities selected from the product backlog, by the development team during planning. Ideally, this list of items should be delivered at the end of the sprint.
Incremental Deliveries
At the end of every sprint, the team must increase the product with a functional delivery.
This was the first article on the “Scrum on the go” path. I gave an introduction to the concepts of this framework. In the second article, you can see how the scrum flow works.
