Exploring Five Scrum Myths

Paulo Soto, Hexacta, http://www.hexacta.com/

In the software development world, many still have doubts about Scrum. What is stopping them from using it? This article explores five main Scrum myths that could be holding people back from moving to an Agile approach for software development.

Besides the fact that nowadays most software development companies claim to use some kind of Agile methodology, there are still several common myths and misconceptions about Scrum that we need to debunk, now and forever.

Doing this not only would help the ones already using Scrum to avoid common pitfalls and improve their own Agile management, but it will help more companies to realize their benefits, embrace the change, and join the Agile world.

So, if you or your company still hesitate if Scrum is a good fit for your project, please keep reading aboutt these five myths and you might change your mind!

Myth 1: There is no documentation needed

This is probably the most common myth we have heard, but the reality is that you can have as much documentation as you would like to have or need.

The root of this myth probably comes from making comparisons with more traditional project executions where huge and "carved in stone" documents are created in a separate phase of the project. But having little upfront documentation does not mean that it can or should be skipped at all when doing Scrum!

During any development activity, documentation works as a roadmap, specifying what the final product will have and keeping everyone aligned with the same vision.

The reality is that Agile produces documentation, but it is different. The increased collaboration environment that an Agile project claims to encourage could reduce the need for some design documents. Instead of those fixed and lengthy requirements, you have a living product backlog, a collection of user stories that are actively updated and prioritized.

Finally, if a specific document is relevant and important for you, which means it brings you value, then it should be treated just as any other deliverable at your project, so it must be scheduled and developed as you do with the code.

Myth 2: There is no planning needed

Planning is essential in Scrum projects and in Agile project management. But again, the difference in a traditional methodology lies in timing. While using a traditional approach (Waterfall), planning is something that occurs once at the very beginning, but in Agile planning, it is an ongoing activity, something continuous that is spread throughout the whole development cycle.

At the beginning of each iteration, you have the Sprint Planning meeting where the team agrees on the requirements that will be delivered at the end of that phase. The more underlying information you have, and the more you understand the final product, the better you can refine your original requirements, estimates, and priorities.
Another difference is that planning requires more involvement on the part of the team, rather than having a single individual do it all.

Myth 3: There is no design needed

This is another "no" myth, which is probably as common as it is false. In order to practice Scrum, or any Agile methodology, you will need to design even more. The big difference is that you do not have to specify a big up-front design, which delays the actual beginning of the development, and that is no longer valid as soon as the first lines of code are written.

With Scrum, the design is omnipresent instead of being something that only happens when the project starts. Of course, doing a lightweight functional design when the project begins can be useful and could help us to avoid some risks. However, what needs to be avoided is trying to create a very exhaustive and final design that should guide the rest of the project, as that narrows or even obstructs the possibilities to adapt and change during the following Sprints.

Myth 4: Scrum is chaotic

Scrum encourages self-organization, and that is probably the reason why people may think that it means less discipline. But let me tell you something, if team members are doing what they want, when they want, and selecting the tasks they prefer to do, then you are doing it wrong.

Scrum is a framework, which clearly describes roles, principles, and practices. There is a Product Owner who should decide what the most important items from the backlog to be implemented are. There is also a set of time-boxed events, such as Sprint Planning, Daily Standup, or Sprint Review meetings, which requires well-disciplined teams in order to do it correctly. So, by no means is Scrum a synonym of chaos.

This might be interesting: Say no more "Buts" and stop asking yourself why Scrum is not working.

Myth 5: We cannot do Scrum... we are too "special"

"This is not the right time for us to do Scrum, but for our next project..." or "I love the idea of Scrum but our project/company is too [complete with any justification you like]...". I am pretty sure those are some excuses we all have heard at least once. Do you identify with any of them?

There are still many companies who think that their projects are somehow different or special and that Scrum won"t fit for them. They like the idea of developing with Scrum, not for the present but for the moment they find the right opportunity.

Do you have a Brownfield project where something has already been implemented? Then Scrum is for you. Do you have a Greenfield project where everything needs to be done from scratch? Perfect! You can also do it with Scrum.

The reality is that most of the time we look for excuses to avoid changing the way we have been doing things in the past.

Conclusion

In the software development world, many still have doubts about leaning towards Scrum, and that might be holding back their own growth. We have reviewed the most common misunderstanding that we usually hear from companies that are still skeptical about developing with Scrum.

The good news is that now you know a little bit more about what is true and what is not when we talk about Agile management with Scrum methodology. We are sure you will make the right decisions next time you have to choose to implement it or not.

This article was originally published on http://www.hexacta.com/2017/08/14/Agile-management-5-scrum-myths-to-see-closely and is reproduced with permission from Hexacta.

Related software development articles

The Secret Sauce of Delivering Scrum Projects

Scrum Roles - an Unsolvable Puzzle?

Agile Scrum Sprint Length: What is Right for You?

Click here to view the complete list of Methods & Tools articles

This article was published in September 2017