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.
- 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.
- 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.
- 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.
- 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
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.
DoD
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.
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 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.
