How our team runs Scrum

There are countless ways for a team to build new software. Over our years at FlowUp we have found that Scrum, the most widely used agile framework, suits us best. This article explains why we chose Scrum, how we work within it and what it brings to you, our clients.

Here are a few points that highlight the advantages of using Scrum in the development process.

In Scrum, the team focuses on delivering the product through multiple iterations, so-called sprints. In each sprint, an increment is added to the product and demonstrated at the end of the sprint. The team sees the main goal and the scope of each sprint before its start and is able to evaluate how much they can commit to. This ensures that with each sprint, you are able to see the product taking shape and adding value to your business.

Scrum is an agile process that enables a high level of flexibility. This means that you as a stakeholder can change the issue priorities before each sprint if you feel that it would increase the value of your product as well as modify already existing features. This is somewhat different from the non-agile development where everything is specified and planned beforehand and each modification or new requirement can cause major issues in meeting the fixed deadlines and uncertainty of how much the team can deliver.

As a stakeholder in a Scrum project, you will have the chance to choose your level of involvement in the process. If you want to be a part of the team, you are welcome to be. You would fill the role of a Product Owner who specifies tasks, introduces them to the team and makes sure everything is clear before the team starts working on them. If you would rather stay at a higher level, you can assign a Product Owner to the project, or we can fill that position and discuss your requirements with you separately.

In addition to the investor, delivery management and the project board, the Scrum team consists of several other experts who play a crucial role in product development. These include the Product Owner, who may or may not be you, the Scrum Master and the Developers.

Responsibilities:

• define what has to be done

• communicate with the other stakeholders

• make sure we bring value to the project

• make sure the team follows Scrum

• coach PO, Devs

• focus on the team’s effectiveness

• eventually, make themselves redundant

• develop product

• deliver the sprint goal

• communicate risks and problems early

There are prescribed events used in Scrum to create regularity and to minimise the need for meetings that are not defined in Scrum. All events are time-boxed. Once a Sprint begins, its duration is fixed. All events aim to be as effective as possible and they may be ended whenever their purpose has been achieved.

Meet and sync. Every day. Be efficient.

This event is primarily for the Developers. They should share their progress, blockers, findings and everything that prevents them from achieving common goals. The Product Owner does not need to be present, but in many cases they are available, so they can react to any blockers in the follow-up discussion.

Let’s plan what we do next!

Need to change or add something? Want to estimate? Let’s talk it through.

These two events make sure the Developers know what should be done in the next iterations and that every piece of work is well defined and understood.

They are usually two separate events, but in many cases (mostly in smaller teams) they are held together in one session.

Let’s have a look at the increment!

The Sprint Review is an event led by the Scrum Master in cooperation with the Product Owner to evaluate the sprint, validate the sprint goals and have a look at the statistics (if already available).

Time to learn from the sprint we just finished.

Time to discuss what we did well and what we want to avoid doing next time! Outputs of this meeting are SMART action points. This event is the engine of change for the team. Anyone can be open here and give constructive feedback with the emphasis on suggesting action points instead of focusing too much on the problem itself.

The Scrum Guide defines three artefacts: the Product Backlog, the Sprint Backlog and the Increment. On top of those, our teams keep three documents of their own. They make it easier to estimate work and to determine exactly when each task can be considered complete. They are used as a reference throughout the whole development process, so it is essential that the whole team is actively involved in their creation.

What needs to be provided and clarified before the team can start working on a task.

What needs to be done before a task can be considered, well, done.

Answers two questions: how does the team estimate the effort needed to complete a task, and which factors can increase its complexity?

Each team has a delivery manager who takes care of the delivery process, from choosing the team composition to handling feedback from stakeholders and making the changes needed to keep development on track. In other words, a delivery manager has to make sure that all the parts stay perfectly balanced, which makes the job a delicate balancing act.

Let’s see how our cooperation went last month and what we expect to happen in the near future. In addition to the Scrum events, we periodically sit down with the customer in a monthly check-up (Delivery Meeting) to discuss overall satisfaction and to communicate risks and potential blockers, so that expectations are set on both sides. It is very important to understand that we are in the same boat and working on a long-lasting partnership.

Choosing the right people to get the job done ensures that things will go smoothly. We are going to help you with this by suggesting the best team composition.

To make sure there is always enough work for everyone, we need to take team allocations into account. In order to do this properly, we can accept changes if they are proposed at least a month in advance. We will, however, try to react to these change proposals in the fastest manner possible.

We have gone a long way since the times of the Oracle of Delphi. Today, we have way more effective ways of collecting relevant data. In Scrum, we use team velocity based on story points. Thanks to that, we are able to forecast the amount of work that will get done in a specific sprint.

At the end of the day, all work done needs to be reported. We prefer to report on a “per-sprint” basis, so you can expect to get your report with the same periodicity. There is some basic info that should be contained in each report. On top of that, we can surely agree on some cooperation-specific metrics that will be used in our delivery process.

Having an appropriate place to share and store information about a project is one of the key things for a successful project.

There’s no better way to make the team members motivated than sharing your own vision of the product you want to build with them!

Every team member, including the customer, should know where to find the necessary information and answers. This means that everything from project documentation, UI designs, workshop materials to team composition or calendar events is accessible for the whole team.

