As we follow the precepts of Agile Software Development, the client’s satisfaction is the highest priority for us (right after quality). This approach also allows us to be more flexible and much more effective than the waterfall development model.
Using Agile, we are open to changing requirements, no matter how advanced the development process. Since we work in short time intervals, or Sprints, we provide our clients with first results much faster. This iterative approach allows for and encourages adjusting project course on the go, so we don’t have to spend time creating hefty, 500-page-long specifications, but if we had to, all the required info would be clear and up to date.
Scrum, an Agile Software Development methodology, focuses on solving the most common problems of software development: long development cycles and the difficulty of fulfilling the product’s business expectations within the given constraints. It also facilitates progress when the client is undecided as to what should the final result of the work be or when they need to change their priorities due to shifting market realities or investor demands.
Scrum allows everyone to focus on what’s most important in their tasks, it promotes simplicity, transparency, and organized collaboration. It also empowers the client, making them a part of the whole process and gives them the ability to monitor the progress of work in real time.
The development process is divided into short iterations called Sprints, with each Sprint having its own goal.
The length of the Sprint should be determined upfront for the whole project timelife, so it may happen that a Sprint will go on for four weeks. However, here at Macoscope, it usually takes one week.
Every Sprint starts with a planning session and ends with a retrospective. After each 7-day-long Sprint the client receives a working piece of the product that we are developing together.
In order to plan the Sprint, the team works with the Product Backlog wherein each project is broken down into separate user stories prepared by the Product Owner. A user story is a short description of what a user does or needs to do. They tend to be rather detailed, leaving no room for speculation and misunderstandings.
For example, if the clients is developing app for foodies, some of the user stories could look like this: “As a user, I would like to upload a photo, so that the world can see what I had for breakfast,” “As a user, I would like to see the number of people who liked my photo, so that I can see how popular the photo is,” and “As a user, I would like to be able to comment on photos, so that I can express my feelings about other breakfasts.”
User stories are basically the answers to the questions in the statement above.
In the course of Sprint Planning, the Product Owner explains to the team what should be done during that particular Sprint.
As a result of Sprint Planning, the Scrum Team is able to prepare the Sprint Backlog with stories for the Sprint. It also lets the client know what the output of the Sprint will be.
The client can be present during Sprint Planning.
This series of meetings, running as often as needed, is necessary to create a comprehensive Product Backlog for the team. This task continues throughout the whole project and includes the Product Owner who, in consultation with the client, decides on the priorities for the user stories.
Daily Scrum Meeting
Short daily meetings that allow the Development Team to coordinate its work and agree on the action plan for the next 24 hours.
Once per each Sprint, the Development Team presents the progress of their work by showing what has been done and how it works. This meeting allows the client to discuss previous results and provide their feedback to the team. Additionally, after a couple of Sprint Reviews and work progress reports, the client can notice that they understand the overall process much better and are able to prioritize the Product Backlog more efficiently, and understand how many Sprints are left.
At the end of a Sprint, the Development Team meets up and discusses the concluding Sprint and identifies improvements that could be introduced over the course of the upcoming one. The goal is for the Development Team to become better and learn from its mistakes faster with each iteration.
The client is not involved in the Sprint Retrospective, though this part of the process influences the overall performance of the team. Due to the constant retrospective approach embedded in our DNA, we can learn much faster and provide process improvements, better estimates, and work more efficiently on your project.
Artifacts of the Process
After each Sprint (or sometimes even more often) the client is able to install the demo of the app on your device and play with it. The client receives a preview of your working product on each Sprint Review, together with UI/UX designs and wireframes.
We also send weekly progress reports to the client so they are able to track how many hours were used up on their project, on which tasks, and by whom.
Last but not least, the Product Backlog also belongs to process artifacts. It consists of a prioritized list of all the features that should be developed. Work on the backlog is a constant process and some of the user stories can be added during the development process, while others can be given a higher or a lower priority. The client works on the Product Backlog together with the Product Owner.
Planning to develop an app your company needs? Already have one but you’re struggling with the launch? Tell us more about where you are at as a company and about the state of your app and we will get in touch with a solution package tailored to your requirements.