The team contract...

Jon Strickler triggered a great discussion about team charters and the items a team needs to be successful from the start. He focused on things like the why, what, who, and when questions.

I had to contribute a few Agile specific items to the list. I feel it is important that the team not only have a charter that governs it from above, but also a contract that governs it from within. For example:
"How will they handle failed tests or failed builds? Are they committed to pair programming or TDD? Are customer demo’s done at sprint review or throughout the iteration? Do standing meetings start on time or when everyone is present? Without these agreements, the team won’t be in sync with one another."

How to handle interruptions...

There is a great discussion about how to handle interruptions on InfoQ. In many environments, teams have to not only build a product, but also support that product's existing customer base. Fires arise all the time that diminish productivity and velocity for the team. How can this be handled?

Suggestions included:

• separate backlogs
• emergencies (work stops)
• manage support like features
• sacrifice someone

Having seen Alistair's presentation at Agile 2007, this was one of the points I wanted to add to in the discussion. The "sacrifice one" idea is described properly in the post as: "assign one person dedicatedly to take care of that interruption. Though, this one person would feel sacrificed, rest of the team can make progress by working on the primary task."

My thoughts:
"As for Alistair's idea to sacrifice one team member, I do believe he supports that this is a rotating role (per iteration or sub-time window)... and that it is important to assign your most important person first to make it clear that it is an important role and is not dumped on the newer/weaker people in the team. Otherwise, it can become something that breaks the team dynamics into a group of superstars (those that create) and pledges (those that support)."

The Boundaries of a Sprint...

How do non-developers get involved in the iteration rhythm? How does a business or UI person have all the answers on the first day of the sprint when developers need them? This is a great problem and people learning scrum seem to evolve through different levels over time.

This was the point to Karl Scotland's MMF post, and he did a great job of modeling it for easy digestion.

I commented on the sprint boundaries in general and my experiences through this process in other teams and how it was predicted by our agile coaches at the time.

Technical Elitism...

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."

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.

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)"

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-

• 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.
  

Bad time to split a 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.
  

This is bad because it can't be delivered. It destroys the "functioning software" line in the agile manifesto.

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.