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.
If you are wondering how to implement Agile into the development of your IT products contact us:
Read more about our solutions
Have you ever wondered why Scrum? What’s the overall reason behind Scrum and Agile becoming a trend in product delivery, and a popular way of working? Why are so many companies, big and small, starting to focus more and more on a completely different approach to not only create products but to change their whole organizational culture? Let’s give that a thought…
So, you have now decided to give Scrum a try. You have identified a business opportunity and you have a vague product vision that will allow you to seize that opportunity if acted upon within a defined time period. How to proceed from that point on? What steps should be taken into account when facing that challenge?
One question regarding Scrum that comes up quite often, whether it’s during an academic discussion with my “colleagues from the industry” or just some theoretical pondering of my own, is: if you had to eliminate 1 Scrum event – which one would it be?
Obviously, once you are confident with having a proper Scrum Team in an agile environment, you might want to take it further and expand – and why wouldn’t you? Scaling your Scrum setup can help you get more stuff done and at the same time enforce the agile culture in your project and organization.
A common question that any manager or executive might ask (or be asked for that matter) is: “How well is the team doing?”. That’s a fair question which leads us to the 3rd pillar of Scrum: Transparency.