If your company is new to Agile development, there is a\u00a0chance that\u00a0some\u00a0roles and ceremonies will be interpreted wrongly. Most companies are rooted in waterfall project management methodologies, but Scrum differs vastly from traditional concepts of product development and it takes time to get used to a whole new set of\u00a0principles. In this article, we\u00a0will give you common mistakes we came across that people tend to\u00a0do while working in a Scrum.<\/p>\r\n\r\n\r\n\r\n
While it is true that\u00a0attending the daily stand-ups\u00a0you can get a grasp on how things are coming along in the sprint, their purpose is more focused on the future than the past. Attending the daily stand-up is about sharing useful information between team members and discussing what is coming next.
Often those meetings become a status report where everyone is stating\u00a0what ticket numbers they completed. Those meetings don\u2019t benefit the team and they perceive them as time-wasters.<\/p>\r\n\r\n\r\n\r\n
There is a maximum duration that a stand-up meeting can last but there is not a minimum one. If the team\u00a0has not much to report, it is ok to end the meeting fast. It is still good for everyone to attend the meeting because if someone has no issues they want to discuss, maybe there is someone who could use their help. Also, it\u00a0shows respect to other colleagues. Keeping the meetings short as possible\u00a0will underline the fact that the team has a good grasp of Agile principles of which one of the most important ones is \u201celiminate waste\u201d.<\/p>\r\n\r\n\r\n\r\n
It is preferable to have things planned out before the sprint start, but it can happen that some new information can cause the sprint to change. Agile is all about flexibility and it is more important to respond to change than sticking to some rules. On the other hand, if those changes happen constantly that you can not plan a week in advance, then maybe Scrum is not the best choice for your project. Luckily, there are other Agile frameworks like Kanban that could help you out in those situations.<\/p>\r\n\r\n\r\n\r\n
It is not rare that a company sees retrospectives as a luxury and a time-waster. There will always be a time crunch, but we should not put retrospectives to the side. Maybe a solution to eliminating that constant time deficit\u00a0can be discussed over a retrospective meeting. One principle in the Agile Manifesto states that the team has to reflect on itself to be more effective. Having retrospective meetings\u00a0is critical. Without them, you are doomed to\u00a0make the same mistakes over and over.<\/p>\r\n\r\n\r\n\r\n
Even when everyone understands the importance of a retrospective meeting, it rarely makes the impact it should. Often it is a meeting where everyone is telling their side of the story and a Scrum Master writing everything down without immediate action.
To avoid that, add concrete\u00a0actions\u00a0in the form of tasks to the sprint backlog, and set a due date\u00a0on the tasks so they don\u2019t dwell in the backlog forever. This way the retrospective is not just a way\u00a0for the team to get relief by telling what bothers them, it is also a powerful tool for self-improvement and adaptation.<\/p>\r\n\r\n\r\n\r\n
While Sprint Review IS a meeting where developers present the work completed in the last sprint, it is also an opportunity\u00a0to discuss the overall status of the project. Product Owner can show velocity charts and discuss the\u00a0estimated time of delivery. The entire team can collaborate and discuss how the market has changed and what would be the\u00a0best thing to deliver next. Timeline, budget, and marketplace can all be points to discuss at the Sprint Review meeting. Reviewing things constantly is in the spirit of Agile methodologies, and Sprint Review meetings are a perfect opportunity for the team to review where the project is heading.<\/p>\r\n\r\n\r\n\r\n
This mostly happens in companies that recently\u00a0adopted the Scrum framework. It takes time to accept that there is no hierarchy in Scrum and that we are all part of the same team. If a developer has questions about a task, he should go directly to the Product Owner and vice versa.<\/p>\r\n","protected":false},"excerpt":{"rendered":"
If your company is new to Agile development, there is a\u00a0chance that\u00a0some\u00a0roles and ceremonies will be interpreted wrongly. Most companies<\/p>\n","protected":false},"author":6,"featured_media":530,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[17],"tags":[],"class_list":["post-272","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-project-management"],"acf":[],"yoast_head":"\n