There are countless approaches that allow a team of developers to develop new software. Over the years of operating at FlowUp, we have verified that the Scrum approach, generally the most popular agile method of software development ever, suits us best. We have written the following article to explain to you why we chose Scrum, how we work within it and what benefits it will bring to you, our clients.
1. Why Scrum?
Here are a few points that highlight the advantages of using Scrum in the development process.
a. Focus on the product value
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.
b. Adaptive to new requirements or changes
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.
c. Level of involvement is up to you
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 wish to remain a more high-level approach, you can assign a product owner to the project or we can fill in that position and discuss your requirements with you separately.
2. Scrum team
In addition to the investor, delivery management and the project board, Scrum's team consists of several other experts who play a crucial role in product development. These include the Product Owner, which you may or may not be you, the Scrum Master and the development team.
Responsibilities:
Product Owner (PO)
define what has to be done
communicate with the other stakeholders
make sure we bring value to the project
Scrum Master (SM)
monitor obeying of the Scrum rules
coach PO, Devs
focus on the team effectivity
eventually, become expendable for the team
Developer (Dev)
develop product
deliver the sprint goal
communicate the risks, problems…
3. Scrum events
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.
a. Daily (Standup)
Meet and sync. Every day. Be efficient.
This event is primarily for the development team. 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 they in many cases are available, so they can react to any blockers in the follow-up discussion.
b. Planning & Refinement
Let's plan what we do next!
Need to change or add something? Want to estimate? Bring. It. On.
These two ceremonies are responsible for making sure the dev team knows what should be done in next iterations and that every piece of the 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 ceremony.
c. Review
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).
d. Retrospective
Shots fired! Take cover!
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 ceremony 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.
4. Scrum artifacts
While Scrum is a very flexible framework, it does use a few proven guidelines and definitions to make it easier for the team to estimate their work. These definitions help the team determine exactly when each task can be considered complete. They are used as a reference throughout the whole development process, therefore it is essential that the whole team is actively involved in their creation.
a. Definition of ready
What needs to be provided and clarified before the team can start working on a task.
b. Definition of done
What needs to be done before a task can be considered, well, done.
c. Estimation flow
Answers the following – how does the team estimate the effort needed to complete a task? Which factors can increase the task's complexity?
Scrum artifacts
Necessary documents for a successful Scrum team. Ready to use examples of DoR, DoD and our own Estimation flow checklist
8 min. read by
5. Delivery management
Each team has its delivery manager that takes care of the delivery process - from choosing the team composition to handling the feedback from the stakeholders and making necessary changes to help the development process. In other words, a delivery manager has to make sure that all the parts are perfectly balanced which makes this process almost like a piece of delicate art.
a. Expectation management events
Let’s see how our cooperation went last month and what we expect to happen in the near future. Above Scrum ceremonies, we periodically sit down with the customer in a monthly check-up (Delivery Meeting) to discuss the overall satisfaction, communicate risks and potential blockers to set the expectations on both sides. It is very important to understand that we are on the same ship and working on a long-lasting partnership.
b. Team composition
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.
c. Allocation
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.
d. Forecasting
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.
e. Reporting
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.
6. Information sharing
Having an appropriate place to share and store information about a project is one of the key things for a successful project.
a. Project mission and vision
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!
b. Knowledge base
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.
c. Communication channels
Transparency, no unnecessary middlemen and being on the same page. There would be two main channels on a specified platform – a team channel and a delivery channel (for the management). As each channel would have a clear purpose, it would help us all stay up to date and on the same page.
7. FAQ
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 actually not a very good approach (considered as 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 man-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 ceremonies? Won’t the team then spend most of their time on their meetings as opposed to delivering the product?
Yes, it is. The implementation itself is – more often than not - just a 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 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 called IBM 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 has several employees who are organized into squads. Each squad is responsible for building and maintaining a specific function of the Spotify app. By taking this approach, Spotify is able to assign each squad their respective tasks without running into the fear that one bad commitment will break the entire platform.
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?
Scrum Board is a comprehensive way of visualising team's progress for both the development team itself 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.
8. Conclusion
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 you get it to your muscle memory, it becomes very natural for you. The long-term benefits will exceed the learning curve and overcoming complex challenges will become a successful systematic process.
