Agile software development and Scrum in particular can be difficult to understand and adopt for those accustomed to traditional software development, namely Waterfall. Simpler hierarchy, the situation in which a team has to manage itself, constant change and estimation points often make the switch to Scrum harder than it should be.

On top of that, understanding Scrum and implementing it within an organization can present a challenge for many people doing the big jump. Simply said, practice and theory often misalign.

Here are some tips to help you on your road towards better agility!


Sprint Retrospective – you DO NOT want to skip it!!!

Three main pillars of Scrum are transparency, inspection, adaptation. Throughout many years working with Scrum in Atlantbh, we have found that the ability to make quality inspection of your processes is essential. Retrospective onto what has been done right, what could use some improvement and which processes and behaviors should be abandoned is invaluable for the overall Scrum process.

Important thing to note at Sprint Retrospectives is not to deal with the symptoms of the problems you are having, but rather root causes, and to make sure your team has the action plan to tackle the issues identified during the Retrospectives.

In Atlantbh we are following an interesting format for Retrospectives in which we encourage our team members to always start their opinions with a positive statement. That format consists of “I LIKE” and “I WISH” columns. So, instead of saying “I don’t like having planning in the morning”, we use something like: “I wish we had planning after lunch.”

Build trust within your team – give new team members more space

Let me start this tip by being a bit cheesy. I’d like to quote a show I have been watching recently “Agents of S.H.I.E.L.D.”: “A team that trusts is a team that triumphs”. This saying couldn’t be more true for Scrum. Trust within a team is one of the most important factors towards success. Your agile processes don’t depend only on your senior team members. In essence, a seniority of team member should just be an opportunity for a junior member to learn from their experienced colleague. Empower your junior team members by giving them more space to grow. Encourage them to review pull requests in detail, let them do presentations on Sprint Reviews. Trust your team members equally. A team that builds trust builds better software, better understanding and adds exponentially to team’s cross-functionality.

Best Scrum Master is the one “not needed”

Now…before you start attacking me, I did put the not needed under quotation marks for a reason. To grasp this tip lets go back to the very definition of a Scrum team. Scrum team is self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. I know Scrum master is a part of the Scrum team, but having a team of developers who are in sync, well trained and accustomed to Scrum processes, meetings and artifacts is a goal to aspire to. And this is where our third point comes from, a team not regularly in need of a Scrum master is a team that has a great Scrum master. That team has adopted and perfected Scrum!

Laptops and phones are enemies of Scrum!

As IT professionals, we are all attached and dependent on our devices. After all, our work is done using those same devices. However, Scrum meetings should be as device free as possible. Let’s get into more details here. Scrum meetings should be about sharing opinions, syncing up, giving feedback, and in general participating. It is crucial to express yourself during these meetings, but what’s more crucial is being able to listen to your teammates, understand their point of view and spend as much time listening to their opinion as you would like them to spend listening to yours.

All team members should focus their attention toward the discussion being held, thus reducing the device usage to minimum. Even if a team member is not assigned to a certain ticket, understanding the work needed to be done and how it’s related to their own tasks is crucial.

REMEMBER Agile is about INDIVIDUALS AND INTERACTIONS over processes and tools!

Make sure your daily stand-ups add value

  1. What did u do yesterday?
  2. What will you do today?
  3. Is there anything impeding your progress?

The three questions we often go beyond. The fact is that anything other than these three questions add little to no value to the meeting. Daily stand-ups are not about the details, not about solutions and certainly not about discussions. Daily stand-ups are about syncing up and getting the team on the same page.

Make sure you don’t break the time limit. Stand up, it helps you focus. Sync up with your team members, not with product owners or a Scrum master. Your team members are those you work with and they need to know where you’re at as much as you need to know where they’re at in terms of progress and tasks they’re working on.

If you really want things discussed in detail, you can do it at the Parking lot meeting. It’s basically a post daily Scrum meeting where we sort out details regarding certain tasks or misunderstanding between certain members. Separate your daily Scrum and Parking lot meetings. They are not the same. Make daily standups concise and to the point, but parking lots detailed and comprehensive.


Scrum is definitely more than some 5 tips read on some website, but we do sincerely hope that these 5 tips helped you better understand Scrum in practice. We’ve spent years working using Scrum and we would be more than happy to hear your opinions and ideas on this topic. Is there something you would like to add, or something you do not agree with? Let us know in the comments below.

Stay agile our friends!!

Want to discuss this in relation to your project? Get in touch:

Leave a Reply