Friday, July 31, 2009

It's About the Product, Not Velocity

Watch out when the team or management are too concerned about velocity.  The problem with metrics, is that people will start trying to game the system to increase the numbers they think that you think are important. Imagine this conversation:
Good day Boss.  Good news, the team has increased their velocity by 125% in the past 4 sprints.
Some bosses would be happy with this, but out of context, this is an inconclusive statement.  That could have been 4 sprints making pixel level adjustments to the UI, or perhaps updating the CSS to use a different shade of green.  What about the product?  What value is being added to the product?

Look at the product and your cost.  Figure out your burn rate for the team per sprint.  Let's say it costs about $10K to run the team for a sprint.  Instead of the quoted scenario above, consider this scenario:
Hi there Boss.  We just spent $10K over the past sprint and this is what changed in the product.  Are you happy with what you just paid for?
Please, make a good product at a good cost.

Friday, June 05, 2009

Quote: Simple Definition of Business

"A business is a collection of rules that manage a bunch of lists."
Camron Shimy

Thursday, March 26, 2009

Trash and Interfaces: Working Together

I took out the trash this morning (please hold your applause).  I wheeled out two trash cans, a green one for yard trimmings, and a black one for other household trash.  This was a very easy task to accomplish where at the end of the day, my trash cans will be empty and I will be able to fill them back up again.  Ah...closure.  How does this work?

Here are some things that help make this work:
  • The point of interaction between me and the garbage company is the street curb.
  • We have a defined transport container.  Rather than throw all this junk on the street, there is are nice, color-coded containers that indicate to me what to put into each container, but also lets the trash company truck drivers know which containers to pick up and which to leave for other trucks.
  • We have a defined time frame
    • The trash is collected between 6am and 6pm.
    • I can control the quality (more of a boolean, but sometimes not)  If I want to maximize my chances of the trash being picked up properly, I need to put it out before 6am.  I also need to make sure it all fits in the containers provided by the trash company.  I can always skip a week if I please.
  • We have a defined frequency, once a week.
  • We have very clear responsibilities
    • I put the cans out
    • They empty them
  • ...and some other minor things that I don't feel like typing.
Wow, that is a lot of coordination.  Here are some points that make this easy
  • My neighbors have the same service and do the same thing, so it is easy to share information about scheduling, overflow, and who to call if there is a problem.
  • This is a standard and repeatable process
  • When the schedule changes (a holiday here and there), I am notified of the new schedule
  • This process is similar to other trash companies in the area, so some kind of "regional industry standard" exists. 
  • I don't care who picks up the trash, as long as someone does.
  • They don't care who wheels it out, as long as someone does.
Why don't you develop your software the same way? 
  • Agree to the same (and clear) goal
  • Work as a team
  • Accept changes
  • Define responsibilites
  • Make it easy to use
  • Provide value
  • Keep it simple
  • Interact frequently
  • Care about what needs to be cared about

Please tell all your friends about this mind blowing article.

Thursday, December 18, 2008

How to Update a Changeset for TFS

There are many reasons why you may need to update a changeset in TFS. If you need to update the comment, please read the post How to Update the comment after check in.

In my environment, I had to do more than this. I have a check-in policy where all changesets must be associated with work items. If the policy is not met, a policy failure can be seen in the changeset reading
You must associate this check-in with one ore more work items. 
This policy can be overridden, but even if you override it, and your changeset is committed, how do you associate a work item with that changeset?

Here is how.
  1. Find the changeset number. You can do this by viewing the history for your project.
  2. Now open a work item that you want to associate with the changeset. 
  3. The work item template should have a "Links" tab. On that tab, "Add" a link.
  4. Set the "Link type" to "Changeset". 
  5. In the "Link details" section, set the "Changeset:" value to the changeset number you looked up a few moments ago. You can also "Browse" for it if you don't like the "History" approach I mentioned above.
  6. Add a meaningful (or meaningless) comment.
  7. Click "OK" 
Now, the changeset doesn't have any policy failures (or at least not related to work items).

Friday, December 05, 2008

Scrum: Accomplished vs. Did, Hidden Impediments?

