Published On: Mon, Mar 19th, 2018

How to build an Agile team for your software development project

Agile companies believe that teamwork is essential to delivering working software and that great agile teams are about “we” rather than “I.” However, unfortunately many companies claim they have agile team, but in reality they don’t. Therefore, I decided to write an article about agile teams and ways to build them.

photo/ Gerd Altmann via pixabay

It takes a while to transform a groups of people into a real agile team. One of the key success factors is: continuous mentoring and shared skill sets. When team members learn from each other, it makes the process of agile transformation much easier and pleasant.

There are actually common stages that team goes through to become an agile team.

  1. Forming Stage

First stage is – forming stage. It is where it all starts. And it is about focusing on defining and assigning tasks, establishing a schedule, organizing the team’s work, etc.

  1. Storming stage

This stage is about goals and guidelines. Here is where guidance are needed. Also, it is a good time to brainstorm ideas. Here the team members initiate discussion and share ideas about ways to perform their roles and responsibilities.

  1. 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 determine ways to best work together. These steps involve deciding on what modes of communication to use, such as e-mail vs slack, ways to conduct team meetings, conflict resolution ways, etc.

  1. Performing stage

In this stage team members are 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. Many time-consuming distractions are reduced, also motivation is normally very high at this stage.

What are the other important factors that should be considered in the process of building an agile team?

Respond to change

Team should understand that change is inevitable. And to be able to adapt to rapidly changing circumstances is key for agile development and agile project management.


Feedback is one of the essential parts of agile development. I would even say agile is about feedback. It doesn’t matter how fast you can deliver the desired product or feature, if they are not in demand anymore, everything that team has done may go simply to a rubbish bin. And unfortunately that happens a lot in software development. And how it feels when you actually face the situation that the project you have been working on for some time won’t be published or use? I would say this feeling is called frustration and disappointment. So, in order to be on truck with your stakeholders, you need to constantly communicate with them, therefore feedback is highly related to internal and external communication.

Short term planning and delivery

As we discussed, agile is about feedback and feedback is about short term advances. Normally we are talking about 2 weeks sprints, optimal time to code, test and get feedback on the most important functionality. It also helps to launch quality MVP faster and get ROI faster.

Support and mentoring

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 it is crucial. You learn from your peers even more than from the books and courses.

Focus on results

At the end of each sprint there are always features that you need to deliver. By placing more emphasis on the results, team members feel empowered to make decisions, solve problems, and develop innovative solutions. Having goals helps agile team to see the progress.

Team empowerment

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.

Product owner & development team

Recently I wrote an article about the importance of having a Product Owner is 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 he or she is responsible for creating and prioritising the user stories. And development team is responsible for the technical direction of the product, tech team will actually deliver these user stories. However, it is important to note that Product Owner always takes into account the feedback of tech team regarding the user stories priorities.

Agile project management tools
I also believe that agile is about efficiency and automation. The less manual tasks are done, the better. That means that using such tools as Jira is just a big must. 

Agile meetings
Being agile, means having several important meetings during the sprint: sprint planning, sprint review, sprint retrospective and of course daily standups. 


Each agile team has its own Definition of Done. But every agile team needs to agree on what they consider to be “done.”

Best practices = working software

It’s very important to learn best practices. And we believe that to be truly Agile you must practice Test Driven Development, Continuous Integration and unit testing.

Agile Games

Games are fun and they are very effective for team building.

Buy a Feature

This game teaches feature prioritization and it takes around 15 minutes to play.

The optimal number of people for groups is between 3-8. Each player receives two items: a handout with a menu of features and their prices, 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, 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.

The White Elephant Sizing

Agile team needs to estimate user stories as well as product backlog. In this agile game, players have 50 user stories and have 4 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.


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 2 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 it on their sheet and will then communicate it to the Team B that will, therefore, update them and which ships sunk, hits that were missed, etc. Team B then also gets 5 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. 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 5 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 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.

I really hope that you found this article useful! I you know other interesting agile games, feel free to share them in the comments section below!

Thank you!

About the Author

Ekaterina Novoseltseva is a CMO at Apiumhub – software development hub, which is specialized software development and software architecture. 

On the DISPATCH: Headlines  Local  Opinion

Subscribe to Weekly Newsletter

* indicates required

About the Author

- Outside contributors to the Dispatch are always welcome to offer their unique voices, contradictory opinions or presentation of information not included on the site.

Leave a comment

XHTML: You can use these html tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>



The Global Dispatch Facebook page- click here

Movie News Facebook page - click here

Television News Facebook page - click here

Weird News Facebook page - click here