The deadline is today. A remote development team have worked for several weeks on your software. You obtain the long-awaited access to the system. You check it and you are not satisfied with the achieved results.
All that was needed to avoid this problem is a team with experience in technology and working using SCRUM.
What is SCRUM
Wikipedia defines SCRUM as an agile framework for managing work. It is an approach used in many companies to develop software. Full definition can be found here https://en.wikipedia.org/wiki/Scrum
SCRUM solves most of the problems arising during software development
This is my opinion and many people agree with it. I have been developing commercial projects since 2008. I started as a programmer. Currently, I am supervising high-level projects.
Introduction of the SCRUM method in Droptica solved most of the problems. Which ones exactly?
Here are the most important of them:
- The client was not regularly informed about the progress of works – the client was not satisfied. Sprints, review, backlog refinement – all this compels a constant contact with the client
- The tasks were not thought through before starting them, therefore they took a long time to finish – the client was not satisfied. Backlog refinement and planning – these events ensure that the team has to really ponder on completing each task.
SCRUM saves money
You can ask yourself: how is that possible if you do not know the exact duration and cost of the project at its beginning? The answer can be found in the previous paragraph:
- Regular meetings with the client (Product Owner) force them to think about which tasks are actually needed and which can be rejected.
- Analysis of tasks by the team together with the PO, often allows to come up with better ways to implement or reject them.
SCRUM is often called the art of maximising work not done. You maximise the rejection of the tasks that are unnecessary from the point of view of your business. You do only the things that bring particular value to the system. Everything else goes straight to the waste bin.
Why so many meetings?
Planning the sprint, daily scrum, retro, review, backlog refinement. The list of meetings is long. There is no doubt that they take time. The client often expects to pay for programming, not for conversations and meetings.
I used to think the same way. However, after a test implementation of SCRUM in one of the projects, I have changed my mind. Now I want to develop all our projects – for clients and internal – using SCRUM. I see that it saves great amount of time and money. The same can be confirmed by the clients with whom we now work using SCRUM, while we did not have a specific way of working before.
Abraham Lincoln once said, "If I had eight hours to chop down a tree, I'd spend six sharpening my ax."
The meetings guarantee a good rethinking of tasks, sticking to a common direction and pursuing the same business goals. It is definitely worth it.
How long will it take and how much will it cost?
Every client asks this question at the beginning. It is not easy to answer it. The pace of each programmer is different, there are different working conditions, holidays, leaves, the requirements change (from the client, legal requirements, etc.). A longer project also means a frequently changing specification. Such changes change the cost and time.
Story Points is a solution to the problem. It is a very good tool for estimating the number of tasks that can be performed in a sprint (stage). After just 2-4 sprints you can see the team's average pace. After such a time the team knows the project well, knows the client well and plans for the future. The team can very accurately estimate the tasks waiting in the Backlog. Product Owner, knowing the pace of the team can count the number of sprints and the total cost.
Compared to creating a detailed specification at the beginning of the project, such an approach gives better estimation results.
SCRUM is not enough if the team does not have the experience with the technology
If the team will work using SCRUM, but will not be familiar with the technology, it will not be able to provide good quality software within a reasonable time. Only the combination of SCRUM and the team experienced in using the given technology ensures significant effects. The customer will definitely be satisfied with such a combination.
Why a remote team is better?
What is the difference between a remote team and a local team? Actually – just their location. If you can have a local team, it is worth choosing this option. It will be more convenient.
However, in today's IT market it is difficult to complete a team of 2, 3 or more specialists in a short time for a larger project. That is why you should think about a remote SCRUM team. A team that already has the experience in working with a remote client. By expanding the options to the whole world, you have more choices.
How can I monitor what a team thousands of miles away is doing?
SCRUM has a way to do it: Sprint Burndown Chart. It is a chart that is updated daily. It shows the regular peace of project development. It shows whether the team implements the sprint plan. It is the best tool for monitoring the progress of works. Using Waterfall, you usually find out about delays at the end of a larger stage. With SCRUM, the client can check every day what progress the team has made. They can be sure that the team works and delivers consecutive parts of the software.
How to communicate with the team?
At Droptica we have 3 ways to do that:
- Jira - it is the main communication system; here we have all User Stories and tasks
- Slack - for short text questions, used practically every day
- Skype/Google Hangouts/Zoom - for video calls with screen sharing
These three forms of communication in 100% ensure a very good communication between the team and the Product Owner.
If possible, once in a while, the development team meets with the Product Owner at our office or in the client's office. Our offices are located close to the airport, we eagerly invite our clients to visit them.
How can I check if a remote SCRUM team will work in my case?
If you have a project for a minimum of 2-3 people for a few sprints, a well-conducted SCRUM will provide you with very good results.
If you are not sure if SCRUM will work for you, test it. Order 2-3 sprints and see what results you will get. It is a small cost within the scale of projects taking several months, and such an approach will provide an unambiguous answer to the question of whether it is worth using SCRUM.