UserVoice: Using A Customer Service Tool To Democratize Technical Debt

Not sure if you anyone has heard of or used “UserVoice” – It is a site that allows you to create “forums” for your products and then submit ideas, give users votes and they can vote them up, and an admin can say things are started, merge ideas, or mark when the idea has been completed (and the votes go back to the users).

UserVoice is (sorta) along the same lines as GetSatisfaction (another cool customer service 2.0 app). Pretty cool tools. If I was in a customer service role, especially with any type of user based or public product, I would be running these tools to gather ideas and feedback from my users.

I am in a technical role, so what I decided to do was “democratize” the development area of our product one of my teams is working on. We have a ton of technical debt (as do most teams, it is just a matter of what level of debt you have) – but what should we work on next from a technical perspective?

In comes UserVoice. Let’s throw out ideas on UserVoice, give everyone 50 votes, and the ideas that bubble to the top will become our next set of things to work on. One “idea” may become several “user stories” (we are agile). Our goal is to have 20-25% of our stories focused in on paying down our technical debt. If we didn’t, the debt would never get down to a low enough point to where we are very comfortable.

What is cool is that it really shows what the team wants to focus on next. People can have others vote up their ideas, etc. Also, getting the votes back at the completion of an idea is key. As you can imagine, our forum is private. The one cool thing about UserVoice is you can create multiple forums, with different ranges of settings, so you could also have a public forum, or a different private forum for a select group of users, etc.

One thing I wish I could do is maybe give different # of votes to different users. Integration out of the box with TFS or other systems would be nice too, I haven’t looked to much into that though.

If you have a team that ranges from medium to large, I would suggest checking out UserVoice to get the ideas and opinions of the members out on the table regarding your technical debt. You may be surprised as to what gets voted to the top!

Agile in Business Intelligence? Of Course!

About 3.5 years ago I was introduced to Agile at the Agile 2006 Conference. After that, and implementing it in a software dev environment, I found that it just works. Sprints, Scrums, Stories, Backlog, Velocity, all the pieces fit and work.

Now that I am managing a Business Intelligence group, which when I started wasn’t doing *anything* as far as a method, I had to ask myself if doing Agile would work (I knew it could, but it is different than software dev in many ways, similar in others).

Back in October, my group went Agile. We set up a board, got some index cards, and just started Agile. A big paradigm shift at work for IT, but we needed to do something.

With Business Intelligence, we really don’t have *code* to work on, but more “objects” (Cubes, Dimensions, Reports, etc). As a team we needed to figure out – what is a story? What is a feature/enhancement/task. What is an epic? How are we going to score things, etc.

The first few sprints (2 week sprints – Wednesday’s to Tuesdays) our velocity was lower and/or we just scored things a little weird. But since then we have learned our “zone” of scoring stories and we got into a groove of releasing our BIG cube every 2 weeks, and releasing the smaller changes when completed.

We do the daily *scrum* for 15 minutes, and track burndown on stories, which lets us make some cool burndown charts that we tack up on our board, and we have some other cool bullet charts to track velocity by sprint, to our original, and final goal, and more.

What has Agile brought our group? Confidence, Stability, Ability to Meet Expectations. Agility. Results. and more..

Do we run into issues yet? Of course. Can we adjust and handle them. You bet! Are we continuously learning and changing our process to make it better? Yep. Always room for improvements.

What else does Agile bring us? Visibility to our customers, and to our peers in IT. Eventually the “BI” stuff should just run, over and over, iteratively.

Trek BI Agile Story Board

Agile isn’t a silver bullet though. It isn’t easy. You still need to work to keep things organized and on track. You have to fight that organizational gravity that sucks teams back in and people in as well, and throws that scope creep back onto stories and projects. You also have to fight to get rid of your technical debt, which depending on how long things have been running before you started even thinking about Agile, might take you a while.

This post is more of a high level “Yes We Can” type post about Agile in BI. I haven’t decided yet, but my guess is I might have some more detailed posts on how I like to run an Agile project, and what we are doing as a team to handle situations that come up, and just how we do things.

In the end though, just remember, have fun!


Agile 2006

I attended the Agile 2006 conference this year, and it was a good conference. Information overload, as usual. I still need to go through all my notes and powerpoint slides and make heads or tails of alot of things. Two of the most intriguing speakers were Scott Ambler who talked about Database Refactorying and Agile Database Design, and Michael Feathers, who talked about Agile in general, Coaching, and Dealing with Legacy Code. Other good talks from Ward Cunningham, Ron Jeffries, and the like. A few of the sessions I started out in, I ducked out as they werent what I expected, but overall the sessions were good and gave good info. Ill look to post up more info on Agile and things I find useful in the future.