Building an agile team in a structured way

Introduction

Agile methodologies in the context of software development are widespread today, being used in companies of all sectors and sizes and I believe in their positive results when applied correctly.

Many teams, by doing dailies, estimates, planning and retrospectives, say they work on the scrum model. Others, for not estimating the tasks and not having sprint, say that they work with Kanban. Agile methodologies are much more than just ceremonies, working with agile methodologies is having a growth and learning mindset, having to be willing to always be evolving and improving as individuals and especially as a team.

In my career, I have applied Scrum, Kanban and Scrumban several times in different ways, but each time with its own peculiarities.

In short, the purpose of this article is to explain one of the ways I have worked and how it has been applied to some of the teams in which I have led.

How it all begins

You, as a technical leader, will at some point receive the requirements of a project prepared by PM or PO depending on the nomenclature that the company adopts.

Then you will have an idea of ​​how a particular feature should be, from a business or customer perspective. There will be nothing very technical associated with your first inputs.

Given this first contact or contacts, you will need to get organized. You will have to understand the functional and nonfunctional requirements of this feature. Some examples of items you should think about would be:

• How many concurrent users should this feature support?
• What is the expected response time for certain flows?
• How do you think about the evolution of this feature? What can it become in the future?
• How many services and integrations (internal/external) are involved in development?
• Is there any technical debt involved that needs to be resolved beforehand?
• My team has all the skills needed to develop this feature?

These are some examples of what you need to analyze and get answers for, but that’s not all, these issues vary greatly depending on the characteristics of the projects and features that need to be implemented.

You can get a lot of these answers alone, but not necessarily all of them. You will be able to share the burden of these tasks with your team and some of them may demonstrate ownership and seniority for more complex tasks, but we will cover this topic in the course of this article.

Story Mapping

Once the minimum information is organised, it will be essential to share this information with your team. In fact, it is not necessary for all details to be already defined — the team is supposed to help define certain flows and technologies. What you need to have ready is an explanation of the problem that needs to be solved and what solution options exist. In this meeting you will draw workflows, explain the limitations and work collaboratively with the team to come up with a solution. Most likely, you will remember something that was out of the radar, it could be both implementation-related and process-related. Some possible examples:

• We need to inform the marketing team that this feature can impact them
• We need to inform the Data team that they need to import some tables into Data Lake so we can measure the impact of this feature
• We need to align with other teams who are doing something similar
• We need to fix a technical debt since this blocks the implementation of this feature
• The solution presented here is very costly. We can narrow the scope at first and implement this way (explanation). In this way, we were able to deliver faster and measure the impact. If the results are positive, we will work to implement as initially suggested, but in an incremental approach.

This meeting is for the team to understand the MVP of the feature and also manage to break into small deliveries.

You can define a way to measure the impact of the feature. And also what is the best rollout strategy.

You should think about whether you can implement a feature toggle in case you need to turn it off.

The output of this meeting is not tasks or user stories. The output of this meeting are answers to the questions you brought to the meeting and also new questions that you had not remembered that you needed to have done. The purpose of this meeting is to increase the synergy of the team making everyone feel important in decision making and have the ownership to make the best decision in the implementation of a particular feature, as well as being a great brainstorm so that nothing is forgotten and much less that it starts wrong. This reduces time estimation errors and possible bugs caused by developers who did not have the necessary requirements and assumed something during development. Usually, when the developer assumes something during the implementation, this is discovered too late and generates bugs in production or a hastily altered code and therefore could be better.

Another important point is that productive meetings are short meetings. So, they should last between 30 min and 1 hour. If you need more time, it is advisable to break into more than one meeting and take the opportunity to rearrange the issues raised in the previous meeting.

Refining

Now is the time to structure the whole idea.

Before the refining meeting, you need to understand if everything has been defined or if there's still any unknown involved.

You will write the tasks/user stories containing a description of what needs to be done and acceptance criteria that says how to validate that what has been implemented is correct and can go to production. This acceptance criterion is basically a checklist of what needs to be tested by a Quality engineer or other software engineer of the team before deploying in production.

That said, the meeting starts by reviewing what was defined in the story mapping and then presenting the tasks/user stories for the team. For each task/user story presented, it is validated if everyone understood, if the task/user story is of a good size or if it needs to be broken into smaller tasks or even grouped into another task.

After that, if the team works with Scrum, the task is estimated and continues in the backlog until the next Planning, if Kanban it can go to the board.

Daily meetings

The purpose of daily meetings is for the team to share a report of what was done the day before and what is in progress now. It's also a chance to reports if you have a problem or are blocked.

The meeting should last at most 15 minutes and should be done with everyone standing, so it is more objective and productive.

It is very common for the daily meeting to be nothing less than an individual report of each member of the team. I did this and I’m going to do that. If they are working on more than one project/epic/feature, the division of the speaker is by members, not by projects, which results in no sense of the evolution of the features. That said, many teams stop to do the daily meeting because they see no value in it.

