I'm not looking for advice how agile process should work. I know that part. I'm curious what the best way to adapt the process to a typical large, well-established corporation who loves its "processes" and gate/passport reviews.
For those lucky enough not to know what they are, gates/passport things are essentially waterfall milestones presented by development teams to executives: Gate 0 – kick off, identifying positive npv projects; Gate 1 – planning work for the release, coding begins, Gate 2 – code complete/testing phase, Gate 3….
While within our team we've tried to embrace agile as much as we could (peer reviews, iterations, constant communication, doing what makes sense, continuous improvement…), these gates come from way up and there's nothing we can do about them.
Of many things that bug me, one of them is that the corporate environment we are in, imposes some constraints which seem to have adverse effects on how we work. One example is that during development we only focus on new features and ignore existing bugs and even introduce new bugs. This is unfortunate and goes against agile, but we have no choice since code complete could be in 2 months, but "testing/bug fixing" phase can last 6 months after that. We are under constant pressure to "finish work" but emphasis is on completing features, not getting a stable product. This part we sorta learned to live with.
My question is what strategy (successful mode of operation) other teams/companies have found for the "testing" phase that follows a "code complete" milestone?
During "new development" we have iterations and each one gets filled in with stories and tasks. However, currently once development is "done", there's no more iterations and no more planning. Instead, we solely use bug tracking database to monitor how many new bugs are being found and how fast the bugs are being resolved.
Personally, I don't see the difference between adding new UI feature and making existing UI feature work. To me work is work. I proposed that we continue having iterations as normal and continue to schedule work as before, but neither management nor other team members seemed to be on board with that. So 1) am I way off and is bug track database the best we can do? and 2) if there's a better approach, I'd like to explore it and maybe acquire enough ammunition to take back to my boss. At the same time I somewhat agree that a lot of times when reacting to bugs we don't have the luxury of waiting till next iteration.
— Slight clarification based on first few responses —
We just entered the testing phase. At the moment, there's no more stories, no more iterations. Only bug tracking database. That doesn't sit right with me, that's why I'm curious what other teams would do in this situation. Also some bugs are definitely the size of a medium size story, while other bugs would take 5 min to fix. Should 5-min bugs also become stories if we were to continue with iterations? The other argument we've been having is that during "new development" we only interact with Agile tracking tool (Rally) but in "testing" if we continue with iterations, we'd have to maintain paper trail in Rally as well as in bug tracking software.
Best Answer
I don't think you'll really get anywhere without reworking the way things are done right now.
I am fairly certain that this is a grave mistake. Try to explain that bug fixing becomes more difficult and more expensive the longer it is postponed. I don't think there is any excuse for postponing bug fixes for so long.
All agile methods I know emphasize that the software should be technically ready to ship at the end of each cycle/iteration (or even continuously). That means any bug that you wouldn't want to ship must be fixed before any new features is started.
Try to work with people, and explain your concerns.
Finally, if you cannot get any kind of agreement on such basics, it may be best to move on.
Edit
Based on your amended question: I agree that bug fixing should be handled just like new features. I'd normally have single tasks for "small" bugs (up to a few hours) and stories with subtasks for "big" bugs (multiple days, possible to split into tasks). If your colleagues do not agree, point out that the advantages of agile methods apply to bug fixing just like to new features.
As to wheter to use an agile tracking tool or a bug database: Ideally, the two are integrated. If they are not, then yes, you'll have to track work in both. It's annoying, but I've done it myself, and didn't find it a big problem. You track bugs as usual, and just copy&paste the bug id into the title of a task/story when you schedule a bug to be worked on. The task is just a link to the bugtracker (eays if both are web-based), and all discussion is in the bug db. If you link consistenly, you could probably even run reports across both systems.
Finally, it you believe you cannot change the way development is organized, you'll have to work within these constraints. Things like introducing some agile methods into the bug fixing phase will probably help.
Still, I am convinced that splitting development into a "feature phase" and a "bugfixing phase" is a grave, possibly fatal mistake. It may not be so serious for your company (every situation is different), but if it is, and if your organization is unable to change this, then your organization may be so dysfunctional that you'd be better off elsewhere. But that is your call to make... good luck!
Edit 2
Finally, if company policies dictate "features first, bug fixing later", maybe you can sidestep them, e.g. by redefining bug fixes as new features (the difference is often a matter of opinion anyway). To some extent, you can try to introduce new ideas "from below" that way. You know, "if you can't beat them, join them".