Tag Archives: scrum

21st Mar, 2011

No comments

Odeo Sprint #3 Results (Birth of Twttr)

We were trying an Agile process called Scrum at Odeo and somehow by the third Sprint (two or four week iteration) we’d already managed to launch Twitter internally. How’s that for pivoting? At the end of each Sprint, I would send out a summary of results. Here’s how we fared:

From: Tony Stubblebine
To: Odeo-Internal@googlegroups.com
Date Sun, Mar 26, 2006 at 6:56 PM
Subject: Odeo Sprint #3 Results

Twttr.
Got a functional website (http://twttr.com twttr/*******), SMS in (send your status to 10958 as t this is my status). Good example of what a small team can do. Especially if that team is Jack. Actually Florian, Biz, Jeremy and Courtney all had a lot to do with this. More details on what got done and what’s coming next are on the wiki:

http://svn.odeo.com/odeo/wiki/TwttrStories

Crawler
As of Friday afternoon we’d crawled 27k feeds in the previous 24 hours. That’s about 80 times better than the day before. That’s good. But we want to be better. Kellan’s next iteration should be able to spider all of our feeds in under 10 hours.

SMAM/AC Success Rate
Bumped success rate from 92% to 98.5% with some extra error handling and an NFS upgrade by Jeremy. The remaining failure rate is due to Nelly Moser incompatibilities which we’ve postponed addressing.

Better Upload.
As in it works because it has less parts. We still want to put in some sort of progress indication, probably the odeo beach ball.

One Hour Studio
Most of the new creations have been four or five minutes. I sent the list of ones over 10 minutes in a separate email.

Link to audio
You can add externally hosted mp3s to your channels. This feature is listed in the Create sidebar.

Centralized Logging.
Setup for staging servers to duboce. Intention is to be able to quickly build stats, reports, and metrics. Still need centralized logging of production logs for this.

Basic Studio
We broke the mixing/recording/publishing functionality into a component that could conceivably be reskinned by anyone. The first skin, the basic studio, has progress but is incomplete.

Advanced Studio
Work to support the advanced studio clipping and looping functions. This is in developer testing. Major bug work that’s already come out of that includes memory handling for small buffers.

Design
Design work here. I believe that I saw more recent mockups that aren’t on that page and that

http://evofficeg5.local/~odeo/newOdeoHomepage/

New Staging Env.
We’re on a new staging server (cumberland) and staging db (hampshire). The db is destined for production. Also, I prefer to call servers by their functional names so that I don’t have to keep track of shifting servers. You can reach these servers as staging.odeo.com and db-stage.odeo.com

Small Teams Experiment.
In general I liked having smaller groups. I think it gives people more autonomy to make and implement decisions without getting bogged down in process. I’m all for that. I also felt like it messes with energy and company cohesion, and that the daily meeting process was too loose. Something to talk about in the sprint wrap up.

I’m sure I missed some things but, as usual, the final list of accomplishments looks pretty impressive. Thank you everyone!

19th Sep, 2006

Comments are off for this post

Agile Testing

(WARNING: This is another bloglines link dump surrounded by poorly disguised context!)

Traditional software development usually calls for dedicated QA. When I went to Odeo I knew that the engineers there wanted to work in an agile environment. But Odeo had also just hired a traditional QA person coming from a big-software QA group. I’d never heard how people integrated dedicated QA into an agile group so I went hunting for relevant blogs. One that I liked was Agile Testing by Grig Gheorghiu.

Grig’s writing is skewed toward Python but there’s still plenty of gems for the rest of us. Here were the links I had bookmarked in blogines:

Useful tools for writing Selenium tests
Discussion of tools that make it much easier to work with Selenium, a program for writing GUI-based testing for web apps.

Extreme Programming and QA With Kent Beck
A pointer to this QA Podcast interview.

Xooglers – A Blog By Ex-Googlers
Not testing related, but sometimes it’s good to see how and how far a person strays from their blog subject. These are ex-google guys commenting on google on a google-owned blogging platform.

I’m still not entirely sure what the role of dedicated testing is for an agile group. When you’re iterating the product design quickly I think the testing you want is all automated, so that you know quickly if you’ve broken something important (quickly being within 5 minutes). But after you’ve gone through several months of quick product iteration I think you want a thorough QA pass to mark all the rough edges. So either the engineeers the write automated tests as they go and then you bring in contract QA at the end or you hire someone who can do both.

This might be a good time to mention that Rabble, formerly of Odeo, is writing a Testing Rails blog (as well as a testing rails book for O’Reilly).

16th Jan, 2006

3 comments

Tyranny of the Sprint

Page_1.png

Odeo just finished week one of Scrum, our new engineering and product development methodology. In Scrum, development is focused around month-long Sprints with the goal of delivering as much production-ready functionality as possible. It’s a management dream, engineers are constantly sprinting all-out and releasing massive amounts of features. No more worrying about motivation or snickering about herding cats. Engineering at full throttle. Hurray for management.

The top question from Odeo-ers hearing about Scrum was, “How much rest do we get between Sprints?” Normal Scrum methodology finishes the Sprint with a wrapup meeting, then the next Sprint starts with an all-day planning meeting, then it’s back to coding. In our case we’ll also have a weekend between since we’re doing Scrum on a 28 day cycle. So that’s four days of rest (non-coding) one of which is an all day meeting.

I guess that does sound intense.

I’d been thinking of Scrum as a marathon, as a way to keep focus between mile markers. You focus on one goal for four weeks then, take a refill of requirements, then settle in for the next four weeks.

Two problems with that. First, it’s called a Sprint so you’ve got to expect people to get pretty intense about effort and expectations. Second, it leaves engineering almost no time for context switching.

The latter is pretty important to me. We’re a small company. We rely on engineers making smart decisions and contributing feature ideas. Back-to-back sprints clearly doesn’t allow for this. What to do?