3 Common Software Development Mistakes and How to Avoid Them
Fans fill the stands. The crowd roars as the two teams step onto the field. The long-awaited game is here. The red team is introduced over the loudspeaker. The red fans quiet as they realize that the coach has made a rather odd choice. Every single player on the field is a running back. Granted, […]
Project Tips and Tricks
Fans fill the stands. The crowd roars as the two teams step onto the field. The long-awaited game is here.
The red team is introduced over the loudspeaker. The red fans quiet as they realize that the coach has made a rather odd choice. Every single player on the field is a running back. Granted, they are all phenomenal running backs, but still…all running backs.
The game begins. The coaches on the blue team also are making some odd choices. A few run onto the field and shout at the players instructing them on each step they take. Other coaches wander off into the stands to purchase food from the vendors.
The game is completely off the rails, so time out is called. Only neither the teams nor the coaches seem interested in discussing the myriad of ways that this game is going wrong. Instead, they all keep their distance from each other and contemplate their issues on their own.
Sound fun?
Not really. I doubt many people would attend a game if it was like this. Why? Because there are three main problems.
- A poorly selected team.
- A poorly selected coaching staff.
- A lack of communication.
What does this have to do with software? Well, many of these identical problems occur off the football field in software development. That’s why it is important to take the steps necessary to eliminate these issues before one starts to develop a custom solution.
Eliminating Issues
- Selecting the Right Team
The Red team made their mistake when they selected the people who would represent them on the field. Yes, they chose excellent players. No, they did not put together a good team.
In the same way, a good development team is made up of more than just excellent programmers. One must select the right skills and talents to complete the task at hand.
One needs software engineers who are the very best at coding, architects who can design any data structure, Quality Assurance managers who will find any bug, and more. The right team will have a mix of front-end specialists, back-end specialists, senior developers, junior developers, and leadership, all working together on the project.
2. Selecting the Right Coaches
The Blue team made its mistake when they selected their coaches. From the micromanagers on the field to the oblivious ones buying snacks in the stands, neither type of coach was going to lead the team to success.
Choosing the right coach is as important as selecting the right team. A coach must guide the team and trust them at the same time. The coach can’t point out each step that needs to be taken or check out completely.
In software development, the “coach” would be the Product Owner. He or she is responsible for having the overall vision for the product and making the decisions to reach goals. A Product Owner needs to be accessible and an excellent communicator, unlike the coaches wandering in the stands.
On the other hand, the Product Owner needs to trust the team to complete the tasks at hand. Just as a coach will call plays, a Product Owner will assign levels of importance to tasks within the project. However, once he or she has called a play, it is imperative that they don’t run onto the field in the middle of it to change or add to it.
A good Product Owner will balance hands-on leadership and hands-off trust to enable his team to “win the game.”
3. Good Communication
Anyone who has ever been at a game has seen time-outs called. During this break in the game, each team will talk, strategize, discuss the issues going on and how to resolve them, and make plans that they hope will allow them to triumph.
In an agile software development process, the plays would be Sprints and the time-outs would be Sprint Retrospectives.
Development Sprints are usually around two weeks and involve a single-minded focus on reaching an intended short-term goal. Perhaps a sprint’s goal is to create a sign-in page for a website. During this sprint, the team will focus on creating and testing this piece of the application.
Much like a time-out, the Sprint Retrospective allows the team to refocus, assess, and determine the next moves. Just as a coach might switch up strategies in order to win a game, the Sprint Retrospective allows the Product Owner and team leads to make changes to achieve success.
If you’d like to discover how our team can help your team with a custom software solution, contact us for a free assessment.