Agile companies believe that teamwork is essential to delivering working software, and that great Agile teams are about “we” rather than “I.” Unfortunately, many companies claim they have an Agile team, but in reality they don’t. It’s important to learn what an Agile team really is, and to find ways to build them within your own company.
It takes a while to transform a group of people into a real Agile team. However, it pays off later on, as Agile project management brings a lot of value to the team and to the client.
Let me just mention the most common Agile benefits: 93 percent of teams said Agile helped them improve speed to market, 93 percent said it helped them switch gears more quickly and effectively, 87 percent said it helped them to be more productive, 80 percent said Agile led to enhanced prioritization of the things that matter, and 80 percent said adopting Agile helped them deliver a better and more relevant end product.
One of the key success factors is to provide continuous mentoring and shared skill sets.
When team members learn from each other, it makes the process of Agile transformation much easier and more pleasant.
Qualities of an Agile Team
More than anything, teams should understand that change is inevitable. Being able to adapt to rapidly changing circumstances is key for Agile development and Agile project management.
Able to Incorporate Feedback Quickly
This change most often comes from receiving and giving feedback. Feedback is one of the essential parts of Agile development. It doesn’t matter how fast you can deliver the desired product or feature; if it is not in demand anymore, everything that the team has done may simply go to a rubbish bin. And unfortunately, that happens a lot in software development.
How does it feel when you actually face a situation where a project you have been working on for some time won’t be published or used? It’s very frustrating and disappointing.
So, in order to be on track with your stakeholders, you need to constantly communicate with them; therefore, feedback is highly related to internal and external communication.
But for Agile teams, you can’t just listen to the feedback. You also need to incorporate it quickly. Feedback, in an Agile sense, is about short-term advances.
Normally, we are talking about two-week sprints—optimal time to code, test, and get feedback on the most important functionality. It also helps to launch quality minimum viable product faster and get return on investment faster.
Work Together as a Team
There is a very good saying: “If you want to go fast, go alone. If you want to go far, go together.” And in Agile software development, this is crucial. You learn from your peers even more than from books and courses.
A very important part of building an Agile team is to empower the team to work independently.
Not only does this give all the team members a sense of belonging and ownership, it also shows trust and respect.
At the end of each sprint, there are always features that you need to deliver. When teams work using Scrum methodology, they have user stories; tickets they need to move from “to do” to “done.” And when all of them are on the stage “done,” it motivates team members, as they can actually see the result of what they are working on. By placing more emphasis on the results, team members feel empowered to make decisions, solve problems, and develop innovative solutions.
Goals in every Agile team are different. At Apiumhub, we put working software over a number of functionalities, always doing test-driven development (TDD) and continuous integration (CI). Having goals helps Agile teams see the progress and move forward in the right way.
The best way to help make these goals clear is having a product owner role on an Agile team. I strongly believe that it is a must nowadays. The product owner is responsible for the business direction of the product, and they are responsible for creating and prioritizing the user stories. The development team is responsible for the technical direction of the product, and the tech team will actually deliver these user stories.
However, it is important to note that the product owner always takes into account the feedback of the tech team regarding the priorities of user stories.
Be Organized and Use Tools
Being Agile is about efficiency and automation. The fewer manual tasks that are done, the better. That means that using such tools as Jira is a big must. You can find other Agile project management tools here. Being Agile also means having several important meetings during the sprint: sprint planning, sprint review, sprint retrospective, and, of course, daily standups. Having meetings often means that there is a higher likelihood that everyone understands their role and what they need to achieve.
Each Agile team has its own definition of “done.” But every Agile team needs to agree on what they consider to be “done.” It is key to delivering high-quality products and satisfying your stakeholders in terms of project management and results, and functionalities and quality. Basically, it is a checklist of features and activities that adds or demonstrates value and that needs to be completed.
As we mentioned in the beginning of the article, unfortunately, many teams try to be Agile, but they fail. In the software development world, based on our experience, it’s very important to learn best practices, and to be truly Agile, you must practice TDD, CI, and unit testing.
There are actually common stages that the team goes through to become an Agile team. Let’s look at them.
How To Build an Agile Team
Creating an Agile team takes time, and members often go through different stages from being just a group of people to an Agile team with common goals and right processes. I don’t want to reinvent the wheel here; let me just share with you Bruce Tuckman’s stages, highlighting the important things to better understand them. They will definitely help you make your team more effective.
Forming Stage
The first stage is the forming stage, which is very similar to orientation day at universities. It is essential and helps people get to know each other, find useful information, and write down the rules. This stage is about focusing on defining and assigning tasks, establishing a schedule, organizing the team’s work, etc.
Storming Stage
Being on a team is like being in a relationship. At first, you may think that a person is perfect, but then you realize they actually are not. And then you either learn to manage the relationship or it will end quickly. This stage is also about goals and guidelines that each team should follow to be on the same wavelength and achieve the common goal. In this stage, teams brainstorm ideas to find solutions to the issues they have.
Norming Stage
In this stage, team members develop their purpose and strategy for achieving their goals. This is when everyone is focused on developing shared values and determining ways to best work together. People start to notice and appreciate their team members’ strengths and everyone contributes and works as a cohesive unit.
Performing Stage
In this stage, team members are confident, motivated, and able to easily work together on interdependent tasks. It also gets easy for them to communicate and coordinate with each other in an effective manner. Basically, the fourth stage is the one that all Agile teams strive to reach.
Team-Building Activities for a More Agile Team
Games are fun and they are very effective for team building. Here are some examples of the games that are quite short, but very effective. Let’s look at the most famous ones:
Buy a Feature
This game teaches feature prioritization and it takes around 15 minutes to play. The optimal number of people for groups is three to eight. Each player receives two items: a handout with a menu of features and their prices, and a sum of play money.
Features can be anything, for example: items to have on a vacation. The sum total of all players’ money should be less than the total of all feature prices. This introduces scarcity and forces the team to make trade-offs, because it’s not possible to purchase all items on the list.
Players take turns using their individual sums of money to pay for features they find most valuable. Once players have spent most of their funds, and either they don’t have enough individually to make another purchase or they don’t value what’s left on the menu to buy anything else, the group will pool the remaining funds and discuss what to buy from the remaining items. This game helps team members to learn how to prioritize user stories and how to do resource management.
The White Elephant Sizing
In all software projects, Agile teams need to estimate user stories as well as product backlog. And this game is fantastic to learn how to estimate user stories. In this Agile game, players have 50 user stories and have four hours to estimate them. Everyone’s voices are heard, and everyone contributes equally.
The goal of this game is to get a quick estimate of the size of an Agile project and the size of the individual stories before the project starts. I believe this game is absolutely a must, as most Agile teams have issues with estimating their projects in terms of time.
Battleships
This Agile game is generally used to introduce people to iterative development and to explain the concepts behind it. The idea is to get people to understand that up-front, large plans are just not a good idea!
In this game, you have two teams: A and B. Each will have a “battleships sheet” and some dots. Each team will have around two minutes to plan how they would like to place their ships. Team A will have five minutes to plan its hits up front and will mark them on their sheet, and will then communicate them to Team B, which will tell Team A which ships sunk, hits that missed, etc. Team B then also gets five minutes to play each one of their hits, but this time with real-time feedback from Team A on misses, hits, and ships that sunk.
Results are obvious. Team B gets the chance to change its plans due to the fact that they follow iterative rules, which will make them score higher. It seems obvious in this game; however, many teams forget it when they work on real projects.
The Ball Point Game
This game helps a lot when introducing Scrum to new Agile teams. It helps to estimate user stories, sprint, and the project overall.
The rules are simple: You need to give the team as many balls as possible in two minutes. Each ball has to pass by each team member. In order to get a point, it’s important that the first person who gets the ball be the last one to touch it. So the team will get five iterations, and before each one, it has to estimate how many balls they believe will be passed. Then, the actual number is recorded at the end of each iteration and is compared with the estimations given by the team.
Often, at the first iteration, it is very difficult to give an estimation, as the team doesn’t really know how long it may take to get one ball through the whole team. But, after each iteration, there are retrospectives, and therefore the team adapts the process. With each iteration, normally, the results become better and better. This game helps Agile teams work together and learn how to make estimations, taking into account not only personal capabilities, but also capabilities of the team as a whole. Also, it helps to understand the need for iterative progress and development.
Build an Agile Team to Streamline Software Development
Statistics say that by using Agile project management, on average, the time to market is 37 percent faster and the efficiency of an Agile team is increased by 16 percent.
Switching to Agile is a great idea and I really hope this article gave you a good overview of what it is and how you can master it. And if you know other interesting Agile games, feel free to share them in the comments section below.
| Published on Java Code Geeks with permission by Ekaterina Novoseltseva, partner at our JCG program. See the original article here: How to Build an Agile Team for Your Software Development Project Opinions expressed by Java Code Geeks contributors are their own. |
