Agile Methodology in Tech Companies

How we run Agile (scrum) methodology in a big Tech company

Agile can be work only if the employees are trained in that mindset. Otherwise it could be just a waste of time with no a lot of impact in the way of working.

In the last 3 years i worked with a very strict Agile methodology in my company and it had a huge improvement in the way that we worked with successful sprints (and goals), but also decreasing a lot the “stress” of doing a task.

Before going to details lets see a little bit the theory of Agile.

What is Agile Methodology

The Agile methodology is a way to manage a project by breaking it up into several phases. It involves constant collaboration with stakeholders and continuous improvement at every stage. Once the work begins, teams cycle through a process of planning, executing, and evaluating.

This is a simple explanation of Agile Methodology. Now let’s see as an example how our team is composed and explain how the agile system is really working.

Team Composition

I will not name the company, but i will provide some information about our team. The company is too big so we have multiple teams, everyone focused on a specific feature/technology.

Our team is focused on AI Technology. We have a large number of people with job title “Bot Trainer” which are our engineers that are training our bot to understand better the end user. We have the front end developers for web and app (one of them is me), the back end developers for our services, UI/UX designers, Product Owners, copywriters and our Scrum Master (that is responsible that the whole Agile system is followed in every stage of the project).

In order to manage all these people and their tasks is necessary to plan the tasks and what every people should do in a specific range of time. To achieve that we run sprints and have some “ceremonies” during every sprint.

The sprints are driven usually based on the Stakeholders needs. The continuous communication with the stakeholder is crucial as the sprint’s tasks is based on the decisions from stakeholders and product owners.

Let’s see in our case who is the stakeholder.

Stakeholders

A stakeholder has a vested interest in a company and can either affect or be affected by a business’ operations and performance. Typical stakeholders are investors, employees, customers, suppliers, communities, governments, or trade associations.

In our case our stakeholders are the people that are managing a customer service operations (like call centers and customer satisfaction). Our AI and applications reduce the work of a call center agent as the bot can reply to customers questions without connecting them to a real person.

The stakeholders can provide information about their work, their problems (and possible solutions), their workload and some feedback about how our product will help them. In this way we take actions and improve our product based on their needs and customer needs.

After taking all the information about the Stakeholders we plan our tasks (we have a specific meeting about that that we will explain later). All the tasks are organized inside a sprint.

Sprint

A sprint is a short, time-boxed period when a scrum team works to complete a set amount of work. Sprints are at the very heart of scrum and agile methodologies, and getting sprints right will help your agile team ship better software with fewer headaches.

In our case we run 14-days (2 weeks) sprints, because as a company we need to deliver an update every 2 weeks. Every sprint needs to have a Goal (the most important task of the sprint) and it’s successful only when that goal is achieved.

The next important thing on the Agile Methodology are the Ceremonies, which are necessary to plan and successful deliver the tasks into the sprint.

Agile Ceremonies

Agile ceremonies are four events that occur during a Scrum sprint. These are Sprint Planning, Daily Stand-Up, Sprint Review, and Sprint Retrospective. Without them, agile development could survive, but it couldn’t live well.

In our case (as we are a big team) we have one more ceremony called “Refinement” and it helps us for better Planning (it’s the Sprint Planning ceremony divided in two parts).

Let’s see them one by one.

Daily Stand-Up

This is the first meeting we have at the beginning of every day. Every member of the team can speak about a minute about the tasks that he did the day before and what he is planning to do next. It’s useful for the other members of the team to have an overview of the project and what every person is responsible of. It’s also necessary if a member has a problem and other team members can help him to resolve that. It should not last more than 15–20 minutes.

If a member has a problem he just have to say it to the daily, but he should take actions after the daily.

Sprint Planning (and Refinement)

This meeting occurs once every 2 weeks. It’s necessary to define the tasks of the Sprint of every team member. The product owner talks with every member to decide together what task can be included in the sprint.

Every team has a backlog (tasks that we should work on). The planning is to choose some tasks from the backlog and put them in our Sprint.

Every task has a specific “Complexity” and the tasks that we pick for that sprint should have realistic sum of complexity. The complexity is called “Story points” and is based on Fibonacci’s scale. Using Fibonacci scale system you can rate a task (for example a simple task should be 1, and one other difficult could be an 8 or 13). Usually a 13 complexity is too much for a short term sprint and it should be divided into more parts as it cannot fit in a single sprint and the sprint will not be successful.

After setting up all the tasks, the product owner decides what is the sprint goal and by that point the Spint will start!

Note that when the Sprint starts it should not change during the 14-days period. If it changes it should be a critical task (like an error in production that affects the whole project) and that is called “Scope Change” and it should be communicated also to the stakeholder (why that happened).

Developers (at least in our case) can decide alone their tasks that should be included in the sprint as they usually know better the necessary time that they need to develop something and maybe the problems that the software could have.

Sprint Retrospective

Also this one occurs every two weeks. In this meeting we need to answer to 3 simple questions for the Sprint:

• What we did well
• What we did wrong
• What can be improved

Answering those questions (all the members should participate) can give us feedback about what we should keep doing, what we should stop doing and what actions we need to take in order to improve our performance.

If you have any problem with someone or something, this is the right place to talk about it. Be honest, everyone wants a peaceful and a great working environment. Here you have the opportunity to take actions about fixing your daily problems in the workplace.

Sprint Review

This is the last meeting of the Sprint. Show your work to the Stakeholders.

In this meeting the team shows what tasks have completed, some statistics about the sprint (success rate, velocity etc) and how to the product will help the stakeholders and the customers.

The Stakeholders can give feedback to the team during the presentation (also suggestions and possible errors, if any), can ask questions about the statistics and performance and at the end about the next steps.

This is how we run agile Methodology in our company. It requires a lot of time to have the mindset of the agile, but sprint after sprint you will see a lot of improvement.

Thanks for reading.