Linda and Paul run their own businesses. They are both successful, their companies are growing, but their revenue started to dwindle recently.
Looking for new ways to reach more customers and get larger market exposure, they both decided to develop mobile apps for their businesses.
Finding an app developer with the right approach for your business
Paul found an app developer, got an exact cost estimate for his product, the developer offered a waterfall approach to create his app. It took a couple of months to put together documentation of requirements, features and the app’s design. All that’s left for Paul to do now is sit back and wait. Eventually, he will get his product, complete and working, for which he will pay handsomely and he will then be able to enjoy the benefits of innovation. I reckon it will take a while and his product will be exactly as initially planned – no frills, no hassle, no Paul’s involvement. Delivered as ordered. Let’s leave Paul to wait – it will be a while.
Linda went to an agile developer and got an estimate for her app, her developer offered a Scrum method of development.
What is scrum?
Scrum is an agile methodology of software development. While an agile process is based on a set of values and principles, Scrum is a method that utilises them and offers a framework for the development process.
After agreeing to the developers estimate. Linda became a product owner. Her involvement in the process of creating the app would be quite hands on, especially at the beginning and whenever changes or adjustments would be required.
Linda got a team and a Scrum master assigned to her project. Actually, it turned out she herself became part of the team! It’s just how Scrum methodology works. As her developer explained, Scrum development requires Product Owner, Scrum Master and the Development Team to work together.
As this was Linda’s first agile app development project she did need to learn the ropes of Scrum. The developer has been working this way for many years, so there was no question they could not answer.
How would it all work? The question was on Linda’s mind from the start. The developer explained the agile development framework.
The development team roles in Agile Scrum
It starts with assigning the roles. To ensure optimal productivity, flexibility and creativity of a Scrum teams, it needs to be self contained. This means that the Product Owner, Scrum Master and the Development team would be all that is required to see the project through. The three roles form a cross – functional group with all the competencies to accomplish the work needed.
The product owner (customer) is the decision maker in the process. Linda’s job will be to tell the rest what is needed in her app. The functions, the problems they will solve, the deadlines. She would also be responsible for accepting the products of each stage of development. Should need arise to introduce changes or additions, it would be her job to communicate these to the rest of the team (Single Point of Contact). Linda will be charged with maximising the value of both the product itself and of the development team. She will be in charge of telling people what to do (but not how to do it), and decide on accepting the effects.
The Scrum master is the one person that ensures that Scrum actually happens. When working with agility, constant adjustments and need for flexibility are an everyday thing. The Scrum master’s job is to optimise the workflow, resources allocation, communication, and clarity of goals among all those involved in the project. The philosophy of a Scrum master is to serve the product owner, the team and the organisation in the strive to deliver value.
The third role is that of the development team. A cross – functional group of specialists, collectively possessing all the skills necessary to deliver the required work. No rigid titles are assigned to particular team members, they all help each other in the development process, holistically, if you please.
The agile framework
Once roles were explained, Linda needed to learn what Scrum framework is about. Her app was to be built from scratch. Scope of works, planning, schedule, deliverables, deadlines, billings – all had to be arranged. But how is it all done in Scrum?
Agile development plan
As with any project, Linda’s app development would start with a planning phase. In Scrum methodology all the components, features and requirements are put together as a Product Backlog. It is a list of so called best-understood requirements that the finished app should possess. The backlog, unlike classic documentation, is highly flexible and adjustable. Refining of the backlog is on-going and unrestricted.
Changes, additions and other adjustments can be introduced at any point during development, without the need of going back to initial planning phase. You could say that a Product Backlog is never really finished, but constantly perfected.
Scrum framework assumes working in relatively short iterations. After the creation of the Backlog, the development process is divided into Sprints – the duration of which is estimated according to complexity of requirements. Usually sprints last between 1-4 weeks and should produce deliverables in the form of working features, ready for the product owner to test, review and approve.
Short iterations add agility to the development process. New requirements, changes, additions can be introduced as additional sprints and work on them can commence immediately after current sprint is completed.
Sprints – short, agile and productive
Sprints start with planning, during which a Sprint Backlog is produced. This contains a set of requirements taken from the Product Backlog, and the goal of each sprint is to satisfy these requirements. The team establishes how to achieve the work needed to reach the goal within the set timeframe.
Each day, the team gets together for a short Scrum meeting, where daily goals are established.
Sprint planning requires product owner’s review and feedback and must be agreed by the whole team. They can then commence working on achieving the goal. At the end of each Sprint, the work is presented to the product owner for review and approval.
After a successful Sprint, we run a Sprint Retrospective. In Scrum, we evolve and adjust to each project differently. Retrospective is the perfect opportunity to look back at most recent development and identify what worked well and what requires improvements.
Once the sprint is completed, goals achieved, reviewed and approved, the cycle repeats. Sprint planning, daily Scrums, work, review. Each sprint produces deliverables, so with each completed stage, Linda can see her app growing, refining and bringing her closer to the final product and many case studies prove that.
Paying for delivery, not for promises
Sprint method also allows financial flexibility. Each Sprint can be billed as separate ”product”, so instead of paying for the whole project straight away Linda has the comfort of being invoiced on a per-sprint basis. This gives her a lot of freedom and control over the company budget. In extreme cases she could even suspend the project, drop it altogether or look for a more suitable developer halfway through it. She will only pay for the work done to date, not the full amount for the whole project.
Clarity and transparency
With each Sprint, the Product Backlog reduces and estimations of the speed of progress, remaining time and costs become more accurate. It becomes clear if the project is on schedule, if additional requirements can be introduced within budget or if some requirements can be dropped to reduce costs. Undeveloped requirements from the Product Backlog can be removed at any time and replaced with new ideas and propositions. This flexibility allows refinements according to Product Owner’s vision and ensure the final product is exactly “as ordered”.
Twists and turns
The changes, refinements and new requirements are theoretically allowed throughout the development process, but in practice, if proposed close to final testing and deployment, may involve significant delays in estimated schedule. For each new sprint a reasonable timeframe should be allowed to ensure effective collaboration.
The earlier new features are proposed and included in the Backlog, the quicker sufficient adjustments in estimations and requirements can be made.
The role of a product owner has taught Linda what it means to be a part of a team developing her dream product. Throughout the process she came up with new features for her app, got rid of ones she didn’t need, had her hand in virtually every piece of the product. The end result exceeded her expectations.
The superiority of agility
The cooperative and inclusive nature of Scrum framework gives it a significant advantage over classic, waterfall development. For the latter, any involvement of the person ordering the software during development is considered an obstacle and impedes the production process. Classic development is applicable to projects with highly detailed documentation, rigid requirements and thoroughly defined goals, where after initial planning phase all depends on the developers execution. It is virtually impossible to reduce costs of the project once development starts.
Agile Scrum methodology allows evolutionary approach, development with agility. The effects of working in Scrum give all involved the feeling of satisfaction of delivering bespoke product, tweaked and refined to suit the clients needs. It is much easier to introduce changes and expand the list of requirements during the process. Reduction of overall costs is possible by eg. dropping sprints that are to develop features no longer required.
Enjoying the fruits of your own work
For Linda, agile development with Scrum as a method proved the perfect solution. She got a product that was her own. All her isight and refinements were included, savings made by reduction of unnecessary features, some extra bits added in the meantime. She obviously stuck with the developer the whole way and opted for their services for further development. She knew that it would be quite easy to fork out something extra for another sprint.
Let’s not forget about Paul and his project. In short, he’s still waiting for implementation.