Jordan Bortz posted a great rant about technical elitism and questions why tech folks are so quick to make judgmental calls based on a technology. Geeks believe they are in a superior position just because they know or use something that someone else doesn't. How many times have you observed the MS vs xNIX debate?
My nugget: "Somehow we have driven ourselves towards the concept of better, and not focused on the concept of appropriate. Unfortunately, “better” is in the eyes of the speaker whereas “appropriate” is defined by the view of the surrounding group."
Random comments on interesting posts within the agile software development community...
Monday, June 30, 2008
What do to with found bugs...
As a customer I tend hang out in the VersionOne google-group user forums. Sometimes I find myself providing agile coaching feedback unrelated to the tool. Today was one of those days.
The discussion was surrounding the tool and what to do when a tester finds a bug.
Option 1: reopen the old story and tasks
Option 2: enter a new story or task to fix the bug.
I pushed the discussion towards the process issues and impact.
My summary point -
If the customer/product owner can live with the bug and it is not critical to release, then option 2 might be acceptable to save time and focus on prioritized business value.
But if delivery can't be reached without the bug being fixed, and especially if the bug was injected while working on that story... THEN THE STORY ISN'T DONE.
It's painful to re-open a story and go back to something the team believes is done and wants credit for. But this is our job. The quality criteria is deliverable and working.
If you buy a burger and it has a fly in it... you expect it to be fixed or replaced. You don't go back to the counter and get charged for a new one. Just like the restaurant doesn't get to charge again, neither do you. Your team's velocity is no different than money in a restaurant.
The discussion was surrounding the tool and what to do when a tester finds a bug.
Option 1: reopen the old story and tasks
Option 2: enter a new story or task to fix the bug.
I pushed the discussion towards the process issues and impact.
My summary point -
If the customer/product owner can live with the bug and it is not critical to release, then option 2 might be acceptable to save time and focus on prioritized business value.
But if delivery can't be reached without the bug being fixed, and especially if the bug was injected while working on that story... THEN THE STORY ISN'T DONE.
It's painful to re-open a story and go back to something the team believes is done and wants credit for. But this is our job. The quality criteria is deliverable and working.
If you buy a burger and it has a fly in it... you expect it to be fixed or replaced. You don't go back to the counter and get charged for a new one. Just like the restaurant doesn't get to charge again, neither do you. Your team's velocity is no different than money in a restaurant.
Thursday, June 12, 2008
TDMeetings...
Brett Schuchert of ObjectMentor extends the concept of TDD to driving positive meeting outcomes. It's a great idea, and this is the first place I've seen it. Meetings have the same problem of scope creep and deadline overrun that projects do.
The debate after the post led to other methods or frustrations about meetings. I strongly believe that "...there are no open laptops or phones in my meetings! I say, stay engaged or stay out. (unless it’s a CxO of course)"
The debate after the post led to other methods or frustrations about meetings. I strongly believe that "...there are no open laptops or phones in my meetings! I say, stay engaged or stay out. (unless it’s a CxO of course)"
Tuesday, June 10, 2008
Splitting a story...
An interesting conversation in the VersionOne user group sponsored this post:
When should a team split a story?
Good time to split a story-
The team can't take credit for work unless it is "done" and adding business value to the user/customer.
These examples are over-simplified for this conversation, but many times it is not this black and white. Unfortunately, this second approach is done way too many times.
When should a team split a story?
Good time to split a story-
- Story -> Allow user to login
- End of sprint -> The user can login by manually typing username/pwd, but system won't remember them the next time they return.
- Outcome -> Release software as is and split story into "User can Login" and "User can login without having to re-enter credentials next time." Get credit for first story but not second story.
- Story -> Allow user to login
- End of sprint -> Stored procedures are done, but UI isn't.
- Outcome -> split story into back-end and front-end work to get credit for work completed. Let DB move on.
The team can't take credit for work unless it is "done" and adding business value to the user/customer.
These examples are over-simplified for this conversation, but many times it is not this black and white. Unfortunately, this second approach is done way too many times.
Subscribe to:
Posts (Atom)