Episode 1: Hello SCRUM

Thinking about the fundamentals
Since some of you may be new to agile and/or Scrum, here’s a few tips what to focus on. In my opinion, these are the 
most crucial factors and most relevant elements when thinking about Scrum. This should provide you with some aim and focus, at the beginning as well as throughout your journey. It should give you more insight on top of the basics, such as the Scrum Guide (www.scrum.org) or any other available resources.

It’s important to remember that Scrum and agile overall are about mindset. For example: having team members put in the extra effort, or extra time to cover a colleague’s unplanned absence to meet the sprint goal is a part of that mindset; as is sacrificing the sprint goal to stabilize a working production environment. It’s not necessarily doing everything by the book, but thinking in an agile way to address specific situations. Sure, it’s important to follow the guidelines, especially when beginning with Scrum to build a proper foundation. However, you should remember, that Scrum is only a framework that you should expand on, depending on what your / your team’s / your project’s needs and the circumstances are. Consider this: if a team reports the need for an additional meeting or an alternative way for any of the Scrum ceremonies, which is not aligned with the Scrum principles, but improves the way that the team works… is it ok? I would say, this is exactly the way it should work and only confirms the team’s motivation for further improvement.

The scrum team is the most important piece of the puzzle. Take care of them! The team needs to be built of the right people (not only with technical knowledge, but equally with soft skills). Surely a full-stack squad would be a nice starting point (depending on the product in development) but that’s not often the case. Make sure you have all the needed competences in the team or at least a plan for the team to gain them. Having a team that knows each other and has already worked together is a plus in terms of ramp up time, but it’s not critical; they might need more time to learn to work together. Remember that technical skills are not the bottom line. It occurred to me multiple times, that people with good communication and organizational skills can push the team from good to awesome.

The product owner and the backlog would probably be the second most important piece; mainly because without the PO (representing some stakeholders) there would be no need nor request for a product. I mention both in one point because they are somehow inseparable concepts. The product backlog is a physical representation of the product owner’s vision and goal. It’s crucial to have a fully dedicated, 110% available product owner and that is one of the reasons in my opinion, that the PO has the most difficult role. A good product owner needs time to:

• update the backlog on a daily basis, to cover upcoming and long-term roadmap topics (refinements, groomings)

• cooperate closely with the dev team on current sprint topics

• work closely with other POs (if multiple teams are present)

• communicate with stakeholders to address their demands towards the team and vice-versa.

Scrum ceremonies and principles are good to be followed by the book from the start, because this is the way you and your team can shape your habits and preferences. Use the recommended timeslots and frequencies of sprint planning events, daily stand-ups, backlog refinements, sprint review events and sprint retrospectives. Sometimes it may prove that in order to fit in your 15-minute daily, the team needs to optimize it. Other times it will prove that running a 20-minute daily is the best solution for the team. However always follow common sense, for example don’t run the daily for an hour a day at this point you should reconsider the structure and content of these meetings (overhead) again referring to the scrum guide, which is quite clear in this matter. One thing to add from me, is put pressure on refinements. I can never stress enough how spending your 10% capacity on backlog refinement can save you much time in the future. It’s an investment and that’s why it’s not easy especially having a running sprint to think about what to do next. The truth is, a proper approach to backlog refinement can optimize and shorten your future sprint planning events, help avoid unexpected tasks and impact the stability of the team’s product roadmap.