tracker, but the phrase "CMMI compliant issue tracker" is an oxymoron.
Post by Cass Dalton ***@gmail.com [SCRUMDEVELOPMENT]We have to use a CMMI compliant issue tracker to track stories, bugs,
etc to meet contractual requirements. But my teams always also use
stickies on a whiteboard and the SM keeps the two in sync. The issue
tracker (Jira Agile) is tied into the code review and CM tool (Stash),
so the issue tracker is part of the workflow, but I like to keep
something that gives an "always on" and visceral representation of the work.
__
Yeah, having too many bugs that aren't bugs is essentially the same
problem I was describing with a similar solution.
BTW, I don't really recommend having bug triage "meetings". The way
I would prefer is to look at the bugs right when they arrive, stop
the line if they are critical, put them on a card and give it to the
PO if they need to be fixed but aren't critical, push the delete
button if they are duplicates or you won't fix them. That's my
rather extreme :-) version of triage.
Also, bug tracking tools are awful. They seem like they're a way to
enable communication, but they're actually a way to delay it. Put
important stuff on the wall where people can see it. Let the
customer talk to you in a chat window, on the phone (or video
conference), or preferably in person. Just say no to bug tracking
tools.
__
Hi,
There's another reason to do bug triage that hasn't come up yet.
It's when you have too many bug reports - but not many actual bugs.
* The large client has very aggressive deadlines
* Several business units inside the client will benefit if the
project fails
* Your business has signed SLAs on defect fixing (in integration
test environments)
* The client raises every defect as "severity one" giving you 2
days to fix each defect.
* 95% of the defects are in the order of "working as designed",
"duplicate", "this was your requirement", or "function not
implemented in this drop as agreed".
* The client refuses to listen to anyone except for a member of
the development team. Also, few people in the organisation have
sufficient knowledge to classify the defects properly anyway.
The only way we could handle that particular environment was to
setup daily defect triage meetings with the client while we
increased knowledge in our org and tried to manage the client
better.4
Tim
__
If you are doing bug triage you have too many bugs. That is
why the comparison to mass casualties is apt. If you have
too many bugs there is a flaw in your team's communication
that is allowing potentially costly mistakes to get too far
down the line, possibly (probably) into the hands of the
customer. Whether you are a developer, a customer, or a
business owner, you don't even have to know what a manifesto
is to see the problem there.
If you are not doing bug triage that does not necessarily
mean that you don't still have too many bugs. You need to
work on your team's communication process to eliminate the
source of the bugs (By "communication process" I mean to
include planning, testing, and handling feedback from
customers.) You may also want to pay particular attention to
bugs that are costing you money without derailing the rest
of your process. Triage may be an effective stop gap if used
appropriately.
All of this is somewhat orthogonal to Agile. I'm actually
using more of the Lean part of my brain above, but I don't
think there is any conflict between the two on this (nor
most) issue(s.)
The main symptom is you have too many defects. The solution
is two-pronged: figure out why you are creating them and
address the root cause (hint: it's a communication problem,)
and build a safety net to catch them earlier (TDD, pair
programming, continuous integration, etc.)
__
While I can wholeheartedly agree that bug triage is
certainly a smell that there is something blocking the
organization from becoming aware of and correcting
defects sooner, there is a dogmatism to this response
that is striking. The linkage between behaviors in the
Scrum Guide and the overall notion of "Agile" is harmful
to the overall community. Pair Programming is also not
in the Scrum Guide -- does that mean it has "no place in
agile?"
Others have their own beliefs about how to embody the
Manifesto -- judging their activities against the Scrum
Guide is just plain shortsighted and reinforces the
mistaken notion that the two are one and the same. They
aren't. And the sooner we can embrace that and embody
the distinction with our clients, the better off they
will be.
I would also be extremely careful about calling people
"unagile" -- this practice may be the next step for them
in creating an authentic, human-oriented process that
accepts and responds to feedback as quickly as it
possibly can. While we should be holding everyone to a
higher standard, it is extremely unlikely they will come
along if we bully them by telling them they are wrong
all the time.
My challenge for everyone who coaches Scrum and other
kinds of agile teams: what is the good in what they are
doing? How can you take that strength and call it out in
them? What is the best way to motivate people to move
even further beyond their current predicament?
What problem are they trying to solve with bug triage?
How might they get to the root cause of the problem?
What would allow them to use this solution to its best
effect without becoming addicted to it so they can later
wean themselves off of it?
Wielding the hammer of "that's unagile," in my view, is
not likely to get them there.
--
Tim
021 251 5593
http://www.linkedin.com/in/drtimwright