If you recently graduated from the University - there is a high probability that you have never seen a waterfall software development process. Most likely, all you have had experience with is some sort of Agile framework. However, even if you have been taught from a blank page and don’t have any legacy thoughts in your head - you are probably still influenced by common misconceptions that came from the era of early adoption.One of the most misunderstood topics in the community is how teams are structured and managed. We can’t trace where this comes from, but for sure, it originated somewhere from the way Agile was adopted—people jumping into implementation without getting it right. This is, in fact, the way we would like Agile to be embraced. However, they go off the road when the above-mentioned implementations are not being revised and adopted. Cross-Functional Teams. The common misunderstanding is that if the team is cross-functional - that means that everyone on the team should be able to juggle all the topics. Backend, frontend, DevOps, quality assurance, you name it. In general, this idea is not so bad, and if we fill the team with absolute superstars who are proficient in every topic - that would work, and you probably get the most productive team ever. However, you don’t need to be an expert in HR to understand that it is hard to find even a dozen people like this. The beauty of working in a team is the ability to emphasize the strengths of each team member and use the difference between experiences, skills, and intelligence to build truly great products. Cross-functional teams, when understood correctly, are a powerful tool. They are the state where the team is able to solve all the problems by having all the required knowledge in-house. They are able to go from the design stage to production, and even further - actually evaluate what has happened with the increment and whether customers are satisfied with the result. Instead of looking for people who are doing everything on their own, it is more realistic to look for someone who is T-shaped. These individuals are experts in a field, but when it comes to the required skills in other areas - they know enough to be able to communicate effectively and together create a powerful combination of skills that can help the team achieve its goals. When experts in different fields collaborate, they are able to contribute their best to the common goal, providing the best knowledge one could imagine and upskilling the side elements of their T-shaped colleagues. Self-Organized Self-Managed Teams Self-managed teams terminology was introduced into the Agile community in 2020 when it was simply been used instead of the self-organized team. When asked why they have done this, they responded that self-managing teams not only implement what has been defined by the Product Owner of the project sponsor but also contribute to defining what will be implemented next. While a minor change, this is a significant extension of the fact that teams can succeed with proper empowerment and the ability to influence the end state of the product. The key difference here is that self-management includes what work to do and when to do it, in addition to how it was already there. What’s Next? We should focus on something other than the difference between self-organized and self-managed terminology. What is more important is that all three should be united. Having all the necessary skills in the teams and providing them with enough authority and empowerment to deliver what matters to the customer is critical to achieving the actual state of agility and delivering outstanding results. Everyone involved in the process must focus on the way the work is done rather than the wording of terminology. However, as the industry is flooded by fake experts who have done a one-week training and achieved certification, everyone in the team should be able to distinguish what matters and what to embrace. What misconceptions about Agile methods and terminology have you encountered? Share your thoughts in the comments. If you recently graduated from the University - there is a high probability that you have never seen a waterfall software development process. Most likely, all you have had experience with is some sort of Agile framework. However, even if you have been taught from a blank page and don’t have any legacy thoughts in your head - you are probably still influenced by common misconceptions that came from the era of early adoption. One of the most misunderstood topics in the community is how teams are structured and managed. We can’t trace where this comes from, but for sure, it originated somewhere from the way Agile was adopted—people jumping into implementation without getting it right. This is, in fact, the way we would like Agile to be embraced. However, they go off the road when the above-mentioned implementations are not being revised and adopted. Cross-Functional Teams. The common misunderstanding is that if the team is cross-functional - that means that everyone on the team should be able to juggle all the topics. Backend, frontend, DevOps, quality assurance, you name it. In general, this idea is not so bad, and if we fill the team with absolute superstars who are proficient in every topic - that would work, and you probably get the most productive team ever. However, you don’t need to be an expert in HR to understand that it is hard to find even a dozen people like this. The beauty of working in a team is the ability to emphasize the strengths of each team member and use the difference between experiences, skills, and intelligence to build truly great products. Cross-functional teams, when understood correctly, are a powerful tool. They are the state where the team is able to solve all the problems by having all the required knowledge in-house. They are able to go from the design stage to production, and even further - actually evaluate what has happened with the increment and whether customers are satisfied with the result. Instead of looking for people who are doing everything on their own, it is more realistic to look for someone who is T-shaped. These individuals are experts in a field, but when it comes to the required skills in other areas - they know enough to be able to communicate effectively and together create a powerful combination of skills that can help the team achieve its goals. When experts in different fields collaborate, they are able to contribute their best to the common goal, providing the best knowledge one could imagine and upskilling the side elements of their T-shaped colleagues. Self-Organized Self-Managed Teams Self-managed teams terminology was introduced into the Agile community in 2020 when it was simply been used instead of the self-organized team. When asked why they have done this, they responded that self-managing teams not only implement what has been defined by the Product Owner of the project sponsor but also contribute to defining what will be implemented next. While a minor change, this is a significant extension of the fact that teams can succeed with proper empowerment and the ability to influence the end state of the product. The key difference here is that self-management includes what work to do and when to do it, in addition to how it was already there. What’s Next? We should focus on something other than the difference between self-organized and self-managed terminology. What is more important is that all three should be united. Having all the necessary skills in the teams and providing them with enough authority and empowerment to deliver what matters to the customer is critical to achieving the actual state of agility and delivering outstanding results. Everyone involved in the process must focus on the way the work is done rather than the wording of terminology. However, as the industry is flooded by fake experts who have done a one-week training and achieved certification, everyone in the team should be able to distinguish what matters and what to embrace. What misconceptions about Agile methods and terminology have you encountered? Share your thoughts in the comments. What misconceptions about Agile methods and terminology have you encountered? Share your thoughts in the comments.
