Saturday, April 25, 2009

SmartBear: A better way to do code review ...

At OpenView Venture Partners we encourage portfolio companies to do code reviews - online, not face to face. Contrary to most agile practices where face to face communication is preferable, there are some distinct advantages to online review - no posturing, no haranguing, complete documentation of the problem, leisurely review and followup.

SmartBear Code Reviewer 5.0 has some nice features and we have some reference sites for OpenView companies.

An interesting discussion on whether code review should be done before or after committing to the build can be found on the SmartBear blog.

Monday, April 13, 2009

Shock Therapy: British Telecom Presentation

    Photo by twhume

On 2 April, I presented the latest version of "Shock Therapy: Self-Organization in Scrum" at British Telecom in London.

An earlier version of this presentation was presented at Google in the summer of 2008. The Google presentation is now on YouTube and several people have asked for slides so here is the latest version of "Shock Therapy: Self Organization in Scrum."

After the Google presentation, a group of went to dinner and they pressured me until late in the evening to describe exactly how and why the first Scrum team went into a hyperproductive state. The results of this discussion will be pressented at:

Travelocity
325 Hudson St.
New York, NY 10013 US
View Map
When: Tuesday, April 14, 6:00PM Add to my iCal Calendar
Phone: 917-887-1669

Topic: "Agile Architecture: Should I take the Red Pill or the Blue Pill?"

An analysis of hyperproductive Scrums at Google last summer showed that high performance of a team is dependent on architecture, the quality of the implementation and the understanding of the team. Most teams have either poor common understanding of system components or lack of ability to work together across components. This cripples velocity. With the right understanding of architecture teams can achieve not only high velocity, they can craft the product to fit end user needs in extraordinary ways. Thus the fundamental principles of the Agile Manifesto can be achieved at a much higher level with the approach described in this presentation.

We will need your name on a list at the door and bring your photo ID.

Location: Travelocity, 325 Hudson (see above; many thanks to them!) Entrance is on Vandam St. (just around the corner). Conference Room is on the 10th Floor.

We will have networking and food starting at 6:00pm. The talk will start at 6:30pm. And we will stop at 8:00pm.

Sunday, April 12, 2009

Self-Organization: The Secret Sauce for Improving your Scrum team


Google asked for an advanced Scrum presentation for those already doing Scrum. So we talked about "Shock Therapy" and how to bootstrap a hyperproductive team. Click here for slides.

Friday, April 10, 2009

Scrum and the A3 Process: Game Over for Waterfall Companies


The best teams I work with are using lean tools to identify waste, particularly value stream mapping. They then use Scrum to eliminate waste by working the Scrum impediments list. This has the benefit of pushing Scrum out of development into the rest of the organization as they see how they contribute to waste (or they feel so much pressure from development velocity they have to change).

This week I spent several days with the second company in the world that is implementing Scrum everywhere. It starts with the Senior Management Scrum Board in the CEO's office and translates into every department in the organization. The last company that did this immediately generated a hockey stick in their revenue curve, acquired two companies and went public in less than a year. We are eager to see what happens with this company.

As we have focused on surfacing waste and clarifying the ScrumMasters impediment lists, we find that ScrumMasters need better tools to eliminate impediments. They need a plan the whole company can understand and support. Using the A3 Process developed at Toyota we find that it gives ScrumMasters a powerful tool that they need to eliminate impediments.

Google on A3 Process and you will get hundreds of links and dozens of books, so this is a huge resource available to ScrumMasters everywhere.

A key component of the single sheet A3 paper which documents the problem, context, root cause, proposed solution, next steps, and issue is the 5 Whys. For every problem ask why, they ask why to the answer. Do this five times and you will get down to the root of the issue which is often surprising to management and developers alike. See:
Understanding A3 Thinking: A Critical Component of Toyota's PDCA Management System

These aggressive strategies will turn a Scrum company into a Toyota that will crush a waterfall company like GM. We are beginning to see an acceleration of waterfall software companies going out of business in some parts of the world because they are either unable or unwilling to change.

Monday, April 06, 2009

TableNinja: Poker Consultant expert advice to Agile developers

 
Alex Sutherland graduated from Cal Tech a few years ago and continued into the doctoral program in math and econometrics. However, his online poker hobby was generating all the cash he needed and he noticed that the PokerStars user interface was not suitable for serious players with multiple simultaneous games running concurrently.

Teaming up with a partner in a Los Angeles software company doing Scrum, they decided to implement the best front end for experienced poker players in the business. TableNinja shipped their first Scrum product release a few months later.

Alex is a Certified ScrumMaster from a recent course in Beverly Hills and says Scrum has definitely helped him and his partner double productivity and that it works better remotely than it does colocated. When they are colocated they drift off focus. When they work via Skype video they stay focused. As a result they say their next hires will probably be outside the United States.

This observation is the same as the CTO of Xebia made in our paper at Agile 2008 last year. Teams half in the Netherlands and half in India work better in their environment than colocated teams so they do all their projects that way. Of course, you need to do really good Scrum to get this effect.

TableNinja does consulting for serious poker players all over the world and some of Alex's best students are in places like Tokyo outside the United States. He says his recommendations to wannabe Poker champions are the same that he makes to software developers.

Your game falls roughly into three categories:

A Game - all the big money is made in your A game. The typical player/developer is running at this level less than 10% of the time.

B Game - this is where you make small amounts of money, probably 40% of your time.

C Game - this is where you lose small (or perhaps big) amounts of money about 40% of the time.

Alex's goal as a coach is to increase your A game to 20% of your time and make your B game good enough to pay off your losses on your C game. If you do this, you can make as much money as you need (and maybe more) playing Poker.

The problem for Poker players and software developers is that they do not stay focused when in their A game and stop playing when they realize they are playing their C game. They are like a taxi driver that has a target of $300 a day. During a conference when they can cycle back and forth to the airport they make $300 in a hour and quit. The rest of the time they cruise for 12 hours a day until they get their $300 dollars. They don't get it that they should only work the day of the conference that week!

Alex's recommendation is to code like crazy when you are in the zone and quit immediately when you are tired or bored. I noticed this recommendation fit nicely with Tom Poppendieck's observation of an XP company that did an experiment with different hourly work weeks to see when XP teams that did intensive pair programming hit their maximum production of shippable software. In that company, 16 hour weeks delivered the most production ready software.

Tune in, turn on, and drop out of the rat race might be good advice for Agile developers. You can start by playing a little TableNinja to get a feel for it. Better yet, join us at Beverly Hills Scrum Certification training later this month and learn how to do this in software development.

Sunday, April 05, 2009

Sprint Burndown: by hours or by story points?

The best teams I work with burn down story points. They only burn down when a story is done.

To do this, the team needs to have small stories. They will need to work with the product owner to make this happen. In disciplined teams this saves a lot of overhead and makes them go faster.

For new teams, breaking down the Sprint Backlog into tasks and estimating in hours is done but no longer recommended. Intronis, one of my venture group portfolio companies, started their first Scrum with burning down story points and has never looked back. They tripled their velocity in a few months.

This strategy is recommended for teams that can deliver working software at the end of each Sprint. This means tested at the feature level, i.e. potentially shippable code.