Implementing Scrum? – 10 Bad Practices To Avoid
Today, many companies are adopting the agile approach. The need for the agile methodology has grown in the IT industry, and in a few other industries as well. In the past years, there have appeared many proponents of the agile methodology. We will describe the process with these steps:
– Iterative development, time boxed process, collaboration with the customer enforced;
– The process naturally allows involving of all team members;
– Enabling fast, recurring and confident deployments;
– Continuous integration, easy resolving of changes.
Of course, there could be some bad practices that you can personally face about agile organizations and teams:
User stories in the sprint can be changed. Sometimes the user story has the same size and has increasing importance, but it should not be changed with a less important story. In some cases the story could swap during the sprint, but not to entirely change the initial requirement. When the sprint starts, the scope is sealed and a change in the needs will imply that sprint is invalid, as the goals of the sprint have changed.
Regular team meetings. One of the bad practices is when the scrum master asks frequent status updates from the team members. This is very unnatural to Scrum, since it looks like a micro-management. Scrum needs spontaneous, energetic and involved participation from all team members, with the scrum master defining the time/content and product owner listening in for potential questions and unclearness of stories. A good way to abandon this practice is to make standup meetings optional, until the team decides to meet and learn together.
Unclear, incomplete user stories. Agile methodology provides software with no defects, with the assumption that the product owner has expressed his/her intent completely and clearly. Stories that don’t have acceptance criteria – bring misunderstanding to everyone, or cause continuous arbitration throughout the sprint, thus lowering the quality and the speed. A good way to prevent this from happening is to close the sprint and immediately close a story that has no acceptance criteria. Product owners should adapt, since their budget is limited.
Product owner is also a developer/team lead. Product owner should determine the objectives and goals of the project together with the client, and not directing engineering tasks. There could be cases where a product owner could be in the advisory board. Defining how to do the work does not only wastes the time of a product owner, but also shifts focus away from the final goal.
Scrum master is the product owner. This case is similar to a pirate becoming a captain. Aside from daily dashing to the team and immediate lack of direction, the dictating nature of this role does nothing more than interruptions in the Sprint.
Automation is not always present. With no acceptance of testing running regularly, there is no proof that everything that worked so far is still working. Without testing, new development efforts will be unclear. Unclear results almost always float, disturbing the sprint. There have to be taken enough time and efforts for automating tests and deployment.
Deliverables are not finished at the end of a sprint. Putting the product to production could be optional, but deliverable that satisfies all user stories as a set is obligatory. Some teams, especially teams with short duration sprints, choose to have a consolidation sprint, before delivering the production.
Story points have large duration. They are measures of the efforts, not in terms of time. Once you realize the abstract nature of software development, you will understand that work cannot be quantified in time, but only in complexity. “This story needs 28 hours to complete.” “It could be done in 30, but we can sum up to a week and help in planning.” That type of discussion should not be done by any team, whether scrumming or non-scrumming.
There are no software oriented stories. This happens if the team has amazing technical capabilities, or infinite hours in a day. Scrum allows patchwork, add-ons on existing software to incorporate new features. But, over a period of time, the team might end up with a fragile and an uncontrollable product. To prevent this from happening, it is important to have a consolidation sprint, or have engineering stories in the sprint. However, aside to regular stories, these stories should have a well-negotiated purpose and the end.
Backlog cleaning is a weekly meeting. Product backlog cleaning is usually a non-interactive process, where development team uses the backlog as a knowledge base, permanently adding comments and updating story sizes, as they learn more about the product owner’s goals and intent.
There are some companies that disrupt the scrum process, though few and far between. Scrum, or any similar agile process, is a simple and lean process that works for developing software. It also requires complete forgetting of traditional practices and willingness to accept it completely to make it effective.
