Question

This isn't a specific support request, so much as just a general request for advice or blog posts or knowledge base threads you might suggest I read.

I work on a team of web application developers and we've been using FogBugz for I think about four years. And yet, we've only begun to scratch the surface of all that FogBugz can do. We don't take advantage of EBS, we don't click the "working on" links, we don't use discussion threads or wiki's for anything outside of documentation some of our own team's assets. We don't use RSS threads. We don't integrate with our Subversion repository. We don't encourage customers to use the screenshot tool. We don't organize our projects into phases or milestones. All of our developers have administrator rights, so projects often overlap, with no consistency in categories, status, etc. Probably 80-90% of our currently open cases have just been forgotten about.

We really don't do much more than just accept cases emailed to our popmail account and close the case, without really associating the case in any way with a bigger picture, timeline or agenda.

I've tried hard to educate the team on all that FogBugz can do and I do happen to use EBS reporting and many of FB's more advance features, but usually only for an audience of myself. Management is always asking for pretty much exactly what EBS gives you. But there's nothing to look at because my colleagues aren't populating it with data by being disciplined about making estimates, writing good cases, and clicking on "working on"...

The excuses range from "I don't need Big Brother watching me all the time" to "that's not the way we work around here"... Just wondering whether anyone can suggest something I might get my colleagues to read, a webinar to watch, maybe on-site consultation services from Fog Creek... I know my problem is really just cultural. But I was hoping others could share insights on getting a reluctant team to organize their workflow around this fantastic tool.

PS I realise the http://fogbugz.stackexchange.com/faq advises "Avoid asking questions that ... require extended discussion. This is not a discussion board, this is a place for questions that can be answered!" But I don't know where that place is...

Answer 1

Great question, and one I suspect many struggle with.

I got enough Fogbugz licenses for my entire team plus support, plus sales consultants - about 20 something in total. I've been able to get subteams using it for a while - and by using, I mean enough info to make the EBS make sense. But even then, there has been some holdout. I now have one team who are really using it well, with very little nagging from me.

But it feels harder than it should do. And trying to get more teams using it is hard.

I think the problem, as you say, is cultural. If you have a bunch of people who are largely heads-down-pound-out-code people, it's always going to be a really hard sell to get them to use any tool that may benefit the team, targets, and therefore company as a whole. They think their job is to write code, and don't see that code is just what they write to deliver a service or a product. Of course, they will say that it is the latter, but their behaviour indicates true belief in the former.

The solution is to somehow encourage a heads-up approach. My team who are using FB well, and helping me with my EBS, are pretty much heads-up guys. They look around for things that will make their job easier - which basically comes down to removing obstacles. I see FB as a big obstacle clearer, but people confronted with it who are in a rut see learning it as a huge obstacle.

My main message on FB is that it allows us to manage that most important resource in software developent - time. So I show them EBS, as everyone is concerned with deadlines. I show them it is dynamic, and the thing most people struggle with is juggling priorities. FB is great at helping manage priorities in a very fine grained way. I kind of hint that if you can't prioritise your work, you don't really know what you are doing, and that using FB can develop this skill.

A bit of a sticking point is time recording and estimating. This can be very emotive, and software engineers generally are very sensitive to this. They obsess about the accuracy of their time submissions, and whether they should include coffee breaks or not. They worry their total time is being judged and looked at by senior management, and some fixate on their personal EBS record and strive for that perfect prediction record. But that's irrelevent. Again, a session showing EBS's variance and emphasis on probabilities rather than absolute dates can help here.

What will break an engineers trust in the time system is any hint at all that these are used for performance/reward judgements. They will then game the system, and you lose all value in EBS - it will always tell you what you want to hear, right up until ship date when you realise you can't. At which point, the earlier doubters rise up and say EBS/FB is useless, and revert back to previous behaviour.

Not sure how much help that's been - it's a bit of a ramble I suppose. But I'm in a hurry and need to write a report that tells senior management when we're going to ship :)