Daily meetings are fundamental and indispensable because the main objectives are:
- Identify how close to a delivery the team is or is not
- Is there a problem that is impacting the speed of the team?
- Something unexpected happened and somehow impacted the team. What quick action can be taken so that we can mitigate this problem and minimize its impact?
- Does the team work as a team?

All right, what can you do to improve this quick meeting?

First at the beginning of the sprint, if you are working with Scrum, or at the beginning of the week, if you are working with Kanban, it is necessary to put the Week / Sprint Goals on the board. This needs to be defined with the team in planning (if it works with Scrum) or just before starting Monday’s daily in the case of Kanban. These goals set out on the board are what will guide the team’s actions and decisions.

The second step is to split the board by project/epic/feature. As much as the team works hard focusing on one feature at a time (which is ideal) we know that real life is not that simple and there is always something, however small, being developed in parallel.

In this way, the report will be divided by feature and not by a team member. Everyone who is working on feature 1 will give you their report, and in the end we will understand if it remains on track or if something has changed since the last conversation. After discussing feature 1, move on to feature 2 and so on.

It is very important to focus on the sprint/week goals if something is out of the picture, it is important to discuss with the team to see what can be done to minimize the impact. Like for example:

• Let’s give up feature 2 (this sprint/week) and everyone will work on feature 1, because in this way at least we deliver a feature instead of none.
• Our Quality engineer is sick, so let’s split up to test the features so we do not create a bottleneck in the development pipeline and what’s close to being delivered is delivered faster before we start coding new tasks.

Do you understand the meaning of the daily? It is not an individual report, but rather that we can work better as a team. How we can deliver more having an active collaboration of each one. And how can we keep delivery promises by focusing on goals rather than tasks and sub-tasks.

It is also good practice at the end of each daily show graph (burndown, burnup, throughput, etc.) of how the sprint/week development is.

Retrospective

The retrospective is nothing more than the moment when the team needs to get together and understand what the job has been like in the last days. This meeting is the time to set goals, quality parameters, the working model, among other things that the team sees as necessary. Beyond the definition, it is always important to follow the progress of what has been defined. I always start the meeting going through some numbers that the team defined as goals, for example:

• New bugs in the last x days
• Closed bugs in the last x days
• Total open bugs
• Open technical debts in the last x days
• Closed technical debts in the last x days
• Total open technical debts
• Goals reached (can be a sprint, can be of a certain period)
• Features delivered

It is important to evaluate and discuss the whys if there is any unreached goal and/or if any action defined in the past retrospective has not been performed. Let’s talk more about it in the next paragraph.

There are a number of approaches to how to proceed in a retrospective, but the most important to be obtained is to answer two questions “What went well?” and “What needs improvement?”. Usually, each member of the team writes their points individually and in a second moment, all points are open to discussion.

Be careful to not turn a retrospective meeting into therapy. The points raised need to be discussed and actions need to be defined to solve the problems. Depending on the points raised, it is easier or more difficult to define actions, but definitely all the problems raised need to have actions defined, executed and measured in the upcoming retrospectives. Only then will the team be able to evolve gradually.

Another important point: celebrate the achievements. Don't neglect the goals achieved, the problems solved, the features delivered. Celebrate with the team and show that each one’s effort and dedication are important. The retrospective cannot be seen as a negative context meeting, but rather important for the growth of the team and that reflects the reality that the team is going through.

The meeting should have a fixed cadence, no matter if you work with Scrum or Kanban. Usually, every 15 days is a good cadence, since there is already some output of the actions defined in the previous meeting, as it is already possible to verify new problems to be addressed.

Planning

The planning meeting is required if your team works with Scrum.

It does not need to last longer than 15 to 30 minutes. After Story Mapping and Refining the team is already well aligned with the challenges ahead. The purpose of this meeting is to check if the next sprint team members are going to work, or if someone is going to have some day off or a vacation and there are holidays among other things that can impact a normal day of work. Given this, you can estimate how many points the team can deliver in the sprint. It is validation with the team and the PM / PO if they are all according to what needs to be developed and delivered in the next sprint. Do not forget to set the Sprint Goal or Goals. Depending on what needs to be delivered, sometimes the goal seems very obvious, however, what is obvious to you may not be obvious to everyone. So even though it’s repetitive, it’s important to speak out loud and align with everyone present at the meeting if everyone agrees with Sprint’s goal and whether it is achievable.

I have already experienced planning meetings that last for several hours since the meeting encompassed everything that is done in Story Mapping, Refining and Planning.

There are two major problems with such an approach. First, long meetings are very tiring and unproductive. After an hour of meeting the majority of the team is dispersed and accepts anything that is said so that the meeting ends soon. The second problem is that the care that exists in Story Mapping and Refining so that all points are properly listed, remembered and studied does not exist. Because everything is defined at the same time, there is no period for information to be absorbed, rethought and validated with other stakeholders.

