Are you really doing Scrum? Many teams in the software development industry might be wondering why Scrum doesn’t work for their projects. These are some key factors that any Scrum team can‘t avoid if they want to succeed.
Even though many software development companies say they work with agile methodologies –Scrum in particular– some teams ask to themselves “WhyScrum doesn’t work for my team?”. Our question is: Are they really doing Scrum?
In a methodology that has few principles and rules, failing to follow just a handful of them means that you are not complying with a big part of the whole Scrum framework. That will obviously carry some penalties in the result you get.
The widely discussed benefits of Agile product development are sometimes overshadowed by some practices that have a negative effect when it comes to realizing Scrum’s full potential. Usually called “ScrumButs”, these bad practices are the excuses or fake shortcuts for not complying with the proposed methodology. The truth is that many teams think that they are using Scrum but they are really skipping many of the steps that Scrum requires, leaving an open door for ineffective and unproductive processes.
If you are asking yourself why scrum doesn’t work properly for your team, here are 5 keys you can’t avoid in your Scrum process. If you don’t want to fail in the methodology, we recommend not to overlook these items in your daily development process. (This might also be interesting: Software solutions design: Going beyond the obvious).
1. Accomplish the Scrum ceremonies… ¡Yes, all of them!
In the Agile world, rules and meetings are simplified to the extreme in order to optimize the team’s time and processes. The main ceremonies (Sprint Planning, Daily, Review and Retrospective) should never be missed.
It is important to keep in mind that each ceremony has its own objectives, so skipping any of them may put in danger the results of the project. “Without any doubt, one of the main reasons why scrum doesn’t work, sometimes lies on the correct execution of these ceremonies. They are an essential part of the Agile development. Thanks to them, we are able to empower the team and correctly implement the Scrum methodology”, says Pablo Pecora, manager at Hexacta and Scrum Coach.
“Scrum is a lightweight methodology, prescriptive (established) and with so few rules and processes. Those few steps or ceremonies were designed to coexist harmoniously among them so that missing any of these ceremonies means a failure to comply with much of the methodology”, emphasizes Pecora.
2. Respect the Time Boxing
Time Boxing is one of the most important concepts to be followed in every ritual of Scrum’s methodology. This technique, which determines maximum times for each ceremony (meeting) helps teams to prioritize objectives, tasks and decision making.
Respect each ceremony’s timing, boost direct an opportune communication among team members (including the product owner), as well as their empowerment to achieve the goals and stay focused on the objectives. (Read more: Communication in agile software development… does it matter?).
“Not complying with the established time guidelines for each activity puts the methodology’s effectiveness at risk, turning it boring, bureaucratic and eventually inefficient. In Scrum everything it is about fluency, so it is not surprising that meetings have a set time for them to develop satisfactorily in that period and they shouldn’t last longer than that”, says Pecora. “This time limitation –he ended– facilitates team work, optimizes time and minimizes inefficient tasks”.
3. Do not skip the estimation with Story Points
Yes, Story Points. That arbitrary unit of measure that the teams used to estimate of the effort (amount of work, complexity, risks and unknowns) required for implementing a User Story.
“We think that this is one of the keys for working the right way. The Story Points will let the team estimate the velocity, a measure of the amount of work a team can tackle during a Sprint. Sometimes going straight to estimating in hours (a practice that usually and incorrectly replaces the usage of Story Points) tend to fail and blur the team capacity for future sprints”, add Pecora.
In this context, if you are asking yourself why scrum doesn’t work, the answer might be in the Story Points. These are one of the keys in this methodology because “they allow us to see the velocity that as a team –not individually– we own and therefore we can estimate how far we can go in every Sprint so we can achieve all requirements on time”, the Manager comments.
It is important to highlight that Story Points provide an indication of the amount of work, but it is not always connected or related with the time it takes to accomplish the work. “Story Points don’t have an absolute mapping with the duration of each task. What they really do is measuring the effort of the team, effort that in reality can use a variable amount of hours”.
4. Put the Planning Poker in a higher place
Having understood the importance of Story Points in optimizing the Scrum methodology, it is necessary to position Planning Poker in a higher place. Being aware that this is the starting point for estimating any software project is a mantra that Scrum methodology cannot leave aside.
And, what makes Planning Poker such an important technique? Here some aspects:
- It is based on consensus and time is not defined arbitrarily: in the agile world there is no place for independent work. Here it is not about one person who estimates. The Story Points lead the team to comply with each user story but all members participate. Only when there is an agreement, the estimation is accomplished. In summary, the task duration is not established arbitrarily.
- Generates a constructive debate: given its very nature, Planning Poker is a time for constructive discussion. If some people on the team have very opposite estimates, this is an opportunity to listen the different points of view and debate.
- Helps identify risks: as everyone’s opinion is heard, Planning Poker helps to detect potential risks and take into account unforeseen aspects of a task to begin working on them from the get go, thus preventing them from becoming impediments.
- There is direct communication with the client: Planning Poker is the scenario where the development team asks all the necessary questions to the product owner. Only when each feature has been fully analyzed and the requirements and needs are clear, the estimation process begins.
5. Make sure the retrospective meetings generate an impact
The retrospectives are the Agile culture in action: The team focused on discussing the processes, how to improve them and feeling the empowerment to do all the changes they think are correct in order to add value to their work.
The retro meetings have a clear objective: to review the project’s progress and learn from both successes and failures to improve. It is a time when team’s members review and discuss how they are working and how to be more efficient. But how can these generate a real impact?
- Ensure that at the end of the meeting the team has established concrete actions. When plans and new ideas are left in ideas and are not executed, the team loses motivation and it creates the feeling that changes never happen. Let’s do an action planning!
- This meeting is also an opportunity for brainstorming. The Scrum master should embrace this process.
- Innovate! Make sure the retro is different, fun and attractive for everyone. Use techniques that allow you to innovate and keep the group focused and working together.
To Sum Up
Scrum is a methodology which success depends on putting into practice certain good practices. Keeping these practices is key in order to make the most out of Scrum.
If you are wondering why Scrum doesn’t work, these 5 keys you can’t avoid in your Scrum process are just a stepping stone to what agile teams might become when taking this methodology to another level.
Do you know any other advice to improve the way teams implement Scrum?
Comments? Contact us for further information about how we can help your business. We’ll quickly get back to you.Go Back