Monday, December 27, 2010

Scrum Inc Sprint 2 Retrospective: The Happiness Metric

Happiness Metric Process Improvement Priorities - ScrumInc 15 Dec 2010

Scrum, Inc. was a small company hosted by OpenView Venture Partners in Boston from 2006-2010. As a two person Scrum using Pivotal Tracker as a Scrum tool, I was a remote Product Owner traveling 2-3 weeks a month in Europe. Operating remotely was an impediment and Scott Maxwell, the founder of the venture group has been encouraging me to expand the business for several years.

Effective 1 December, we are now six people. We had a workshop on 6 December to do initial planning and backlog creation and we run weekly sprints. When I returned from Europe mid-December we had our first sprint planning with the whole team colocated.

We decided to run the weekly sprints using a format similar to that used by Scott Downey at MySpace and Napster. He runs the Sprint Review, Retrospective, and Sprint Planning as all one meeting that takes half a day. It took us a full day as we introduced the Happiness Metric as a way to run the company and had a lot of Product Backlog grooming to do.

We decided to use the introduction of the Happiness Metric as the Retrospective for the previous sprint. The Happiness Metric is a leading indicator for revenue and was discussed in a previous posting. The retrospective can be done in many ways and consists of several key components:

1. Establish a clear picture of what happened during the last sprint - the good, the bad, and the ugly.

This we did by having everyone answer the first two questions of the Happiness Metric - on a scale of 1-5 (1) how do you feel about the company and (2) how do you feel about your work at the company?

Everyone put a number on two sticky notes and posted them on the wall. The average for the team was little over a 3. Not great, but not bad for a team that was just starting up and several of them were learning Scrum for the first time.

2. Create a list of process improvements that emphasize the good, deprecate the bad, and pretty up the ugly.

We did this by asking the second two questions of the Happiness Metric - (3) What would make you feel better about the company and (4) what would make you feel better about the work you do?

Each person created one item per sticky note and put several notes on the wall.

3. Identify the top priority process improvement.

It is critical to get extreme focus on the process improvement that will have the most impact for the least cost. Fixing one thing at a time gets everyone behind making one change. The team can then feel the impact of the change and discover whether the change worked. Following that, the priorities of process improvement may radically change. The next priority process improvement can then be selected in a way that maximizes progress and minimizes wasted time and effort.

We decided to use Priority Poker to rank order the improvements - the things that would make people happier. We pulled out our Planning Poker cards and to my surprise, improving the way the team worked together scored 64 points, way above anything else! Everyone was astonished as we would never have seen this by just having a conversation about what was important. When we drilled down into how we would measure this during the next sprint we discovered several things were important:

a. People were working only on their own stories and need to start working together on stories. We will measure how much people team up on stories.
b. People who should be in the loop on discussions need to be included. We will measure how many times this happens or does not happen.
c. Avoid duplication of effort by including the right people in the discussion and having daily meetings at the same time and place. We will measure the number of times miscommunication causes rework.
d. The sprint must have points set aside for unanticipated events. Any new items coming into the sprint in this category must go through the Product Owner. If the Product Owner finds it necessary to insert more new work than points allocated, the sprint will be aborted and replanned.
e. Pivotal Tracker must be updated at all times so that those not in the office can see the global status of everything in the company.

4. Implement the top priority process improvement before the end of the next sprint.

A lean expert was in our Scrum training in Paris the previous week and his critique was that we do not emphasis Kaizen enough. Work to be done = Product Backlog + Kaizen. In Scrum, Kaizen is impediment removal. We decided the top impediment in the retrospective would always be a story in the Product Backlog for the next sprint. The number of priority points for the top impediment was far larger than the business value of any product backlog item.

Of interest, is that the second priority was getting new space for the larger team. A backlog item was put into the sprint to investigate this. Within two days we have several candidates and our new lawyer from the venture community advised us to locate at the Cambridge Innovation Center as this is where all the action is in the Boston new venture community. Even though this effort was lower priority we negotiated new space before the end of the sprint!

The rest of day was even more surprising. My feeling, based on work with high performing teams, is that this team will go hyperproductive and if they do, will be the first office Scrum that has the metrics to prove it. We broke out champagne at the end of the day and celebrated the launch of our first properly planned sprint. My happiness metric was already rising and I was looking forward to our next meeting!

Friday, December 24, 2010

Multi-tasking makes you stupid: Give it up before you get brain damage!

We know multitasking causes project delays but it is even worse than we thought. Psychology Today reports on new research that shows it builds up a stress response that damages cells in your brain.

The Difficulties of Multi-tasking

