How to Adapt Technical and Non-Technical Teams to Scrum and Agile

This is a guest blog post written by our Scrum Master, member of our QA team, who wishes to stay anonymous. In this post, he is going to share the main processes you should be aware of when putting together a Scrum and Agile implementation plan.

At SpamExperts we are currently experimenting with the Scrum framework. We are testing various approaches and different types of Agile based frameworks to find the one that suits us best and make our work more efficient and smart. Eventually, our aim is to cover the needs of our customers, offer them top notch quality and the best experience on the market.

What should you know about Agile?

Agile is a software development framework which refers to a group of iterative development methodologies, where solutions and requirements grow together, through self-organizing cross-functional teams.

Agile, as a framework, promotes disciplined project management through its methods and processes. This means that the project management must promote and encourage:

Frequent inspection

Constant adaptation

Teamwork

Self-organization

Accountability

These, together with a set of best practices, allow high-quality software, rapid-delivery and a business model that aligns customer needs with company goals.

What do you need to know about Scrum?

Scrum is an Agile framework subset that allows the efficient completion of complex projects. Scrum was originally built and formalized for software development projects, however it is not limited to this, since it works well on any complex, innovative project or scope of work. The Scrum framework is quite simple.

What are the roles in Scrum?

Product Owner – This should be a person with authority, availability and, most of all, vision. The PO’s responsibilities revolve around communicating the vision and priorities to the development team. However, the Product Owner must always step back from micro-managing the teams. The main reason to step back from micromanagement is because Scrum values self-organization. One of the key responsibilities a Product Owner must fulfill is answer questions from the team.

The Scrum Master– This is a facilitator by definition, for the Product Owner and for the team. Keep this in mind though, the Scrum Master is not a manager. The Scrum master’s responsibility is to remove impediments that are hindering the team’s evolution in achieving sprint target. If this is done properly, the team is greatly helped. Thus the creativity and productivity are maintained at high values and everything is clearly visible to the Product Owner. Another responsibility of a Scrum Master is to work with the Product Owner and advise on how a team can maximize its ROI.

The Team – The development team is responsible for its own self-organization. The typical team is formed by software engineers, analysts, QA experts and UI designers. The optimal number of team members is 7, while the Scrum Guide mentions that the number can range from 3 to 9 members. The team always has autonomy and the responsibility to meet the goals of the sprint, and establish how it will be accomplished.

Sprint Planning – during this meeting, teams pull tickets or tasks from the top of the product backlog and create a sprint backlog. The team then decides how the sprint backlog will be implemented.

The sprint– a time span of usually two to four weeks in which all team members work together to complete the sprint backlog. Along the way, the Scrum Master works to keep the team focused on target.

Daily Meetings (or Daily Scrum) – during a sprint, the team meets for 5 to 15 minutes every day and assess the progress, and underline the blockers if any exist.

The sprint ends with a sprint review and retrospective meetings.

This cycle repeats until the deadline is reached, or enough items in the backlog have been completed and released.

Scrum ensures that the most valuable work has been done by the end of a project.

Ken Schwaber and Jeff Sutherland have built The Scrum Guide to explain this framework clearly.

Scrum Inc. CEO Dr. Jeff Sutherland said that, although Scrum was initially created to help technical teams release products of high quality efficiently, it can actually be used to improve work output in any team or profession.

To make sure that Scrum properly scales and adapts to your organization, key features must be taken into consideration:

Understand the bigger picture of the importance of tasks

Scrum teaches us that complex projects must be split into smaller, manageable tasks. This forces you to think about specific needs that should be fulfilled to reach a goal and it also encourages the revision of those specific needs. The end goals should always be in everyone’s mind but the necessary steps to achieve them are the main focus.

Keeping tabs on the team

Scrum will always encourage transparency but will never encourage micromanagement. The team needs to know what you are doing but it is up to you to complete your work just as you want it. The concept of “boss” in a Scrum team does not exist, although Product Owners are held accountable for the finished product. The rule is simple in the end: Scrum encourages autonomy within a team.

The Sprint length

Since Scrum is an iterative based framework, development teams go for sprints that last one to two weeks long. Because this is a feature that needs to be implemented in non-technical teams, the duration of a sprint may vary. While the sprint can obviously be shorter or longer, you should be careful though and not incorporate too much time between sprints, as the team loses their sense of urgency.

The deliverable you are working on

In software development this is a simple step, however in sales, marketing or financial teams it will be a bit difficult. It tends to be more difficult because it is harder to define a product, deliverable or project. The Goal here is to determine what the team is exactly working on and what their results will be.

Functionalities mandatory to complete a sprint

Warning note: it can be quite difficult to get all the necessary people to accomplish a meaningful increment onto one team, nevertheless it is possible. To translate this into more meaningful words, the equivalent to developers, testers and other members, as well as their functions, must be translated to your non-technical teams.

Equality

For Scrum applied in software development no team member is more important than the other. This means that developers are above QA, just like QAs are above developers in terms of importance; and this applies to all team members. Everyone is equal and there is no boss. This is very important because the Product Owner, while accountable for a product, should never micromanage the teams.

I’ve heard the question before: “So, if I have person in my team who is a bit rude but they have a ton of experience, why shouldn’t I listen to their advice?”

People are not yet perfect. Harmony and equality must always be maintained in the team, no matter what. Even experienced team members can make mistakes. If you only consider their opinion, this will affect the rest and create disadvantages, delays and problems.

According to Scrum.org – “A hyper-productive (but rude) member may destroy a team’s integrity.”

It can also negatively impact the productivity. So keep these in mind when implementing Scrum in any type of team.

Implementing Scrum is not always simple. How open is your organization to change? We’d love to hear your feedback in the comments!