David Sirlin’s just done a writeup of Flashbang studios recent experiment with work hours:
“The first part of their theory is that we really only get about 2 hours of seriously focused, amazing-quality work per day–if we’re lucky. Maybe you can get 2.5 or 3 sometimes, but that’s pushing it. There are so many distractions and blockers, so many times when you’re too tired or hungry or upset about something, or whatever. Flashbang is saying just be real here: accept that you’re only going to be able to do amazing work for a short time each day. Knowledge work as it’s called, is the type of thing where you could spend 20 hours on a problem and not solve it, but just *one* hour of your fully charged genius-time could solve it.”
Unfortunately (tragically!), David’s set his blog to be “no comments”, so there’s no public followup discussion (you can try registering in the forums. On a different page. Not even linked. Have fun with that!)
There are serious flaws with taking general conclusions from this experiment – as someone from TCE pointed out, there’s probably some Hawthorne Effect going on – but I think it’s an interesting data point to add to the game studio manifesto. Specifically because it’s from a games company, and the particular set of changes they experimented with is different from most of those we’ve seen tried before.
12 replies on “Focussed work-hours, and the Studio Manifesto”
Interesting — I think the most intriguing aspect is how they made people ‘time-aware’ by making the working day shorter.
Situational Awareness — I really liked this bit. In the past I’ve had the I/O activity of a svn server hooked up to a big ‘bubble lamp’ so you could see if someone was checking in or updating. This was more necessary due to svn being a bit rubbish, but it was still useful to have that awareness.
With more branches and much bigger teams, it might be harder to make that work. Right now we have lots of newsgroups that get postings when people commit changes, but I need to actually go and look at them to find it out, so that’s not great for me. CCtray gives us something similar for build success/failures although it doesn’t pop up notifications very well in my experience. I’ll have to take a look at knocking up something that throws up notifications in a nice way.
Minimising disruptions – even just for 48 minutes – sounds like a good idea, although in practice I see a lot more people waste time / do thing wrong because they haven’t asked someone to help/explain things to them and have either spend ages figuring it out correctly, or worse have just bodged something in incorrectly. I see A LOT of the latter in games!
Standups / user stories rock – I use those all the time and although it takes people a while get used to them, they’re really good once people get the hang of it. We just delivered some kick-ass improvements to a game workflow in only a couple of weeks and we’d correctly estimated the length of time it would take to get it done. That sounds like a small thing but I am very happy about it – user stories, whole team estimation, daily standups and a whiteboard of stories/tasks was what we used to do this. Relatively low management I think.
We use Jira & Fisheye for our checkin monitoring — I have my outlook set up with folders containing RSS streams. It even gives you a web interface displaying the changelist contents, the file list and even diffing. I’ve been really impressed; it’s much better than the old email spam we had and it means I can keep up with who’s doing what without much hassle.
Regarding the rest of the suggestions: I think a lot of these things are good ideas, but they have to be implemented in a very disciplined way.
We also use instant messenger; you’re meant to send someone a message asking if they’re busy prior to going to their desk. This works quite well, but it’s easy to forget to follow this process if you’re sitting in the same room as the person you want to speak to.
We do scrum and it’s often a case of “best intentions”. Every so often, you realise the standups are taking too long, people are rambling and so forth. As a result, someone whips the team back into shape and things run more quickly for a while until we inevitably drift once more. It’s easy to do badly because if it drifts a little per day, you don’t notice.
The focussed, reduced work hours is something that I’d love to try, but again, it would have to be implemented carefully, plus it means things like having to conduct job interviews and meetings would absolutely destroy your chances of being productive.
I guess the major problem with changing working hours is that it’s very hard to accurately measure productivity in a games studio and the moment management have to make a call between shorter or longer hours, they will pick longer hours nearly every time, even in the face of evidence stating the opposite.
@Mark
“We do scrum and it’s often a case of “best intentions”. Every so often, you realise the standups are taking too long, people are rambling and so forth. As a result, someone whips the team back into shape and things run more quickly for a while until we inevitably drift once more. It’s easy to do badly because if it drifts a little per day, you don’t notice.”
This should be impossible, if you are doing Scrum.
Where the heck is your Scrum Master? What are they *doing* all day? Their primary duty is *explicitly* to prevent what you described above!
I cannot stress this enough: Scrum without a ScrumMaster does not work.
@Mark
“things like having to conduct job interviews and meetings would absolutely destroy your chances of being productive”
This is a very interesting issue. IMHO this setup rquires special handling – any situation where the requirement is that multiple disparate people are needed to drop what they’re doing and assemble at a precise, given, time.
I know some people who advocate “no meetings, ever”, in an attempt to cut out the large number of “meetings’ that are called without really meeting the requirement. But there are huge benefits to meetings, for instance allowing people to plan ahead (especially people outside your team, for whom “attending the office” may be a major undertaking, e.g. interview candidates).
OTOH, it often seems that most situations where a meeting happens don’t actually qualify under that criteria.
Personally, I’ve found a useful tactic is to pre-arrange all meetings on a specific day / couple of days of the entire month. I can do 8 meetings in a day – why not? If the meeting actually had to be a meeting (as opposed to a conversation, a series of phone calls, comments on a document sent by email, etc) … then – de facto – everyone was able to set the date 4 weeks in advance, and not be late, and not overrun.
I’ve only rarely walked out of meetings because the alotted time was used up (I had good reasons, e.g. other urgent business or other meetings pre-arranged), but found it worked so well that I’ve been tempted to make it a general rule. When you walk out on someone for waffling, they turn up to the next meeting a lot better prepared, and with a proper, written, agenda.
Adam — I should’ve put “scrum” in inverted commas, same as I do every time I say the word “agile” because, all too often, it’s just a buzzword — it only means something when you’re doing it properly. Each team does have a scrum master, but the quality of the implementation varies team to team. Similarly, we’re supposedly agile, but changing certain aspects of our development process is akin to turning around an oil tanker. Not very agile indeed.
I guess this just feeds back into the point that if you make these changes, you have to be very disciplined. Just about everything is easy to do and even easier to do wrong.
Re: meeting.
I have generally the same attitude towards meetings. They are a chore, but many of them are necessary. You can’t just say “we don’t do meetings” because it’s hard to plan properly without them, and sometimes nothing can beat sitting in a room and thrashing something out. An email thread can take ages to participate in, especially when multiple people are involved. The same effort can be better spent in a quick meeting.
Planning meetings in advance is good when you can do it, but there’s still quite a few unplanned meetings that spring up week to week, e.g. “what does this story mean? The wording is ambiguous”, “This is not well defined”, “problem x has cropped up with our design, we need to rethink it” and so forth.
@Mark
My advice to teams in that situation (w.r.t. non-faithful implementation of Scrum) is simple:
Stop doing it. It is doing you more harm than good. You threw away everything good about your old process (surely there was SOME good in it, somewhere?), and because of how Scrum works, if you’re not doing it correctly, you are almost certainly getting NOTHING good out of it (even if you think you are).
Even when being paid to convert game teams to Scrum, I’ve more than once called a halt and said “Let’s just give up on this.” (even though it meant I wouldn’t get paid any more for my consulting :)). With some teams, that results in the person/people who are blocking Scrum (deliberately or accidentally) to wake up, smell the roses, and allow Scrum to work correctly.
With other teams, they just give up. And that’s better than struggling on, wasting *everyone’s* time, IMHO.
@Mark
re: “unplanned meetings” – how many of those need to be meetings, though?
Playing devil’s advocate … For instance, can some of them be handled perfectly well through a group IM chat, that may take hours to play out, as people think over what’s been said and come back with more comments and ideas?
My favourite challenge these days is the brutal: how many of them does it simply need someone to go away and implement the thing as-is, in the quickest possible fashion, and bring it back to show everyone else what’s wrong? (a 1-day time limit works well here; and if it’s not important enough for one person to spend a day (8hrs) on it, WhyTF is it important enough for 4 people to spend 2 hours on it (meeting + lost concentration time))
(if done correctly, that takes very little time. I’m assuming it’s done correctly – much like constructing the “smallest possible program that demonstrates a bug”. And, in similar fashion, if it’s too much effort to even do that, it usually means that there’s a different problem that needs solving first)
On a side note, the Hawthorne effect – at least, the original experiment – has apparently been repudiated. Some people got hold of the original experimental data, and it doesn’t hold up. (There was an article about it in The Economist – it’s behind a pay wall, but here’s the link:
http://www.economist.com/businessfinance/displayStory.cfm?story_id=E1_TPSRRQNS&source=login_payBarrier And oh, hey, I just noticed that’s mentioned in the WIkipedia article. But I will leave the link and look pretentious.)
I believe there is some evidence from programming research that whatever you measure gets optimized, so I believe the effect, at least in the handwaving sense of “Measuring affects what is measured”, still exists.
I just got up out of bed, I can’t add anything more substantial yet.
OK, slowly waking up. My 5 cents:
* Every management process is part of a set of processes that all have to work together to be effective. (Kent Beck’s XP book repeatedly makes this point about XP.)
* Every team and project is different and a set of processes that works in one situation may not work in another situation.
* Changing the way you work is at least as hard as the work itself. The odds of success when you change too many processes are low, and I’ve seen teams flounder and fail because they changed too many things, too often.
Concretely in the case of the article linked above, I am tempted to try some of it at my current company, but right now I am afraid we cannot measure productivity accurately enough to tell whether it’s working or not. Plus, even though we’re tiny, I am not sure everyone on the team has the right mindset to make this work.
Oh certainly, it’s easier to start a company arround the principles – and hire accordingly. But I don’t think it’s impossible…and “productivity” in many cases can be looked at as getting the job done in a reasonable number of days.
The key is simply avoiding the basic mistake of equating time behind a desk to productivity… (which so many still do)
“Their primary duty is *explicitly* to prevent what you described above!”
I call bullshit. Agile development works fine without a scrum master, and in fact my opinion is that good agile programming DOESN’T require adherence to scrum, XP, or any other prescriptive process. Further, regardless of title, anyone can get sucked into a tangent that (depending on your perspective) trainwrecks the meeting or accomplishes one of several OTHER goals: team building, raising red flags that require global input, or has no effect anyway.
Get good people, who have bought into getting stuff done, and who are capable of translating their ability into finished tasks. Then sit back and enjoy. You can have a process on top of it, particularly one that doesn’t get in the way of good people doing good work, and it will work too… but start with that, and you’re basically done.
Meetings, decently scheduled, won’t interrupt the few hours of top-notch knowledge work that can be done in a day anyway, and poorly scheduled… top-notch work gets scheduled around anyway. I’ve worked under a variety of processes over the years, and my experience is that in general they don’t hinder my ability to get stuff done, but they also don’t enhance it.
@Matthew
The OP explicitly named Scrum, not Agile.
Agile and Scrum are completely different things, which are sadly getting confused with each other more and more often these days. (Why? Where did this “Scrum and Agile are synonyms” fetish come from? Weird…)
Say what you like about Agile – I think it’s a mediocre approach (not bad, but nothing special) to software, and personally I’ve found it to be of little real use. It’s just an umbrella term, and when a team claims they “use Agile”, they really mean “we don’t know what we’re doing, but we like the sound of a few random techniques we’ve adopted”. Failing teams are usually still major under-performers after they adopt Agile; the same is not true for real methodologies.
By comparison. Scrum is a formal process, with named roles and well-defined sub-processes. And one of those roles is the Scrum-Master – who is explicitly responsible for a couple of things. Feel free to call bullshit, but this is all written down clearly and explicitly, so I don’t see much point in arguing over it.