How do we use Asana, Balsamiq and Google Docs to manage BizTalk360 development, test and release process

Published on : May 8, 2014

Category : General



Like any software development company we have identical challenges in managing a development, test and release process. As a growing company we experiment with different tools to improve our processes and delivery quality, for 7.2 we mainly used Asana as our project management tool.  BizTalk360 7.2 is an important milestone for us in variety of ways. This is the first public release where our team has grown significantly and working in full throttle. There are close to 60 new items (new features, bug fixes, enhancements, design changes etc.)  that are bundled into this release. Managing them end to end requires some level of discipline and process to make it smooth. Our team is distributed, hence all the tools we use are pretty much available online and supports great level of collaboration. We are still in experiment phase to find ideal set of tools to improve our processes, in this post I’ll explain our current working model.

Ideas and Asana Projects

In the previous blog post I explained various sources of inspiration for us to get new ideas for BizTalk360. Now we have a constant feed of new ideas coming our way, and it’s important we channel them through properly, so that the valuable ideas end up in the product at some stage. For this we use Asana projects (Asana is kind of mixture of team communication, project management, task manager, note taker etc). We generally have few projects in Asana as shown below catered for various activities. Asana Project Explorer Asana Project Explorer We will have one major release a year (7.0 in Nov 2013, 8.0 in Oct/Nov 2014) and 2 to 3 minor incremental releases (7.1, 7.2, 7.3 etc.) within a year. There will be corresponding Asana projects for each major and minor releases as shown above.  In addition we will have individual project for each major functionality in BizTalk360 example “User Access Policy”, “Monitoring and Notifications” etc. When we get new ideas from one of the channels, we will either add them to corresponding project categories (ex: user access policy) or to one of the upcoming major or minor releases based on the gut feeling and importance of the functionality. Once we start planning for our next immediate release (ex: 7.3), we will pull the items from various projects and create a new project that will be our next release. Once we assemble the new project (next immediate release), as top priority we will set the approximate delivery date of that project ex: July 2014. This will give us rough ball park figure of how many features we can add to that release. Then we will assign the project items to each member in the team, typically in the regions of 4-5 features per person. The below screen shows our Asana project with all the tasks for 7.2 release. Asana Project Explorer

What is a task?

A task for us in Asana project is a single work item or feature that’s going to be added in the upcoming release. Once the tasks are assigned to team members, they will then build up the tasks with their comments, if the task requires a detailed design document, then that will be created as a Google document and a reference to that will be available in the Asana task.  If the task is something related to design changes or if a brand new UI is going to be developed then we will wire frame the user interface using balsamiq.  We use the hosted mybalsamiq SaaS version, since our team is located remotely it makes it easy to share the wire frames. Below screen shot shows one of the tasks with multiple comments between the team members. Asana Project Explorer The task will start with a team member and during it’s life time before it gets completed it will get assigned back and forth within the team based on the dependency. If a task is assigned against your name, then it’s your responsibility to take action, put appropriate comment and assign it back to either original task owner or someone else based on the dependency. Ex: A front end work may be started, but at some point there may be a dependency with the backend API where the front end developer cannot proceed further. In that case he/she will assign the task to the backend person to finish the work. Once the backend API fix is done, he/she will reassign the task to the front-end developer. This way it’s easy for each one of us in the team to take a quick look at Asana project every day and see what’s assigned to them and take appropriate action.

Daily stand-up calls

We will have a daily 20 min’s stand-up calls in an agile way to go through the project/tasks and if there are any challenges it will be highlighted. The team members will also give a quick update on the tasks they have completed the previous date.  These meetings are strictly limited to 20 minutes duration. If anything gets side tracked, the meeting master will ask the members to take it offline. We use Asana’s “Tasks By Assignee View” for these meetings, which makes it easy to go through the list. From technology front we use GoToMeeting for the stand-up calls. We have a recurring meeting invite on our calendar with all the GTM details, just a single click we are all on the virtual meeting room. Asana Project Explorer

Tasks Lifecycle

We mentioned previously the tasks will get assigned back and forth between the team members during it’s life time based on dependency. The ultimate goal will be to complete the task, get it to the build team and then to QA team. We use the tagging system in Asana to accomplish this. Once the task is completed the developer will tag the task as “QA-Ready” and assign it to the person responsible for the the build. For every release, only one person will be responsible for the build and deploying it into our development backend server. Once the build is deployed into the development server, the build person will assign those tasks to someone in the QA team adding the comment in the asana task mentioning in which version the task is included. The QA team will then perform the QA activities and if there are any bugs identified, the task will be assigned back to the developer with comments or if it passes the QA process, “QA-Ready” tag will be replaced with “QA-Complete” tag. Asana Project Explorer

Balsamiq for wire framing

BizTalk360 is a web based application with a rich front-end user interface. It’s inevitable from time to time we will need some kind of wire framing capability. We have chosen mybalsamiq, the online version of the famous wire framing tool balsamiq for this. Whenever there is a new UI requirement we will brainstorm the idea using wire frames, mybalsamiq allows us to collaborate online and add references to the wireframes into our asana tasks.   Below is an example for rules policies view we are planning to bring in vNext of BizTalk360. Balsamiq Mockup

Design documents in Google Docs

As I mentioned earlier, once we assign the task to a team member  and if it’s something complex and requires some analysis and design/architecture document we will spin off a Google doc to capture all the requirement and add the link to the corresponding Asana task. The design document is a standard word document that will have detailed analysis of the task, this will also help the QA team to build up their test cases.  There are few great advantages of using Google docs instead of sharing files via emails. First we avoid multiple versions issue sharing files in email and two it allows to collaborate real time. Google Doc Technical documents