This is the great asset of breaking Planning into several smaller meetings, you have over time the definitions being taken in a much more organized and productive way and the planning is only a ceremony to identify how much of the team’s tasks can be accomplished. and what goals are to be achieved.

Team Morale

In addition to the retrospective, there are initiatives aimed at measuring the happiness of the team, because if it is detected that a member or some members of the team are not happy, it means that there is something that is not good and can be adjusted before it becomes something worse and more problematic. I agree in parts with this approach and I’ll explain why.

My understanding is that no one is happy all the time. We, humans, are not 100% happy, but we live a life with peaks of happiness. What I mean is that I can be happy in my work and at the same time I can have personal problems that make me worried or discouraged or even unhappy. Depending on the day this question is asked, the answer can vary greatly. Another problem related to the measurement of happiness is that it is often not possible to have a practical action for the team or manager of the person other than a friend’s talk or ask him to seek a specialized professional. Remember, agile methodologies are frameworks dedicated to continuous improvement that can be done to make a group of people work better and more efficiently and effectively. Of course, personal problems will interfere with the group’s results, but it’s up to other specialties to help people with their personal problems in what they need. Be very careful in overcoming this barrier, you probably cannot be prepared to help in the best way possible.

That said, I prefer to work by measuring team morale, as it is a much more stable metric compared to happiness, less moody, more task oriented and less biased.

Because it is a more stable metric, there is no need to have the same cadence as retrospectives, you can measure it every month or even longer.

In the week of the retrospective, a form with 4 questions is sent to all members of the team. After all responds the individual average is made for each member and with these averages, the overall team average is made.

The result of this form is very valuable information to be used in retrospectives. It is interesting to show the historical measurement, evaluating if the team is raising, decreasing or maintaining stable morale. And most importantly, identify the causes of leaving the team with a low morale and define actions that make the team can raise their morale.

Remembering that exposing the individual numbers can generate some discomfort in some team members, so it is more recommended that only the collective results be exposed. If you are managing team members, you can use these results to discuss in 1:1s, or even share with the manager of each.

I have based myself on the article by Christiaan Verwijs to implement the team morale as a metric, and in his article, there is much more detail on why to measure morale rather than happiness on your team beyond which questions to ask.

Reports

Let’s say that all meetings are productive, that team morale is high and deliveries are happening. Everyone on the team has the feeling that everything is fine, but how do you prove that there is a constant growth in the team? How can you visualize that the performance of the team is diminishing? At this point, you need data and numbers. You need to be able to track the team numbers.

There are many numbers that can be extracted and evaluated, but if you can measure the speed or throughput of the team, in addition to the number of technical debts and bugs, you will already have a lot of input on how and where the team can improve.

If you want to deep into this subject, I highly recommend the book Agile Metrics in Action: Measuring and Enhancing the Performance of Agile Teams.

Leaving the legacy

As the team works with this methodology, it is possible to verify which team members have an interest in coordinating and organizing methodologies and processes. That said, it is important that there is a space for learning and mentoring, where smaller projects can be led by one of these members, and with that you can help and guide the structure and organization of projects closely. In this way it is possible to increase the parallelism and train these skills of other team members so that at some point they can assume this role and disseminate this methodology in other teams as well.

Conclusion

It is very common when I explain this structuring of how an idea becomes a feature in production in an organized and structured way that this is to bureaucratize and formalize the agile too much and that it is better to leave the team with freedom of creation. This argument is very fallacious. Agile is not to de-structure everything and every member of the team does what they want, quite the opposite. Agile is you being able to structure and organize your team in a way that it builds software that can be easily adapted and measured in the best way possible for development to follow the changes and business decisions without your code turning a patchwork quickly .

For this to happen, it is necessary to have a well defined organization and processes. Only then can development decisions be made in a clear and conscious way of all the risks involved. Taking into account what needs to be done, what to expect, what needs to be implemented more flexibly, what needs to be measured, and so on.

Another argument that I completely disagree with is when I hear that the freedom of team building is reduced when there are more structured processes. The entire team can participate in architectural and implementation decisions with or without organization and structuring. What changes with the structuring of the processes is that the possibility of assuming a certain behavior in the code in the wrong way or forgetting an impacting part of the project and only remember near the delivery date is minimized. All ceremonies cited in this article are formed by all members of the team. Everyone on the team can express opinions and argue at any ceremony, and they can do this at any time of the day when they are working.

The third argument I hear is that this process has many meetings. If you look closely you will see that you are actually reducing overall meeting time and making it more productive. The team replaces a meeting with hours duration for two smaller meetings that are more productive and more cohesive. So the team can work in a much more focused way and make decisions in a more rational and intelligent way, because they are not in a meeting room for hours hungry and tired.