When a development team starts to build a web application, what do you think is the first thing they do? Do they start by writing code? Don’t think so? Then how do you think a typical development team work? What rituals should a team follow so that they can deliver a high-quality piece of software at record breaking time.

Most development teams work using some kind of Agile methodology . One of the most common framework in the industry that adopts this is Scrum . By adhering to the Scrum framework, the team delivers software in an incremental manner. This gives stakeholders the flexibility to review the increment periodically and make adjustments if necessary.

Now, before we go on any further, I would first like to manage your expectations. What I am about to describe to you is my own interpretation and what I find works best for the teams that I have worked for. By no means you should quote me or tell your employers this should be the way things are done. Instead, you should be using this article to understand the different concepts and how they work. It is also important to understand that each team works a bit differently. Hence, they should adjust the Scrum framework to utilize the strength of all of their team members.

To find out exactly how Scrum works, you can read the scrum guide for detailed information. But let me give you a brief overview, in my own definition, for a basic understanding.

What is Scrum?

A scrum team consist of a maximum of 10 people containing:

• 1 Product Owner
• 1 Scrum Master
• The Development Team

The Product Owner owns the product backlog or a to do list and makes executive product decisions based on the client and the business needs.

The Scrum master is responsible to facilitate, advocate and coach the teams to ensure that the scrum teams are adhering to the scrum rules and are working at the stable velocity.

The Development Team a self-organized team, consisting of many cross-functional members responsible for the development of the product. It is important to note that the development team does not only contain software engineers, but whoever is needed to complete the task at hand. Although this means that members can easily come and go, it is important to consider the loss in working velocity when onboarding a new member, or when losing someone with experience.

Some of the more common roles that you may see in a Development Team includes:

• Project Manager
• Designers
• UI/UX Researcher
• Backend Engineer
• Frontend Engineer
• Security Engineer
• Devops Engineer
• Quality Assurance Engineer
• Hardware Engineer
• Data Scientist
• Business Analyst
• Database Admin
• Tech Lead
• Tech Anchor
• Architect

Each team member has a slightly different role and don't be surprised if a person has to take up multiple roles. It is also important to understand that a team does not need to consist of all the roles mentioned above. If you want to find out more about some of the roles above and the skills needed, I recommend you visit roadmap. Take note that the site is still under development by the open source community but definitely a great site to explore.

Scaling Up

Now you may be wondering, wait a minute if a scrum team can have only 10 people, how come tech companies are so big? The answer is Scaled up Scrum. A Product Owner and a Scrum Master can be running one or multiple Scrum teams. Using the Airbnb products of hosting, experience and online experience as an example, it is possible that they are running scaled up Scrum with each scrum team working on a certain product:

1. Traveler
2. Host
3. Experience customers
4. Experience teachers
5. Online experience customer
6. Online experience host
7. Online experience livestream service

As Airbnb grow even further, they may split the teams mentioned above into smaller teams and have a product owner to manage each service. The following is an example of the services that the Traveler Product may offer that each Scrum team may work on:

1. Payment Gateway
2. Booking
3. Search
4. Automations e.g. reminders and emails
5. Authentication

Scrum Rituals

A Scrum team will produce a working increment over a course of 1-4 weeks known as a Sprint. The sprint length is usually kept consistent in order to cultivate a habit and a routine product release. The following are the different kinds of Sprint rituals that a team will typically have:

*E.g. A 4 week sprint should have a maximum of 2x4=8 hours of Sprint Planning

Sprint Planning is the preparation work done before we can start the sprint. The team will re-prioritize the Product Backlog and select items to be placed in the Sprint Goal that they commit to completed by the end of the sprint. This is also where the development team draw out a detailed plan on how to achieve the sprint goal.

The Daily Scrum is a meeting to monitor the progress of work and identify any blockers. Each person has to answer 3 questions during the meeting:

1. What did you do yesterday?
2. What will you be doing today?
3. Are there any impediments in the way?

Sprint Review is the where the increment created from the sprint is showcased to the stakeholders. Stakeholders can inspect the work and raise questions or concerns or raise adjustments.

Sprint Retrospective is a meeting that allows the team to reflect on how they work over the past sprint. The 3 questions that the team have to answer are:

1. What went well?
2. What didn’t go so well?
3. What can we do differently to improve our working velocity in the next sprint?

Additional Rituals

There are some companies that add additional rituals to ensure that the team can work at a stable velocity. These include:

Mid Sprint Review is usually done at the middle of the sprint. This is to check if there are any risk of not being able to meet the sprint goal. If there are any, make the necessary adjustments.

A Tech Bounce may be needed if the development team is not full of technical engineers. This session is basically taken out of the Sprint Planning time to align on the technical specifications such as the database design, Api request and response, frontend and backend validations etc. This ensures that the tech team is all on the same page so that frontend and backend can be built concurrently. Those that are not involved in the Tech Bounce will be doing their own version of Tech bounce, e.g. Designers, UX researchers will align on the Discovery Task and Hypothesis, QA may be planning out on what they need to do to strengthen the automation testing.

Tech Spike may be done before the tech bounce to ensure the design of the tech for the current or next sprint is efficient and scalable. Some examples include database designs, optimizations to the web application, vulnerability research etc.

Conclusion

From my personal experience, I find the scrum rituals to be much more effective when working remotely. This is because at a remote workplace, everyone is usually working at their own pace, therefore the rituals serves as a common timing for us to check in on each other. In a physical workplace, especially if your team sits in the same room and constantly talks to each other, rituals such as the Daily Scrum may become ineffective.

It is also important to note that although Scrum is one of the most popular ways of delivering a piece of software, there are other agile frameworks that a company may use. Some companies also don't adopt the agile workflow and prefer to work more towards the waterfall method.

So if your company decides how you work, how will this article help you? In my opinion, if you are given a take home assignment, joining a hackathon, or starting a new side project, the scrum framework is something that you should modify off to delivery software. How do you apply scrum in your projects? Well, unfortunately you will have to read the next few articles to find out.

In conclusion, I have scraped the surface of what is Scrum, what the teams are made up of and the different rituals that a team will follow. The next few articles will be focused around Sprint Planning. These will include user stories, database design and wireframes before we move on to the actual coding stuff. For those of you who are die hard coders, I ask for you all to bear with me a little while longer. It is important to understand that the industry is moving away from focusing on the speed of delivery, and focusing more on the quality of the delivery. From your coding bootcamp or university education you should be able to see that creating a web application is easy, but the question is, how do we write code that is clean, efficient and scalable? That is something you have to stay around to find out.

Last Updated: 14/02/2022