Transparency, no unnecessary middlemen and being on the same page. There are two main channels on the agreed platform: a team channel and a delivery channel for management. As each channel has a clear purpose, it helps us all stay up to date and on the same page.

What are Story Points and why do you use them as a unit for measuring complexity?

• Story Points measure effort. While a time spent on a task may be different depending on who works on it, the effort (in relation to what needs to be done) remains the same. This enables the team to agree on an estimation while giving us some information about how many such issues can fit into a sprint.

Can your team estimate in time intervals (hours, days) instead of the abstract Story Points?

• Estimating in time is not a good approach and is generally considered bad practice, because the story point is our primary unit of complexity measurement. However, as time goes, we will have enough data for you to possibly calculate how many story points we complete throughout the whole sprint. Through this calculation, you are most likely to find out how many story points are delivered on average during one person-day.

Will I have to pay for the Scrum Master, even though he does not directly deliver anything? If so, how much?

• The Scrum Master’s rate is included in the team’s hourly rate, as the Scrum Master is always present in the team and helps them deliver more efficiently. You can find more information about the Scrum Master’s role in the text above.

What is your response time? (If I ask the team something, how long should I expect to wait for an answer?)

• Typically, if not stated otherwise (for example in the SLA), the response time should be on the next business day. In practice, this means that your requirement or question will get addressed on the next working day, at worst. Do not mistake this for having any of your issues solved on the next day!

I came up with this cool new idea! Can we start working on it right away?

• Yes. But only if you wish to end the sprint prematurely. The scope of the sprint should be locked throughout the whole process, with the only possible exception being severe and critical bugs. With that being said, it is not the end of the world if the sprint has to be ended prematurely, but only if it happens under well-reasoned circumstances.

Is it really necessary to have all these events? Won’t the team then spend most of their time in meetings as opposed to delivering the product?

• Yes, it is. The implementation itself is, more often than not, just the final piece of the puzzle from the developer’s perspective. All the architectural and technical decisions made prior to the coding itself are the things that make a difference and affect the outcome. In order to make the best decisions, the team needs to have enough space to discuss all the important things beforehand.

Where can I find some information about successful agile driven projects?

• There are plenty of success stories that we can take an example from. To mention a few (source):

Google

• Google has multiple applications such as Gmail, Google Maps, Google Calendar, Google Assistant, to name a few. All these apps require frequent updates that need to be tested extensively before they are rolled out to users.

• One big example is how Google builds and improves on its Android OS. It allows users to participate in a beta program by using a functioning Android OS. Gradually, one feature or a set of them are released to beta testers, and if feedback reports indicate several bugs or major issues with usability, the update is rolled back.

IBM

• Agile Scrum played a huge role in improving IBM’s business operations so much that it offers its own management software that incorporates an agile development environment, now called IBM Engineering Workflow Management and originally released as Rational Team Concert.

• The end result was that IBM witnessed improvements across the board, in metrics such as on-time delivery, defect backlog, beta defects fixed before GA, maintenance and innovation.

Spotify

• Spotify organised its engineers into squads, each responsible for building and maintaining a specific function of the Spotify app, so that one bad commitment could not break the entire platform. Spotify itself has since moved away from that model, which is a useful reminder that the point is to keep adapting the framework to your own context rather than to copy someone else’s structure.

How often can I go and see for myself what the product is like, up to date?

• After each sprint has ended, there will be a demo with the latest features and changes which you can attend. Additionally, there will be a release plan in place where depending on who is in charge of releasing the application, we would agree on a frequency for regular minor releases of the newest changes as well as major releases of new versions of the product on the market.

There is a bug. Who is going to pay for the fix?

• In agile development, the nature of the thing the team is working on is irrelevant. In other words, it is handled as any other work that is supposed to be done.

I’ve encountered Scrum before, but your team works a little differently than I’m used to. Why is that?

• This is not unusual. Scrum is only a framework that helps you set a few ground rules so that you don’t have to reinvent the wheel. It is perfectly normal to adjust some parts of it to align with your specific needs. At FlowUp, we have several Scrum teams, each implementing software for a different type of customer, so it is natural that each team works a bit differently.

What is a Scrum Board?

• The Scrum Board is a comprehensive way of visualising the team’s progress for both the Developers themselves and the other interested parties. On this board, you can clearly see which tasks are currently being worked on, as well as those that are already done and a set of tasks in a backlog, on which the team is going to work next. At FlowUp, we most often use GitHub and Jira for managing our project boards.

Why is nothing on the board moving?

• There are a few possible answers to this one, depending on the situation.

• If the tasks are of a bigger size, they can take days to complete. If a task gets too big though, it should be split into sub-tasks for better progress visibility.

• If the team has a lower allocation on the project, the board moves accordingly.

• To dive into one common example, if there are issues in the “Review” or “Testing” column at the end of the sprint, they become a priority for the team to finish so that they can show the results at the demo.

• One thing that you can do to help us is to prioritise the most pressing tasks before the team starts working on them so that they know to focus on those first.

Agility in the development process is a very powerful tool when used right. We decided to follow the Scrum framework closely because it helps us to deliver the best value to the customer and ensures the process in place fulfils this purpose. Although teams (and customers) have a learning curve and it takes time to perfect, the result is worth the invested energy. You can think of this as a sport: once it is in your muscle memory, it becomes completely natural. The long-term benefits will exceed the learning curve and overcoming complex challenges will become a successful systematic process.