Think about what you did yesterday and what you are going to do today. You can probably make a list of things. Take a shower, eat lunch, go to some meetings, work on this project, refactor some code, etc.
accomplish 1: to bring about (a result) by effort

Now think about what you accomplished yesterday, or what you are going to accomplish today. You will likely have a different list. Finished reading a book or chapter, got requirements from our customer, verified a bug, etc.
do 3a: perform , execute

In your daily stand-up meetings, be aware of people talking about what they did or are going to do instead of talking about what they accomplished. Regardless of your position on the team (Product Owner, ScrumMaster, Delivery Team member), everyone should hold everyone accountable for talking about accomplishments.

If you have a lot of things to do, where those things don't contribute to your sprint backlog, those things might really be impediments.
Today, I am going to work on the code for the new login system and go to a sales meeting.
Whoa! I hope the ScrumMaster catches this. Is this sales meeting a critical part of the product? Will it interfere with the team's ability to deliver? Is it a 10 minute chat or a 3 hour presentation on something not related to the project? How frequent are these meetings? Was this planned? Perhaps this is a meeting where the employee's manager can excuse the worker from, so the worker can focus on the sprint.

Let's re-do that part of the stand-up in a few different ways.
Today, I am going to start coding the new login system. I have a sales meeting as a blocker. It is going to take half the day.
Today, I am going to start coding the new login system. I have a sales meeting to listen to some feedback from our users.

Hopefully, this illustrates how a different mindset can improve the value of the daily stand-up.

Friday, November 28, 2008

Is Barack Obama the "Scrum President"?

The first moment I thought President Elect Barack Obama might be the first "Scrum President" was while I was watching Obama's Inner Circle Shares Inside Story on 60 Minutes.  David Plouffe, Obama's campaign manager, mentioned how his team only planned for days instead of years.  They were "more agile" and "not afraid to take risks". Now, just because someone says "agile" doesn't mean they follow scrum, but I haven't heard many politicians talk like this group does.

There are a few quotes from another story, Obama On Economic Crisis, Transition, that have elements of "inspect and adapt"
[It] is not always getting it right, but projecting a sense of confidence, and a willingness to try things. And experiment in order to get people working again.
If something doesn’t work that they’re gonna try something else until they find something that does.’
If the idea is right for the times then we’re gonna apply it. And things that don’t work we’re gonna get rid of.
Regarding transparency, Obama said this:
I think that we have to restore a sense of trust, transparency, openness in our financial system.
Scrum is also very big on the concept of "team".  During the week of Thanksgiving (which I don't have a direct reference to, but heard on KNX 1070 radio), Obama said in that America will succeed or fail as one people.

I know I am drawing conclusions on some very loose quotes, and I doubt anyone in Obama's campaign ever said, "Hey, let's run a scrum campaign," but I am seeing enough of an agile spirit, which is the most important thing. 

Scrum and Agile have worked very well for me in software engineering, and I hope it works out well for politics and government too.

Saturday, September 27, 2008

Setting Expectations, Getting Results

When people fail to meet expectations, it is often because they didn't know what expectations to meet.  Being a ScrumMaster, team lead, and manager, the most effective way I clear this up is to explicitly tell teams what I expect.  This phrase, although quite obvious and trivial, helps me achieve that goal:
"I expect you to ..."
Yes, it is that simple.  By clearly letting your team (or boss, spouse, friends, etc.) know what you are expecting, they are better equipped with the right information to meet your expectations.  Here is a specific example:

Self-Organizing and Self-Managing Teams
When teaching scrum to a team, I tell them that "Scrum teams are self-organizing and self-managing".  Now that the team has been told, don't expect them to start being self-organizing and self-managing.  Aside from the culture and personality changes that need to occur to make this happen, it is much more effective to additional tell the teams, or individuals on the team, what is expected of them.  I follow-up with this by telling teams and individuals, "I expect you to be self-organizing and self-managing."  This may seem repetitive, but it is very effective.

Here are a few more examples of expectations:
  • I expect you to get to meetings on time, not 30 seconds late.
  • I expect you to meet  your commitments.
  • I expect you to help others with their tasks as though the tasks were yours.
  • I expect you to be pro-active, don't wait to be told what to do all the time.