Tuto knihu jsem si vybrala na základě doporučení od Scrum Mastera z Heureky.
Četla jsem ji s vědomím, že bych chtěla lépe porozumět celému konceptu a aplikovat jej v rámci možností u nás v týmu. Proto jsem se v průběhu snažila co nejvíce hledat shody mezi našimi systémy fungování a vytvořit jakýsi průsečík, který bude vyhovovat hlavně nám. Snažila jsem se vyřešit problémy jako nedostatek transparentnosti, ztráta informací, chaos v práci a špatné dělení úkolů.
Kniha byla psaná v angličtině, a proto se toho budu držet a esej napíšu také v aj.
„The Scrum framework is not as complex as it looks. Everything looks complicated when you’re still starting with a new process, “
So, the first step is to adapt the agile (scrum) mindset, because
„Changing practices is one thing; changing minds is quite another” ―Mike Cohn
Courage
Team members must feel empowered to take action to fix even the toughest problems.
Focus
Everyone has a laser focus on the project like their lives depended on it.
Commitment
Personally commit to achieving the goals of the team (They all need to have a clear understanding of the bigger picture)
To be successful you should be obsessed with your goals.
Respect
Respecting each other’s different skills and capabilities.
Openness
Honesty and directivity throughout interactions.
There should never be a surprise because everyone knows what everyone else is doing.
Personally, I think that these values are in some cases represented in our community as well, or they should be. We state them differently, but I consider these as very important too and I connect with them. I do find many similarities between ours and those.
Transparency – Everyone in the team knows what’s going on
Adaptation – Teams change tactical direction depending on the situation
Inspection – Look at what teams do and how they do it
These key principles are exactly what I was missing in our team, and I hope Scrum framework will help as to adapt them.
This is my opinion on how adapting scrum can help us:
- More transparency
- Decrease in the loss of information (things to do will be added to product backlog)
- Improving the process of reflecting and planning monthly team goals
- Supporting finishing a task
- Easier and faster problem detection
- Improved overall productivity
- Easy way
„Scrum is not a methodology. It is an empirical process that allows you to inspect and adapt to changing situations consistently and continuously. “
Scrum operates in a 3-3-5 framework:
Three Roles
✓ Product Owner
✓ Scrum master
✓ Development team
Three Artifacts
✓ Product Backlog
✓ Sprint Backlog
✓ Product Increment
Five Events
✓ Product Backlog Refinement
✓ Sprint Planning
✓ Daily Scrum
✓ Sprint Review
✓ Sprint Retrospective
In our team we decided that we want to try to work more in agile. We will not adapt the full scrum framework, just use some parts that can benefit us. While making this, I have actually realized, we already do work in a similar way as scrum teams. So we are just trying to give it a form that works the best for us and makes us more efficient. It is an experiment.
The most important thing was to identify what our product is. It is us.
In our team, we do will not place these new roles as they are described in the book. The roles that we already have, have many similarities with these new ones.
Represents the clients, customers and other stakeholders. The focus is on delivering the right product to the customers. He takes care of the business side of things – investment, prioritization, requirements. Ensures that the team meets the project goals.
Main responsibilities:
- Maximize the value of the product
- Manage the product backlog*
- Decide on what product and when to release it
- Act as a representative of stakeholders and customers to the Development Team
- Sets sprint goals
The role of a product owner reminds me of our Team leader role, with a difference, that many of his competencies are in our team managed by managers or other members. He does try to maximize the value of the product. Because we are the product. And he always does what best for the team, that we can grow bigger.
He doesn’t have a responsibility of a product backlog – that belongs to another person.
*Managing a product backlog – create, describe and prioritize (using user stories)
„He or she coaches the team to develop norms and standards that comply with Scrum. In return, the team must respect the Scrum Master and trust that he or she can help the team resolve difficult problems. “
Responsibilities:
- Help team members understand the Scrum framework as defined in the Scrum Guide
- Provide support and ensure that the resources needed by the team are available
- Cut impediments to create a working environment where the Development Team can deliver and succeed
- Remains neutral and don’t favor one side over the other
- Encourages members to do their best thinking and practices
- Promotes collaboration, engagement, and synergy
- Provides charismatic authority
What is SC NOT?
- He is not above the team.
- His suggestions are not always accepted
I would compare the role of a Scrum master to a role of a coach. The difference is in the framework. Scrum master understand scrum and coach should understand Tiimiakatemia methodology.
The primary responsibilities of the Development Team are to:
- Create the product and the product increment
- Self-organize itself and its work process
- Work and operate in a series of Sprints to get the job done
- Collaborate with the Product Owner to ensure that the team is working towards maximizing value
The Development Team can have a maximum of ten dedicated and full-time members. Bigger teams can lead to more elaborate and complicated processes that can be inefficient and costly.
Development team is everyone else in the team. We also include our team leader here too. There are more than of us and I think we do feel it’s hard to cooperate but it is possible.
*Stakeholders
- Internal or external entities that have a stake in the project (end-users, customers, investors)
„The Product Backlog is an ordered list of requirements needed in the product. “
Each item on the list must have a specific criteria.
Our product backlog is at the moment on Trello. Any member of the team can add a task there. We do not have a specific criteria for the items yet and we have not developed a system in which we will prioritize. We have specified that the product backlog will include call for help and tasks that need to be done to achieve a sprint goal (those tasks will be later on moved to a sprint backlog). They should also include any other tasks, that will help to maximize the product – us. Which basically means items, that can help to improve ours and our team’s development to reach our full potential.
Includes all the activities the team needs to do during a current sprint. They are pulled here from the product backlog.
What is there?
- Product backlog items based on the sprint
- List of tasks to accomplish the sprint goal
- Al least one high priority process improvement
Things can change during a sprint, so a product owner can adjust.
Our sprint backlog will work the same.
We will not use this artifact as it is not relevant for us.
Prioritizing the Product backlog. It prepares the member before they go int their Sprint planning meeting.
During this event, the whole team gathers together and starts discussing the highest-ranked backlog item.
We adapted this process in our team but changed it a little bit. We cancelled our business meetings and decided to hold a Weekly scrum meeting on Monday afternoon, where the items on our scrum board in Trello will be discussed.
During the first one in the current month, we will prioritize and move items from product backlog to sprint backlog. We will assign each task to someone. Now I am starting to wonder if we will need to meet every Monday.
The team looks at the Product Backlog and creates a forecast of what can be done within the Sprint time frame specified by the team. They also identify the correct order of work.
The sprint goal is set. It is an objective, that must be met. The sprint goal is fixed, but how its achieved can change throughout the sprint.
We have been working in a month-long sprint, without knowing about it. We hold Training session, where we set goals for the next month and that is basically our Sprint planning. Before we adapted scrum board it was hard for us to achieve the goal because we didn’t keep track of your tasks to get there anywhere. We hope the loss of information will improve using Team Trello board.
„This is a 15-minute daily meeting wherein the team looks and inspects its daily progress. Doing so allows the team to make changes and updates to the daily plan. Daily Scrum is not a status meeting. It is an opportunity for the Development Team to inspect the progress and adapt towards achieving the Sprint Goal. “
It finds answers to the following questions:
- Is the team moving towards the Sprint Goal?
- Does the team need to re-plan?
- What are the things the team needs to work on to achieve the goal?
- Does the team need help?
- What critical issues need to be addressed immediately?
- What impediments have team members identified?
Team members shouldn’t wait for the Daily Scrum to bring up issues and problems.
„A Daily Scrum is necessary to share commitments, identify impediments, stay focused, increase collaboration, and maintain situational awareness. “
We used to do an Agile stand-up, which is basically the same. We answered 3 questions about our improvement in subject team skills, but it was more of an irrelevant report and we stopped doing it. We also had it only once a week, which was not efficient. We will try to adapt it again but make it relevant towards achieving our sprint goal. We prepared a bord with all the question on Miro, where will everyone write their answers in advance. This ensures that we have it recorded and we will listen to each other, because during the daily scrum, we can project it on the board.
The product is presented to the Stakeholders, and they are encouraged to provide feedback, criticism, comments, reactions or opinions. Based on the insights of customers, the product backlog is updated. It is a way to build a product, that the customers really want
We will not hold a Sprint review. We have identified ourselves as customers of the product, which means, that so far, it does not make sense for us to do this. Maybe we will come up with a different opinion later on and start doing it too.
The team discusses what has happened in the past month, what went well and what didn’t. It makes the members to pause and reflect.
It evaluates the previous sprint and makes necessary adjustment and improvements fir the next sprint.
No external stakeholders are invited. (Team needs a safe space). The conversations and discussions can be uncomfortable for someone.
It is also about inspecting how the team works and how it adapts to changes.
Scrum master facilitates the retrospective meeting.
Format:
We are already doing a retrospective in our team. At the end of each month we have a training session where we focus on reflecting on the past month. We used to put the planning in this session too, but recently realized, it is not effective and split it in two different ones.
This book was very theoretical but helped me understand the concept a lot. I was finally able to adjust it and transfer it onto our team. It is an experiment, and we will see how it works and if it helps us. To my surprise, there were actually not that many changes needed in our process, the hardest part was just identify what we are actually doing and how can it help us to be more effective. My goal was to simplify everything not to make it more complicated.
