Applying Scrum for non-IT none techincal teams

Although Scrum had been in existence long before 2001, Jeff Sutherland and Ken Schwaber were the two individuals who pioneered and championed the adoption of Scrum in software development. This article will explain the Scrum framework in the context of non-IT software teams and as such it aims at a non-technical audience.

I often get asked: ‘Femi, what exactly is Scrum and how can less technical employees apply such a successful framework to their teams in order to experience the same level task completion, teamwork and collaborative culture with Scrum that is often associated with IT software teams?’ Before I provide an overview of the Scrum framework, its team structure and values, it is important that we all understand that Scrum by itself does not guarantee strategic advantage over competitors or an increase in business revenue: if Blackberry as an organisation decides to reinvent itself and adopt Scrum as a way of working, their market share will not improve no matter how many Scrum teams they assemble, because their product itself cannot keep up with Apple and Samsung. Scrum, in itself, is not the objective, but a means to an end – a way of working that enables teams to operate effectively as a collaborative unit in order to get things done quickly and efficiently. The next logical question, then, is: what exactly is Scrum?

The origin of the term Scrum was borrowed from the sport of rugby. Scrum is an iterative approach to planning and execution of tasks by individuals within a team with the main objective of creating value to the end customer. These iterations allow the team to respond to internal and external changes that impact the objectives of the team. Scrum encourages a structure that allows for collective decision making across the team, while also ensuring that everyone on the team has a voice and that this voice is heard and appreciated. There are 3 roles within the Scrum team in the context of non-IT teams:

  • Product owner (C-level Executive or Director)
  • Scrum master (Agile Coach or Team Leader)
  • Team member (Marketing, Sales or Human Resources)

The C-level executive creates a prioritized task list which highlights what needs to be done from a strategic level. Working with everyone one on the team, the product owner is then responsible for the strategic level planning in terms of the setting of the objectives and key results for the fiscal year, with a full breakdown of deliverables per quarter. He/She is also responsible for prioritizing the goals for each quarter and sprint. I am sure you are now wondering what I mean by sprints?

Scrum teams break down their work into chunks (or batches) of processes, lasting between 2 to 4 weeks, which allows the team to deliver value at the end of each iteration (chunk or batch). These chunks or batches are called sprints. At the start of the sprint the team gets together to understand what is required from the team. For each sprint, the team take the top priority goal from the quarterly plan and collectively work together to this shared goal. Breaking the work into sprints encourages regular review of tasks completed by the team during the sprint and everyone can collectively decide on important changes required for the next iteration (sprint).

The Scrum master (Agile Coach or team leader) is then tasked with making sure any issues or hindrances causing delays in task completion are removed. Team members don’t have to worry about fixing issues with their work as they rely on the team leader to make sure they have everything they need. A team cannot adopt Scrum by themselves: hiring a Scrum master is a crucial component, as this is the person that will help the team to start the Scrum adoption process. The Scrum master must use active listening and powerful questions to help the team in the Scrum adoption journey. Successful adoption of Scrum is dependant on hiring a qualified and skilled Scrum master. According to Kathy Harman, most companies that fail in adopting Scrum or Agile do so because they hired an incompetent Scrum master who is unable to coach the team towards successfully adopting the Scrum framework. These teams end up not being able to become high performing.

During the sprint the team performs daily meetings which last for 15 minutes and everyone on the team discusses what they have completed and what they are currently working on: this promotes a culture of transparency and trust because everyone on the team is informed about what’s going on within the team. The focus of these meetings is on visualizing the work of the team and voicing any hindrances of external dependencies that might be blocking team members from completing their tasks. Another positive of Scrum is that it also encourages regular face to face communication between team members, because the ethos of the team centres around a culture of failing together and learning which eliminates the culture of blame and finger pointing.

This article is not an exhaustive overview of the Scrum framework and some other questions you might want to consider in your quest to know more might include:

  1. How does the team self-educate themselves about pre-Scrum adoption?
  2. What are the reading materials and trainings available to equip leaders and teams for adopting the Scrum framework?

https://www.scrumalliance.org/

https://www.scrum.org/

The links above will take you to Scrum training and certification organisations, but please be aware that the Scrum training provided by these organisations is specifically tailored to software teams and might not be the best option for non-IT teams.

The main essence of Scrum is focused on reducing risk by continuously listening to feedback from the customers and making adjustments that ensure customer satisfaction is the primary objective of all team efforts. For marketing teams interested in books and online resources that can help you understand more about Scrum, you can find out more in my other blog posts.