Multi-tasking, the mental act of juggling, may not actually be the best way to save time or get things done well. A new body of research has found that multi-tasking makes people less efficient and reduces the level of brainpower used for each task. Also, people who overburden their minds with too many tasks at once can have problems with short-term memory. One study, in the Journal of Experimental Psychology, found that the mind slows down when it switches back and forth between tasks. The only way to turn off this mental friction is to put more time, even just a few seconds, between tasks. A second study, in the journal NeuroImage, also notes that the mind does not cope well with multitasking. It asked participants to listen to sentences while comparing two rotating objects. Even though these tasks use different parts of the brain, visual input dropped 29 percent and listening success fell 53 percent.

For people doing too many things at once, additional worry can build up into a stress response. This adrenalin rush can damage the cells that form new memories. It can also weaken attentiveness and alertness. So what can people to get their act together? Focus on fewer tasks.

OpenView Venture Partners Video Lab: Backbone of Scrum

The Structural Backbone of Scrum According to its Founder
Dec 23, 2010 by Corey O'Loughlin

Jeff details the history of scrum, starting with structure

When the idea of Scrum was just a notion in Dr. Jeff Sutherland’s brain, the agile devel­op­ment method’s cre­ator intended to rede­fine how busi­ness was conducted.

The best prac­tices process at most com­pa­nies look­ing to achieve break­throughs in pro­duc­tiv­ity would need to be com­pletely torn down and rebuilt. And so he did just that. He took his 11 years of doc­tor­ate learn­ing and applied them in form­ing an agile devel­op­ment method for businesses.

Why did Dr. Suther­land decide to put forth a plan to cre­ate what even­tu­ally became the Scrum approach? Because after count­less hours of study­ing, he was cer­tain that there were insti­tu­tion­al­ized short­com­ings in many busi­nesses. One of the most preva­lent issues was a lack of com­mu­ni­ca­tion and mis­com­mu­ni­ca­tion. So many com­pa­nies failed to over­come issues here caus­ing prob­lems through­out the operation.

The goal was sim­ple: com­pletely rede­fine the way com­pa­nies oper­ate. And that’s pre­cisely what was done. Watch the full video from Open­View Labs for more infor­ma­tion on this topic.

Saturday, December 18, 2010

Scrum Board on Steroids: The Awesome Nature of Awesomeness



Breaking news: Vodafone board wins Atlassian Ultimate Wallboard contest ...

The Vodafone team in Copenhagen has a Scrum Board with RFID technology that knows when a card moves and updates data in their Jira tracking system. A video camera is always watching the board. This video is an entire sprint running in fast forward.

There are projectors showing the burndown and how much of the sprint backlog is in each state. This is driven by Jira and the projectors are on 100% of the time. Using Google voice, the board is also wired to talk to the team to point out or remind them of critical issues. The board will verbally complain if someone updates Jira and tell the team to move the cards to the right columns.

Software is written in Python by the ScrumMaster, Ole Hojris KristensenDefinitely the world's most awesome Scrum board! Click here to see Ole demo the board.

Saturday, December 04, 2010

Give Thanks for Scrum Day - 24 Nov 2010


Dan Mezick organized the Second Annual Give Thanks for Scrum Day on 24 November at Microsoft in Waltham, MA. Ken Schwaber and I gave presentations and did a panel. A good time was had by all!

Aggressive Scrum - What Happens When You Actually Remove Your Impediments?

There are endless studies of dysfunctional Scrum and 1000 ways to implement ScrumBut. But what happens when a company, a coach, or a team aggressively implements Scrum and successfully removes impediments. I'll discuss three papers presented at Agile 2010 as snapshots of successful Scrum. The first is an artificial life company in Finland where the entire management team got on board with Scrum. The paper on how the managers felt after a company wide Scrum implementation has some interesting findings. The second snapshot shows how an Agile coach successfully produced a hyperproductive team every time he became ScrumMaster. His metrics for hyperproductive teams are something everyone doing Scrum should know about. The third snapshot describes a companywide transition to Scrum that was executed in two months. Running headlong into your companies biggest impediment at full speed is a story not to be missed. Published results on each of these three snapshots are available. Click to download slides.

D. Friis, J. Ostergaard, and J. Sutherland, "Virtual Reality Meets Scrum: How a Senior Team Moved from Management to Leadership," in Hawaii International Conference on Software Systems, Kauai, Hawaii, 2011.
J. Sutherland and S. Downey. Scrum Metrics for Hyperproductive Teams. Agile 2010, Orlando.


J. Sutherland and R. Frohman, "Hitting the Wall: What to Do When High Performing Scrum Teams Overwhelm Operations and Infrastructure," in Hawaii International Conference on Software Systems, Kauai, Hawaii, 2011.