A year ago, I got an opportunity to lead an agile team for the Electronic Table Games vertical at IGT. This team was made up of very smart individuals, who put IGT’s name in the electronic table game’s market space within just couple of years. IGT was an underdog in this market, but this team’s hard work and dedication had allowed IGT to bring two successful titles to the market. Even though this team was successful in making this vertical profitable over time, their velocity was not sufficient to keep up with the already competitive market pressure. Thus, I was called to help the team.
Over the year, I have made many tweaks to this already successful team. And hence, I would like to share some of success stories from my experience that have worked for us. I am hoping that you could use these pointers to increase the velocity of your own agile team.
Co-locate your team: After joining the team, I quickly realize that the team could improve their face-to-face communication. Even though the engineering team talked to each other daily, the communication between the QA and Product Management team was infrequent and rare due to their physical proximity to the engineering team. Thus, we went ahead and relocated all of our QA and Product Management resources with the engineering team. This change promoted the face to face communication between the teams and improved our velocity by reducing communication time between the developers and the QA engineers. Obviously, this change was challenging, given my team was located all over the US. But we were lucky to have multiple clusters of the team where more than 4 people were together in the same building. Thus, co-location was practical and beneficial in our case.
Reuse common components: At IGT, we were creating different games, and hence, all the developers were making customized software for each game. Even though we were required to make customized interfaces for each game, given the vertical that we work in, I looked for some common components that we could reuse. To my surprise, I was able to find many communication APIs and other architectural components that were common between each game titles. By making some minor modifications to those components, we were able to reuse them for other games that we were making. Thus, I believe that you should invest some time during your Sprint to look for common software components, which you can reuse to significantly decrease effort spent on building the same functionality. Developing a strong process around this mentality will help you in decreasing product development time.
Increase test automation: You might argue that this is compulsory for increasing the velocity of any software product team, but you would be surprised to see how many agile teams follow this practice. Since the focus of any agile team is on delivering minimum viable products, they often underestimate the investment that they need to make in testing. Thus, most of their testers perform some basic manual tests before releasing the product. In our case, we were able to increase our automation test footprint by providing engineering tools to our testers and investing heavily in test automation as compared to the manual testing. As a result of this change, we were able to improve the quality of our games and expand our testing footprint, which in turn increased our velocity.
Do you agree with my recommendations? Do you have any other ideas through which we can improve the velocity of our Agile Teams?
Thanks – Bhavin Gandhi
Bhavin Gandhi's Blog 