How Fooala SCRUMs

In this post, I would like to touch on how we use SCRUM to manage our development @Fooala. And expound on the lessons I have learned as the SCRUM master. (If you are not familiar with SCRUM check out this video. Also, here's a useful diagram.)

(Note: while SCRUM master, I maintain a development role as well. I am liaison between business development and software development making sure both align.)

How do we SCRUM?

Our daily SCRUM occurs at 2:15PM.

Sprints are 4-7 days long. Stabilization sprints are 1-3 days.

Releases every 2-3 weeks.

We implemented SCRUM without any software. We use a whiteboard and post-its.

Post-its define tasks. Each task is placed on the white board and belongs to a developer. As the task progresses, it moves states as follows: "Backlog", "In Progress", "To Verify", and "Done!"

We write the expected amount of hours each task will take on each post-it and modify them every day during the daily SCRUM.

Different colored post-its are used for each of our products.

We also maintain another whiteboard that keeps the task backlogs for the next two sprints.

I have stapled legal paper around our whiteboards in order to group tasks together.

Finally, we maintain a sprint burndown chart in excel and print charts every day or two.

Why keep SCRUM physical?

By keeping SCRUM physical, the tasks feel more tangible and have weight. It is also easier to visualize our progress. Often times, I catch another cofounder working on development turn around from his desk only to stare pensively at the SCRUM board. For him, seeing the tasks move from left to right is a physical movement that parallels our development progress.

Adding tasks to the SCRUM board requires physical effort so tasks are not added without some consideration. This helps to keep tasks focused, relevant, and manageable. However if we are away from the office, SCRUM tasks are emailed to me but I enforce that task be defined only in the subject line of the email.

Why SCRUM at 2:15PM?

The afternoon daily SCRUM is largely due in part to our developer's vampire-like work schedule. As a manager, I would love to have the daily SCRUM at 10:15AM and keep core hours 10AM-4PM. However, fighting the developers would be futile. Core hours are Noon to 6PM. Typically, the developers are up till 3AM, get to the office by Noon, have lunch, work till 6PM, have dinner and relax, then start working again around 10PM. SOOO, I have no choice but to work around the developers schedule. Having it at 2:15 makes sure the developers are awake.

Tasks vs. Features

Sometimes a task is added that is expected to take 20+ hours. When a task is expected to take 20+ hours, it is more likely a feature. Hence, a feature should be broken down into several tasks. When I realize a task is really a feature, I ask my developers break down the feature. If they can't do it, that usually means a design meeting needs to be held.

The dreaded task pushback

At times, it is necessary to take a task out of the current sprint and move it back to the next sprint/release. It is tough to know when to do this, but this is where the burndown chart helps.

The burndown chart illustrates how much effort is left. If i realize that physically there is not enough time left in the sprint to accomplish that much effort, then I know something's gotta give. Largely based on business goals, I move tasks back or mandate certain ones be given priority. And if need be I proclaim that tonight is going to be a late night at the office meaning dinner at the office, coding party till 5-6AM.

Releases

Planning a release starts by first evaluating how the last release went. We do a release post-mortem answering questions like: 'What went well this release? What can we do better?'

Then we start with what are the business goals we need to accomplish. We then select the features that align with our business goals. Finally we breakdown the features into tasks. The tasks can be pre-existing (either pushed back or on one of the legal pieces of paper). However if a new feature is being developed, a design meeting is scheduled.

We end our releases with a Release Demo. I try to add weight to the Release Demos by inviting our advisors. Usually a business/sales person produces a slide deck and gives the presentation. My belief is that if our business people don't understand what the developers have done and the impact of their work, then the overall vision of the company cannot be aligned. Also, by emphasizing the importance of the Release Demo and including our advisors helps motivates everyone both developers and business people.

Sprints

Like releases, sprints start by evaluating how the last sprint went. Mostly I see what has been pushed back from the previous sprint and whether it is still important.

Sprints end with a demo day that includes only the developers. Each developer spends 10 minutes demo-ing their work. (Applause is encouraged)

Stabilization Sprints

Finally, at the end of the release, we have a stabilization sprint. This sprint is meant as a buffer to help clean up code before it is rolled out to production. Admittedly, this sprint should not exist and should be taken care of while a task is being verified. However, I find it is necessary to keep up the extreme pace of development.