*PS: If any of my guys are reading this, we don't use timesheets for anything other than EBS purposes!

Answer 2

Sounds like the first thing you need is either a big shift with the development or a push from management. Much like SCM, once you know how much it will improve your life and productivity, you don't want to go without.

In our environment, the initial push for an issue tracking system was a typical pro/con comparison and a look at where our problems were at the time. Identifying items (e.g. bugs) that were missed or forgotten in the past that have caused present problems can show to management why the system is needed and needs to be used.

It's not surprising for many to be reluctant at first. Even starting small and using additional aspects of FogBugz as you go along can help (both with workflow and adoption). There is no reason for everyone to be an administrator. As it is, most users can do anything that they need or desire.

Here is what we've done:

1. Started with just the major projects that we have, leaving only the miscellaneous area.
2. Use a wiki for documentation and specifications.
3. We're working on using estimates more as well. EBS produces some good results, but we haven't used them a great deal yet. I usually don't remember to use the "working on" action but use the timesheet or manual elapsed time entry.
4. Regular meetings where we review new cases and all cases that we marked to keep an eye on along with anything due.
5. Any cases that have been postponed for a later version are reviewed on a regular basis (every couple months).

We don't use the discussion boards (and the link is even hidden). If anyone is using RSS, it's at a personal level (such as in the browser). We start using features as we need them so as not to overwhelm anyone. We don't currently use the system directly with customers. Testers and engineers may use the screenshot tool, but that's about it.

Bottom line, one of two things need to happen:

1. The team needs to push for ITS usage because of their own frustration or desire.
2. Management needs to start pushing or requiring -- it can be for a portion at a time or a gentle push.

There can also be someone appointed, as part of their duties, to make sure cases are categorized well, etc. In that environment though, I don't think I'd volunteer.

Answer 3

"Management is always asking for pretty much exactly what EBS gives you."

That sounds like your potential win right there. Get management convinced that EBS is the hotness.

Answer 4

Great question. I've wondered about all of this as well.

My hangup is: where do you log generic "professional time"? ...things like reading industry blogs, watching web casts, water-cooler talk, taking a phone call here and there, etc.

Since the Working Schedule page forces you to account off 100% of your day, but 20% of your day is spent on miscellaneous professional time, how do you account for it?

The only two work-arounds I can think of are to either create a miscellaneous "bucket" case for such tasks, and insert intervals against that case in your timesheet.

Or

Set your working schedule not from 9-5, but from, say 10-4.

Problem with the first approach is that it's tedious and the case can't have an estimate, since it goes on indefinately.

Problem with the second is that you don't record intervals accurately - but maybe that's fine. Just feels clunky.

What do other folks do?

Answer 5

Thanks for the prompt answers folks! I'm eager to hear from others if anyone has thoughts...

@msemack: Agree that's the best angle to pursue. Problem is I think there's already a little resentment going around. But maybe it'll just take time.

@Kris K.: I like your 4th point: regular meetings to review all cases together.

@Greg Whitfield: Really good point: "What will break an engineers trust in the time system is any hint at all that these are used for performance/reward judgements. They will then game the system, and you lose all value in EBS" I almost wish there were some way for FogBugz to offer developers a level of privacy with their timesheets. Sure I suppose you could piece it together by looking at the cases they're working on. But if there were an option in the Administrator console to generally conceal time sheets from management or even from each other. After all, it's the estimates that drives EBS...

I guess, come to think of it, Administrators can't really see a developer's actual working schedule, can they? I can see "Per User Timelines" in Reports. Your P.S. kind of gets to the heart of the issue: I think people do fear that management will use the timesheets in calculating compensation.

But then, and forgive an even more rambling response, I guess FogBugz allows you in your schedule to claim to only work cases, say, 50% of the time. So long as you generally are, then so long as your estimates are good, EBS will work fine, right?