Since the Agile transformation at Skyline, we organize in small teams which we call Squads.
We have different types of Squads in the company, each one with different roles and responsibilities. In this post, we will give you an inside look at the Skyline Deploy Squads. And to be more precise, we’ll zoom in on our Deploy Squad—the Scrumbledore Squad—and give you some insights on how we work together, how we organize ourselves, and which solutions we are working on or have worked on in the past.
Roles & responsibilities of a Deploy Squad
As a Deploy Squad, we are responsible for delivering a certain solution to a DataMiner user, keeping in mind our quality standards and aiming to provide the best possible experience from the solution design to the implementation and delivery of the solution. But partnering up with Skyline is more than just receiving a solution though. We want to ensure our users can deliver exceptional services. This includes our software platform DataMiner, but on top of that, it also includes sharing our expertise and experience in digital transformation.
A Deploy Squad is usually composed of a mix of Technical Account Managers (TAM), System Developers (SD), Operation Engineers (OE), and in some cases, a Project Manager (PM). This mix of individuals from different Chapters of Skyline ensures that each Deploy Squad has the necessary skill set to deliver a project from start to finish and overcome any roadblock it might face. However, not every Squad has the same mix of Chapter profiles. And sometimes the composition of the Squad can change depending on the projects we have to deliver. But we try to keep these changes to a minimum as disruptions of a team often have an impact on the team’s stability.
In each Squad, apart from the Chapter responsibilities, some members take on an extra role in order to align with the Agile way of working. These three roles are present in every Squad:
- Product Owner
- Agile Coach
- QX Coach
A Deploy Squad is assigned to a set of users and solutions for which it is responsible. Most times, we have several solution deliveries for different users running at the same time. Therefore, we need to organize ourselves in a way that allows us to deliver value to each one of our users as often as possible. And sometimes this is a real challenge. We need to keep a close eye on our product backlog and make sure we prioritize our tasks considering what is most valuable for our users, and plan accordingly. This is only possible if we hold regular meetings with our users and stakeholders.
Each Squad has a certain freedom to organize itself differently. We’re empowered to choose the most suitable way of working so that we become as efficient and high performing as possible. That’s why we experiment with different approaches and adapt as we see fit to effectively improve our performance. But we also need to adapt to—and take advantage of—the rapidly changing digital environment in which we and our users operate.
Scrum events & bi-weekly sprints
In our Scrumbledore Squad, we hold a set of Scrum events where we sit together to discuss the progress of our work: what did we accomplish, how can we improve and what do we do next. The goal of each event is to increase our transparency, inspect our increment, processes and tools, and adapt.
We work with bi-weekly sprints. This means that we deliver an increment to our users every other week. Every two weeks, we sit together during the sprint planning meeting to align our goals: what we will be working on, how we will do it, and most importantly, how will this next sprint bring value to our users?
In advance of this meeting, the Squad Product Owner organizes our Squad’s product backlog. Their goal is to maximize the value output of the Squad and make clear what should be picked up next by the Development Team. During the meeting, the Development Team agrees on the sprint goal and decides which items in the backlog can be achieved by adding them to the sprint backlog.
Keeping track of our progress
To keep track of what we are working on in each sprint, we use Skyline’s Project Collaboration platform. For each sprint, we create what we call a “bucket”. In this bucket, we describe our sprint goal and we include all the tasks that the Squad agreed to work on during that sprint.
As we work with several solutions, defining a sprint goal is not always easy. However, it’s very important that the goal is well-defined and clear to everyone before the sprint starts. In fact, the sprint goal can be seen as a joint mission: it’s what we want to achieve by the end of the sprint, and we will work together with our Squad members and our users to get there.
We work very closely with our users. And as we’re also in charge of Maintenance & Support contracts for solutions we delivered in the past, sometimes it’s necessary to adjust the tasks in our sprint to address, for instance, an urgent issue in one of our users’ production environments.
To keep track of these changes, we use a second bucket. Here we group the tasks that came in after the sprint planning meeting as these could impact the sprint goal. At the end of the sprint, when we reflect on our achievements, we also consider this second bucket: we discuss how it affected our progress and how we can deal with such situations more effectively in the future in order to avoid a negative impact on our sprint goal.
Every single day of the sprint, we get together for the stand-up meeting where we briefly discuss the following questions: what has been achieved so far? How far have we progressed towards the sprint goal? Are there any roadblocks preventing us from progressing? And if so, how we can deal with them? These daily syncs ensure that every member of the development team is working on the highest priority items, and keep everyone informed on new information that comes in while creating the solution.
Finally, we have a third bucket where we include some tasks that didn’t make the sprint—but which are the next high-priority items in the product backlog—or even some “quick win” items.
So when a member of our Squad has completed their tasks and there’s nothing they can do to assist the other members, then they will start working on the tasks from this bucket. It’s not always possible to do more than we planned, but if we have the room for it, why not?
By using these buckets in Project Collaboration, we ensure transparency towards all stakeholders regarding our progress and we provide insight into our planning for future sprints.
A wide range of expertise
As our Scrumbledore team has been working on many different solutions over the past years, we have a wide range of expertise divided among our members. We’ve been involved in the development of complex solutions using DataMiner standard solutions such as Reports & Dashboards, SRM, and IDP. These projects have helped us to enrich our knowledge on different industry domains, such as:
- Video On Demand performance and capacity monitoring:
- Satellite Downlink Orchestration, event management and service configuration (read the use case)
- Sports Roadkit Orchestration (read the use case)
- Orchestration on IP Studio Productions (read the use case)
Please note that you need to be logged in to access our use cases: in the top corner of the screen, click LOG IN and authenticate yourself with your corporate email address.
As part of a Deploy Squad, every day we have the chance to learn more about the different industry domains and how DataMiner helps our users with their daily activities. At the moment, we’re involved in an exciting new project for sFlow Monitoring, which we hope to be able to share with you as a use case in the near future.
Bringing DataMiner to life with one of our deliveries is quite a rewarding activity, and we’re proud to be part of one of the teams that make it happen.