Internally, to help track all of the things, our good friends at Salesforce, use a homebrew project management system called “GUS” — an acronym for “Grand Unified Strategy” (blog | webinar). The Salesforce GUS came about from an effort to consolidate three earlier internal systems: Bugforce, Scrumforce, and QAforce. The heart of the new system is a virtual wall where stories, bugs, and tasks are presented and team conversations threaded via Chatter. GUS also supports seamless integration with a number of other systems like version control tools, build management tools, ERP tools, and so forth.
For the rest of us, there are a great set of commercial-off-the-shelf tools that can provide the same functionality.
Here’s how GUS works at NimbleUser.
Source of truth
Back in the day, products like JIRA were mainly used for bug tracking. Agile teams have long since learned that issue trackers are the best way to track all the tasks, from greenfield development thru deployment, and, then, finally for bug fixes too.
Everything the product development group touches is reflected in JIRA. We create a JIRA issue for every kind of product task that needs to be done, development or non-development. We work the issues from an agile board, which shows what we need to do, what’s in progress, what’s being tested, what’s being code reviewed, and, ultimately, what is now done.
The issue objects have a number of social features. Anyone can watch a JIRA issue and see the status changes, or comments added. Comments can also be directed to other users, to pull the right people into the discussion. Folks can also vote to help prioritize an issue. We also log work to an issue and reality-check our estimates.
To help tame the whirlwind, issues can be tagged with a managed taxonomy (components), or you can create a “folksonomy” with labels. The search feature can turn up whatever else you might want to find or list, in both standard or custom fields.
Often, larger stories take multiple issues and even sprints to complete. We use JIRA epics to identify milestone features. Completing an epic usually means it’s time for a preview release that we can share with other stakeholders.
Issues can be linked together to make it easier to see everything in context, even across projects. We also use JIRA to manage our customer implementations, and if a technical consultant has a feature request (or even a defect report) for an open implementation, we can link the issues together. With a link, we can quickly jump between the development issue and the implementation issue, and our consultants can jump in to monitor the progress and provide feedback on the solution.
We even have a Salesforce Case/JIRA integration, so that when customer logs a case with us, it’s easy to followup on the development or consulting task .
Spreading the word
It’s easy to create other integrations using naming conventions with a simple-and-unique issue ID. For example, we name our Git branches and feature orgs using the issue ID. We also link directly to issues from from our Google Doc test plans and requirements (and vice versa), so its easy to see what resource goes with which issue.
JIRA supports release management, and as we ship patch, preview, and release versions, we can see everything that was done for an issue, and which version got it out the door.
Today, we’ve started to use JIRA for non-development projects, like hiring new talent, and planning Nimblepalooza!
Communication hub
Using tools like Hubot and Zapier, our hub integrates well with JIRA and other external systems. A blocker issue means we stop everything and regroup to fix the problem as quickly as we can. When someone files a blocker, a link to the issue is posted to the hub and highlighted. (We’re also working on claxons, flashing lights, and a ringtone for our phone)
Happily, we don’t get a lot of blockers, but when we do, it’s nice to have the hub watching our back. We also have agents watching the trust and status sites for the various cloud products we use, which post to the hub when someone else is having issues.
We can even request trial feature orgs, directly from a chat post. By directing a message to @doggles (our Hubot agent), we can setup an environment, assign ourselves to an issue, check on an issue’s status, and more.
For example, typing
@doggles forge me AMS-1234
into HipChat calls out to a signup web app we have running on Heroku that pushes a SignUP API record to our signup org which provisions the trial. A few minutes later, a shiney new development environment is ready to rock!
Automatic builds
For example, a build server can watch Git for changes. If a feature branch is merged back into develop, we can migrate the new tip to our development source org. At the end of the sprint, we provision a new template, and create a trial org for quality assurance or “readiness” testing.
When develop is merged into our packaging branch, we migrate the latest bits to our packaging org, and upload a new version, that we can install in our internal orgs and consider for customer deployments.
And don’t get me started on how we use NuGet to maintain external integration sites …
You can GUS it too!
Start now: The cloud is only the beginning.
Are you using an issue tracker now? Does it connect to version control systems? What hooks do you need to pull it all together?
