One-question daily SCRUM

A daily standup meeting (or “SCRUM”) with the team is an important part of agile development. But done wrong, these meetings can be demotivating and can reinforce traditional command-and-control management practices (which don’t scale and don’t work well with creative people).

The three questions that are “supposed” to be asked in standup meetings (according to most descriptions of Agile Project Management) are
1) What did you get done yesterday?
2) What are you going to do today?
3) What are you blocked by / need help with?

The problem is that the first question (“what did you get done yesterday”) sucks. It is important that the feel of a SCRUM meeting be peer-to-peer. And in respectful peer relationships you are not reporting achievement bullet-points to each other. The very act of reporting “what did you get done yesterday” puts people into a political mentality. The search for trivial tasks that can be done to make an impressive-sounding achievements will begin. This question just sucks in terms of the effects it has on a team, and has no place in SCRUM.

“What did you get done yesterday” is a question that seems like it was designed to solve the problem of a lazy manager. Anytime you find a process like this you should kill it, because it’s sapping the motivation of the team. Managers should work harder to get the information they need: team processes should be tuned to the information needs of workers.

The question of “what you are blocked by” is also problematic. I’ve noticed that explicitly requesting this information doesn’t work well. It makes people feel like they are complaining or ratting out their colleagues to say that they are blcoked by something that someone else is doing (or failing to do). If you focus on the work that’s being done.

The third question, “what are you working on today?”, is where the magic happens. It makes concrete the fact that people are in charge of what they want to work on. It is forward-looking so it is useful for planning purposes. And it often contains within it the answer to the first two questions. So in a slideshare SCRUM that’s the only question we ask.

LEADING USING NUMBERS

WHY MICRO-MANAGING IS BAD
Most adults (or even most children) _really_ don’t like being told what to do. In order to feel motivated and engaged, we need to have *agency*. Iin other words, we need to be able to make  meaningful decisions about the work. This is doubly true for the smart and internally-motivated people that join most startups.

METRICS THAT MATTER, AND THAT CAN REALISTICALLY BE MOVED
On the other hand, you are a startup founder in a rush – to build the product, to gain market acceptance, to defeat the competition and scale when its time. How can you get the product doing what it needs to without micromanaging the team? How do you get each individual to rally behind the current challenge?

One approach I’ve used at SlideShare is to articulate the 1-3 metrics that each team is working towards. Your team should know that their job is to move that metric in the right direction, and they have wide discretion to do whatever it takes to achieve the objective.

Easier said than done, right? It’s actually damned hard to come up with 1-3 metrics that define success for your team. And to make it even harder, it has to be something that the team can actually impact, not something that feels like it is in the hands of fate.

For example, maybe as an internet business you live and die by traffic. But your team may have little control of the number of unique visitors that hit your website. If this is the case, then making this the metric is setting your team up for failure. They probably have much more control over what percentage of registered users complete their profiles or become long-time repeat visitors, for example.

WHAT, NOT HOW
If you can orient your team around shared goals that are captured by metrics, then SHUT UP! Don’t dictate the “how”: that’s micromanagement. Let the team figure out (independently or together) how they will achieve the objective. Give people space to make their own decisions, to exercise their own initiative. They’ll surprise and impress you!

These 1-3 metrics have to be more important to everybody than the thousands of other chores and tasks that compete for their attention. Everyone on the team should always know what metric the team is working on, and the current status of the metric (is it getting better? worse? why?).

The metrics need to be available to your team on a daily basis (an automatic daily email works well for this). As a leader, you should notice and comment every time the metrics go up and down. The email will be iterated on constantly as the numbers that drive whatever your goal was are discovered and instrumented. Eventually it may contain a lot of numbers, but they will be the numbers that the team thinks they need to do their job.

REALITY IS MESSY
Laser-like focus on a few metrics is the goal. But reality intrudes There’s always critical maintenance work to be done: bugs to be fixed, customer service issues to be handled, site downtime to be reduced. Your team is under this pressure, and feels a responsibility to respond to it. This is ESPECIALLY true in an early-stage startup, where it can feel like just keeping the ship from sinking requires all hands on deck and every-day course-correction.

One way to fix this is to have some members of the team who are on firefighting detail. Their job is to deal with all the random crap that reality throws at you. Anything that is a fire that needs to be dealt with RTFN. As long as everyone takes a turn firefighting, it means the rest of the team can focus 100% on the key metrics.

DELIVERING RESULTS IS HARD (BUT WORTH IT)
Moving numbers is hard! It’s way easier to ship new features than to have a measurable impact on user behavior or revenue. By focussing the team on an important metric, you are making them work harder. The fact that you are focussed on a SHARED goal helps here. No one individual is signing up to move mountains. You’re all trying to do it together, and you will succeed or fail as a team. People want to actually have an impact on the world: it’s your job as a leader to provide an environment where this is possible.

When you set shared goals like this, you’ve turned working at your startup into something like a shared quest or an adventure. And you’ve provided a platform where your team can (together) have an impact on the outside world, and impact that 1)Is important, and 2)that they can actually see. I think that’s pretty cool!

Software as a work in progress

I was interviewed by CIO magazine about the technology behind SlideShare. The article was called Successful Tech Startups Offer IT Tips. There are some nice tips from Groupon, Box.net, and ZenDesk.

Here’s a excerpt from the interview:
SlideShare is at the point now that it tweaks its Web-based application dozens of times per day. “The combination of having very good measurement of user behavior with the ability to make small changes to the site means we can iterate extremely quickly,

Cloud interview on the windows azure blog

I talked to the folks who are in charge of the windows azure blog, and they were kind enough to publish it. I tried to focus on what the real benefits and challenges of cloud-based systems are (especially for startups), instead of the faux issues of control and security that seem to be the focus of many of these conversations.

As far as I’m concerned, the issues with the cloud come down to disk speed, network speed, and cost control. Disk speed, because it’s hard to run a big-ass MySQL database on a virtual machine with poxy IO performance. Network speed, because it’s hard to quickly move gigabytes of data into the cloud. And cost control, because it’s easy to get sloppy and waste money when you can scale your infrastructure (and your costs) at the push of a button. Remember the spider-man credo: with great power comes great responsibility!