IT workers (myself included) have most likely already heard the following sentence, after being assigned a delivery date to the product team:
“Isn’t your team Agile? Shouldn’t you’ve finished this task faster?”
If you’re one of those IT workers, you’ll maybe roll your eyes or, at least think about it. But to be honest, they aren’t wrong. The Agile method is an approach to fasten delivery. Atlassian mentions that on their website:
“Agile is an iterative approach to project management and software development that helps teams deliver value to their customers faster and with fewer headaches.”
Nevertheless, in this article, I’ll try to explain why being Agile does not necessarily mean that you’ll finish the project faster, it means the team can deliver small results faster, resulting in more adaptability for future changes.
Agile is a mindset that everyone involved in the project should comprehend. If a company tries to be Agile but prioritizes finishing everything fast, it’ll be avoiding Agile principles. This way, the project won’t be agile or flexible enough when change is required, and it will take longer to complete it.
So, in this article, I’ll try to clarify the impact of using (or avoiding) Agile principles. If it’s your first time hearing about Agile, then make sure to read this article, so you can understand the basic concepts first.
The Meaning of “Agile”
According to the Cambridge dictionary, agile means: “Able to move your body quickly and easily.” Notice that the word fast or faster isn’t even mentioned on the synonyms list.
For companies, the Agile method means being able to change your project plans quickly and easily.
But how can a company become an Agile company?
The agile method has a lot of frameworks that can help that transformation, but for this article, I’ll use the Scrum framework as an example.
The Scrum Process
So, let’s start by talking about how Scrum works and can help the company have an Agile mindset.
Most IT projects aren’t a straight line, failures happen, and plans change throughout the development phase, but with Scrum, the project can be more adaptable when it comes to solving these problems.
Because Scrum tries to separate the project into small pieces that can be planned and delivered in a short period of days (2, 3, or 4 weeks), this feature gives the project more flexibility to change during development.
The image below illustrates the structure of a Scrum team and the steps of the process:
Scrum Team Roles
A Scrum team is composed of:
- Product Owner
- Development
- Scrum Master
Every project has a product backlog of tasks. The product backlog consists of a collection of small tasks that will be developed in a short period of time.
The Product Owner creates and manages the product backlog. Their responsibilities include understanding the customer and business requirements, transforming them into tasks, adding them to the product backlog, and defining the value and goal for each sprint.
The members of the development team will be working to complete their tasks in the sprint and advance the project.
Scrum Masters train other professionals regarding Scrum methodology. They can help the Product Owner define the sprint value and guide the developers to deliver it.
Cycle Steps
Scrum has a cycle of steps (called rituals) that need to be followed:
- Planning;
- Sprint;
- Retro.
Planning is the phase when the product owner presents the sprint backlog to the development team, describing the sprint’s tasks and goals. Here, the developers and Scrum Master have the opportunity to bring up any missing information and situations that may result in the incompleteness of a particular task, before reaching an agreement about the sprint.
Then, the Sprint begins and developers start working on their development tasks. The team gathers every day for a “Daily”, a quick meeting where team members provide updates about their tasks. These meetings help the team become more agile by giving them the flexibility to change their plans to reach their goals for the current Sprint.
During these daily meetings, the team can evaluate if any tasks will take more time than predicted, decide if more people need to be working on a particular task, or deprioritize less important tasks.
The team meets again at the end of the Sprint to present their results. At this point, they take any mistakes into consideration, discuss what went well and what didn’t, and adjust for the following Sprint. The Retro marks the beginning of a new cycle that repeats the same rituals.
These cycle steps give team members the flexibility to change ideas and direction throughout development. After each Sprint, stakeholders, and customers have access to a small portion of the project and manage to provide their feedback.
Any required changes are inserted into the product backlog by the Product Owner and the development team begins working on it on the following Sprint.
With a well-coordinated team, the company can have a fast and agile Sprint at the same time. To do that, good communication between members is crucial (here’s an article about how to improve your communication skills). The company also needs to understand the process and not interfere with the sprint goals while the team is still running it.
Any interferences can disturb communication between the team members, which could result in a fast development sprint, instead of an Agile one. This could cause blocks or issues that will impact the following sprints, turning the whole project development slower.
To explain what I mean by the impact of interfering with the team members while still running a sprint, I’ll illustrate using an NFL play called a running play.
Demonstrating the Impacts of the Sprint
The name Scrum comes from a sport called rugby. In rugby, Scrum is called after some infringement of the rules, the team reunites, and the play restarts.
As with Scrum, the sport American Football National League (NFL) is based on rugby too. The goal of both sports is to advance into the other team’s territory and score, whether by reaching the ball in the end zone or kicking the ball into the field goal. The main difference is that instead of waiting for some infringement, in the NFL, after all plays, the teams reunite.
All plays in the NFL start with the coach planning and informing the quarterback what play the team has to run. Then, the quarterback informs all players on the field about the play, formation, and directions. The players get set at their positions, and the play starts.
One of the plays chosen by the coaches could be the running play, in which the quarterback gives the ball to the running back and has to wait for the blocks to open free space to start sprinting toward the goal.
For the play to be successful, communication needs to be clear and everyone must understand the play, if not, it will be easy for the defenders to stop the play.
Here’s an unsuccessful running play:
In this play, a defender from the red team was free to block the running back, this happened probably because:
- The coach of the white team selected a bad plan;
- There’s a lack of communication between the coach and the players of the white team;
- The white team wasn’t expecting a defender.
Regardless of the reason, the runner was stopped very early, resulting in an unsuccessful sprint, which means that the team starts the next play at a disadvantage.
Now here’s an example of a successful play:
In this play, everyone understood their responsibilities, resulting in great protection, from the defenders, and a great path for the running back to start a great sprint.
After the running back passes the initial blocks, there are still some defenders left, but now it is their responsibility to be agile and change direction to avoid the defenders, while still running fast towards their goal (the end zone) and celebrating a great sprint with their teammates.
So, Does Agile Means Being Fast? Final Thoughts
On the NFL field, the running back is the fastest player on the field, but being faster doesn’t mean being the best player. The running back needs agility to change his direction.
The same happens within a company: you can have the fastest development team, but like a running back running towards the end zone, IT projects aren’t a straight line. The team needs to have a great plan and communication to avoid blocks at the start of a sprint. Only then can the developer begin to build an Agile project, being prepared for late direction changes while still running a fast sprint towards the goal.
So to answer the question:
“Isn’t your team Agile? Shouldn’t you’ve finished this task faster?”
No, the goal is to build a flexible project, so the project plans can change, while the development team keeps working as fast as they can.
