How did we use our BizTalk360 7.2 release for team building activity?

The BizTalk360 team had grown considerably in the past few months. When you grow so quickly, it’s inevitable you’ll face some challenges around the processes in the company, the company culture, bringing everyone up to speed etc., – known more as the classic scalability issues. We thought it will be a good opportunity to capitalize on our software release cycle and use it as a platform to achieve few things like

• Team Communication – knowing each other
• Understanding the product
• View/Test features with fresh set of eyes
• Flush out cosmetic bugs straight out
• Identifying areas of product improvements
• Identifying areas of process improvements

While pretty much everyone in the team was working in silo (in their specific areas like testing, development, design etc.) focused on the 7.2 release, our objective was to bring them together and break the ice. After looking at few options, we thought a day long “Bug Bash” event will bring the whole team together, which will perfectly suit our scenario. Wikipedia has a great description for “Bug Bash”, for those of you who are new to the concept

In software development, a bug bash is a procedure where all the developers, testers, program managers, usability researchers, designers, documentation folks, and even sometimes marketing people, put aside their regular day-to-day duties and “pound on the product”—that is, each exercises the product in every way they can think of. Because each person will use the product in slightly different (or very different) ways, and the product is getting a great deal of use in a short amount of time, this approach may reveal bugs relatively quickly.

Let’s walk you through the journey about the goals we set and how we achieved them. Hopefully this will help some of the growing teams to do something similar.

We designed this logo to put forth the message of finding and fixing bugs to deliver an excellent version of BizTalk360.

Team Communication

One of the key aspect of any successful organization is effective communication. It becomes tougher when you work as distributed teams. To fuel the process of getting to know each other and ease the feed-back loop between teams, this activity served as a perfect ice-breaker for this. The India team started around 9:30 AM (IST) with a kick-off note of our goals for the day and the UK team joined in a couple of hours (around 7 AM) later. We had a conference bridge opened (GoToMeeting) and started working together. It was good to see how each member saw a value in what they were contributing and help each other. Helped us to talk to each other and get a good understanding of the product. Some of the terminologies and items which we have to spend hours were learnt in minutes. By sharing knowledge we were able to learn a few things faster.

Understanding the product

When you join a product development company, your first challenge is to understand the product itself. In our case the team members had an additional challenge of understanding something as complex as BizTalk. This exercise shared as a perfect platform for team members to share what they have learned so far, and also ask their questions directly to their peers like Saravana and Ricardo. The feedback at the end of the day was, they learned so much in one single day, which might have taken weeks to understand.

View/Test feature with fresh set of eyes

The other goal we set for our team was to test all the features that were part of this release. Interchanged the modules on which each team (individual) has worked before to provide an opportunity for teams to know about functional aspects of other modules. This provided a significant result of each team member learning about an un-chanted territory in our product. When they were stuck there was other member there to help right-away.  This brought in a greater level of understanding of our product across the team and also helped us to identify a few bugs, usability issues and enhancement that can be made to our product

Flush out cosmetic bugs straight out

There will always be bunch of cosmetic items that needs to be fixed. It’s generally a time consuming process to log them as bugs in your bug tracking system, assign it developer, retest that feature etc. You lose lot of time in the full “Test -> Development/Fix -> Deploy -> Test” cycle. But events like this where you have the full team under your disposal, it becomes easy to quickly address the cosmetic bugs within few minutes.

Identifying areas of product improvements

When we started the “Bug Bash” event, we simultaneously opened a new project in Asana, to capture all the areas of product improvement. The rules are simple, if you don’t understand something easily from the UI, that requires you to ask someone in the team about the feature, then the UI is not clear enough in that area. We captured those for product improvements. We also captured few of the nagging UI issues like scrollbars, grid resize, typo’s in deep pages, etc. All of them are now fed back into our product feature set, which will be addressed based on priority and seriousness.

Identifying areas of process improvements

For any successful start-up its key is how good/efficient your processes are. Most of the start-ups will work on the mantra of “less is more”, with limited set of resources. It’s important you spend less time on internal things and maximize your efforts on more customer facing (benefit) activities, like adding new features, fixing bugs, identify new tools for trade, etc. After the bug bash event we moved from Asana to Atlassian JIRA for issue tracking, and from desk.com to freshdesk.com for support ticket management. We now have new process in place to handle our support tickets, which is derived as a result of the bug bash event.

Summary

We had approximately 60+ featured items in our list for 7.2 release, during our testing we noted around another 50+ items to the list and added approximately 30+ new feature requests. Extreme pair programming, peer review of the code, the right attitude to deliver the successful product was the outcome of our event. We will personally recommend doing this kind of one day hackathon/bug bash bringing the whole team (development, test, sales, marketing, project management, everybody!!) together, you never know how much everyone can contribute or how many new ideas can inspire within a single day. If you are a start-up trying to solve some of the problems we face, hope you got some pointers here, if you have any feedback we would love to hear. After all, our goal is to make a bug-free software & WoW our users!!