Blood, Sweat, and Pixels, ch. 3: Stardew Valley
“Barone worked on his video game; Hageman paid for food, expenses, and rent on their tiny studio apartment” (66)
“Barone was working a lot—but he wasn’t working very efficiently” (67)
“Because he was making Stardew Valley by himself, there was nobody to hold him accountable or force him to stick to a schedule. He had no employees or expenses. No producers were hovering behind his computer chair, telling him to stop overscoping and just ship the damn game” (67)
“Any time Barone thought of a cool feature or an interesting character for players to befriend, he’d add it. Every week, the game grew exponentially bigger” (67)
“Where he really could’ve used help was scheduling. Some game developers set their project milestones based on what they think will take them the longest to make, while others build schedules around the demos they’ll have to create for public events like E3. Eric Barone had a different approach: he made whatever he felt like making” (68)
“Barone searched the Internet and stumbled upon a new program that seemed promising: Steam Greenlight. With Greenlight, Valve crowdsourced its approval process, allowing fans to vote on the games they’d want to play” (69)
“They had eaten into most of their savings, and Hageman was still only working part time as she prepared to graduate from college” (72)
“he found a part-time job as an usher for the Paramount Theatre in downtown Seattle, working there a few extra hours every week so they wouldn’t go broke” (72)
“Being a solo developer came with two major challenges. The first was that everything took a very long time. Because he didn’t have a strict schedule, Barone had a tendency to build 90 percent of a feature, get bored, and move on to something else” (75)
“The second major challenge was loneliness. For four years now, Barone had sat by himself at a computer, rarely talking to anyone but Amber Hageman” (75)
PsychOdyssey, eps. 7-9
Episode 7: We’ll Know Where It Is
It’s a surprising day at the studio as a beloved team member shares personal news. —Episode Description
“Sony is really particular on what they show and kind of wants to put together a best showing. And I don’t think either us or them want to show the game if it’s not ready” —Chad Dawson
“All the polish and stuff that takes it from that, which is way pre-Alpha, to probably Alpha or Beta level, which you want to show at E3, is a lot of polish” —Dawson
“How can other people work on the same level I’m working on so that I don’t stomp on their work, and they don’t stomp on mine … That’s the hardest part, figuring out best practices” — Dave ‘Rusty’ Russell
“It’s day to day for me. Like, one day I’ll leave thinking: ‘oh, this is awesome!’ And we’re going to be all right. And then another day I’ll leave, and I’ll just feel: ‘how are we going to ever get this thing done?’” —Crook
“I always just tell myself: ‘Don’t freak out, and nobody is going to die.’ Because nobody is going to die. I’m not some surgeon that’s going in and trying to save somebody’s life, right? That doesn’t mean I don’t take it very seriously. I know that it’s important. It is important. It’s important to the company, it’s important to everybody. This is– This is our livelihood, right?” —Crook
“And you’ve done all this work. ‘And I don’t know what I’m doing. I don’t know if this is good. I hope what we did is okay. I don’t know how we are going to get this done.’ And suddenly you’ve got people saying: ‘Oh, this looks cool! I want to play it!’ ‘Okay, great. Awesome!’ But that is a good sign.” —Andy Alamano
“That was cool to see. To see a lot of the ideas that we had developed that were just ideas. And to see those, like, actually implemented and working, and sometimes even better. You know, they had made better decisions, they had adjusted things.” —Crook
Episode 8: A Couple Years of a Lot of Work
The Psychonauts 2 team staffs up with both veteran team members and new hires, while attempting to create a prototype of the game experience. —Episode Description
“This is not a super productive period for the project right now.” —Zak McClendon
“It’s supposed to be that great thing where we get ahead on the design.” —Tim Schafer
“But we don’t want to get ahead! That’s the trick, is that you don’t actually want to get ahead … I feel like we are there. I feel like we are there in terms of, like, what we want the game to be. And I feel like we can describe the creative goals of the game.” —McClendon
“I’d like to work with a team on what they are excited about building. The biggest impediment has been without a team on the back end applying pressure for us making decisions, it’s been very easy to stay in brainstorm land and come up with a lot of ideas and keep exploring all of those ideas” —McClendon
“A lot of it is just balance. Because it’s never going to be perfect. We are not going to do everything that we want to do. That’s never going to be the case. Because there is no lack of ideas or polish that we could put on it. But there are budgets and deadlines.” —Duncan Boehle
“I’m really open to reconfiguring how we execute and produce the game, compared to the first one” —Schafer
“The first one, it was this thing, where like a tornado, and you are just trying to hang on, and just stay together, and get things made. The first attempt we made at levels just were not working out. And we ended up reconfiguring the entire team, putting different people in charge of different things. And then we just got it done by brute force, by everyone staying here until five in the morning and stuff. That’s how we got the first one done, and we don’t want to do that again.” —Schafer
“So now we are using, I feel like, a more logical approach. And Zak has a more level designer-based approach, which I think makes sense” —Schafer
“What is my fiscal responsibility to this project? That, if I screw it up, you are like: ‘That was supposed to be your job! Why didn’t you do it?’ Because, like, Lead Designer, coming in, I’m going to tell you: ‘this game is going to be great.’ I’ll do everything I can to make the game great, make sure we hire the right people, make sure everything about it is good, that’s my responsibility. But now I’m in the Project Lead role, and so I don’t know how that connects specifically to budgetary constraints, all that stuff” —McClendon
“The Project Leads do have to get the game done with the money that we are able to generate for them. There is both the stuff that you are doing now, which is to advocate for the quality of your game. Which means pushing us and management to get the most money we can. You are just like: ‘Look, this is the best version of the game that we can make.’ But then, also as the actual budget gets more locked in, and we realize that: ‘Okay! We have to make a game for that.’” —Schafer
“Usually, we can’t start a game before we have a publisher. So we are really desperate for, like, you know: ‘Oh my god, we are going to run out of money in two weeks. Can you please just sign this? And we’ll take any terms you want.’ This time we have money. We could start the game, we could get a prototype made before we sign this.” —Schafer
“It’s going to be a couple of years of a lot of work to make everything feel good.” —Devin Kelly-Sneed
Episode 9: One Shot
Double Fine hires a rookie designer and longtime studio fan to kick off development of a new game level. —Episode Description
“Sony’s been great, they are telling us: ‘You know, make the game the best you can, and don’t worry too much about the submission dates. Let’s try to hold to it, but…’ They are flexible. We are not. Psychonauts 2 isn’t. We need to get those people over to Psychonauts 2. We need to start working on that game. And I know that! Working at a place like Double Fine where there is a lot of people sharing talent … When you think you are going to be done with the game, there is another team of people who, their expectation is that: ‘I’m going to get that person, and that person, and that person to start working for me at this point.’” —Alamano
“Most of the tech work we are doing will be stuff that’s used by other projects. So, in that sense, our project itself has been pre-production for a lot of those. If we hadn’t done our project, they would be spending an extra eight months, an extra year getting their engine ramped up. So, it hasn’t been too bad in that sense. You know, it’s studiowide knowledge that we have.” —Dawson
“It’s nice, because Tim will, you know, just say: ‘I want the pie in the sky!’ And Zak is like: ‘Well, it’d be nice, but, you know, the realities are that I need this and this. And I maybe don’t need that other stuff.’” —Russell
“But Tim’s gotten really good at that now too, so … he reeled himself in even before Zak. His family reeled him in. I mean, it’s true. It’s, like… He wants to go see his wife and child. He doesn’t want to stay here until 3 AM.” —Russell
“So, what I understand about the original game is that… the level designers… it didn’t go great. Um, so, they eventually got fired halfway through the project. Which I saw on Wikipedia, like, a day after I got hired. I was like: ‘Oh, no! This is a terrible omen.’” —James Marion
“once we actually figure out production math on those things, I think it becomes bigger than just eleven brains” —McClendon
“It’s about building out these level teams. And having those level teams be functional creative units that work really well together. And for that they need to do creative work together. We could just hand them ideas and say: ‘Here is what you are building. Go build it.’ But I don’t think that would develop them as a team as well. And ultimately they wouldn’t feel as close to the work” —McClendon
“Tim is, like, a dreamer, right? I even noticed that in the Double Fine Adventure. Tim thinks about things without a ton of concern regarding how possible they are. Which, I think, is really good for a Creative Director. So it’s probably great that Zak is here to be like: ‘Nope, not going to work.’ I would assume Zak is probably good enough, smart enough to know that some impossible things are probably possible.” —Marion
“I had a dream last night that I got into a fist fight with Tim” —Marion
“We want to share with you our finalized, fully executed contract with Starbreeze Studios … Now, we were already making this game, and nothing was going to stop us from making this game. But there is a substantial amount of money tied to that contract that is going to help us make this game the way we want to make it” —Schafer
“A lot of people passed on it. They offered us less money. There were some people who wanted to give us, like, a tiny bit of money. We were like: ‘We want to make a really good game. It’s going to take this much money.’ And Starbreeze turned out to be the one that was the most enthusiastic and also the one that gave us the best deal” —Schafer
The Scrum Guide
“Scrum is a framework for developing and sustaining complex products” (3)
“A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value” (3)
“Scrum is a process framework that has been used to manage complex product development since the early 1990s” (3)
“Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques” (3)
“Scrum makes clear the relative efficacy of your product management and development practices so that you can improve” (3)
- Scrum teams
- Roles
- Events
- Artifacts
- Rules
Scrum Theory
“Scrum is founded on empirical process control theory, or empiricism” (3)
“Empiricism asserts that knowledge comes from experience and making decisions based on what is known” (3)
“Scrum employs an iterative, incremental approach to optimize predictability and control risk” (3)
“Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation” (3)
Transparency: “Significant aspects of the process must be visible to those responsible for the outcome” (4)
Inspection: “Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances” (4)
Adaptation: “If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted” (4)
“Scrum prescribes four formal events for inspection and adaptation” (4):
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
*Scrum values” (4):
- Commitment
- Courage
- Focus
- Openness
- Respect
Scrum Team
“The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master” (5)
“Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team” (5)
“Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team” (5)
“The team model in Scrum is designed to optimize flexibility, creativity, and productivity” (5)
“Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback” (5)
“Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available” (5)
Product Owner: “responsible for maximizing the value of the product and the work of the Development Team” (5)
“Product Backlog management includes” (5):
- “Clearly expressing Product Backlog items”
- “Ordering the items in the Product Backlog to best achieve goals and missions”
- “Optimizing the value of the work the Development Team performs”
- “Ensuring that the Product Backlog is visible, transparent, and clear to all”
- “Ensuring the Development Team understands items in the Product Backlog to the level needed”
“The Product Owner is one person, not a committee” (5)
“For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says” (5)
Commentator’s Note: This principle especially makes sense when coming to Scrum from large, non-Scrum organizational models. This frequently does not happen. Competing decisions and priorities are often the norm, rather than the exception.
Development Team: “professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint” (6)
“Development Teams are structured and empowered by the organization to organize and manage their own work” (6)
Development teams (6):
- Self-organizing
- Cross-functional
- Exclusively made up of ‘developers’
- Have no sub-teams
- Accountable as a whole
“Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint” (6)
“The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog” (6)
Scrum Master: “responsible for ensuring Scrum is understood and enacted” (6)
“The Scrum Master is a servant-leader for the Scrum Team” (6)
“The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t” (6)
“The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team” (6)
Service to the Product Owner (7):
- “Finding techniques for effective Product Backlog management”
- Explains “need for clear and concise Product Backlog items”
- “Understanding product planning in an empirical environment”
- Explains how “to arrange the Product Backlog to maximize value”
- “Understanding and practicing agility”
- “Facilitating Scrum events”
Service to the Development Team (7):
- “Coaching … in self-organization and cross-functionality”
- “Helping the Development Team to create high-value products”
- “Removing impediments”
- “Facilitating Scrum events”
- Promoting Scrum
Service to the Organization (7):
- Driving “Scrum adoption”
- “Planning Scrum implementations”
- Teaching Scrum and “empirical product development”
- “Causing change that increases … productivity”
- “Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization”
Scrum Events
“All events are time-boxed events, such that every event has a maximum duration” (7)
“each event in Scrum is a formal opportunity to inspect and adapt something” (7)
Sprints: “The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created” (8)
During (8):
- “No changes … that would endanger the Sprint Goal”
- “Quality goals do not decrease”
- “Scope may be clarified and re-negotiated”
“Each Sprint may be considered a project with no more than a one-month horizon” (8)
“When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase” (8)
“A Sprint can be cancelled before the Sprint time-box is over … if the Sprint Goal becomes obsolete” (8)
Sprint Planning: “The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team” (9)
Answers (9):
- “What can be delivered in the Increment resulting from the upcoming Sprint?”
- “How will the work needed to deliver the Increment be achieved?”
“Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less” (9)
The Sprint Goal “provides guidance to the Development Team on why it is building the Increment” (10)
Daily Scrum: “a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours” (11)
“This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one” (11)
- What did I do yesterday?
- What will I do today?
- Do I see any impediments?
“The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15-minute time-box” (11)
“Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge” (11)
Sprint Review: “held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed” (11)
“Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value” (11)
Includes (12):
- Scrum team
- Key stakeholders
- Done vs. not done work
- What went well, what problems, solutions
- Demonstration of done work
- Discussion of backlog
- Collaboration on what next
- Marketplace change review
- Timeline, budget, capabilities, and marketplace projection
“The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint” (12)
Sprint Retrospective: “an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint” (12)
“after the Sprint Review and prior to the next Sprint Planning” (12)
Purpose (12):
- Inspect: people, relationships, processes, tools
- Identify and order what went well and potential improvements
- Create a plan for improvements
Scrum Artifacts
Product Backlog: “an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product” (13)
“A Product Backlog is never complete” (13)
“The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases” (13)
“Various projective practices upon trending have been used to forecast progress, like burn-downs, burn-ups, or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has happened may be used for forward-looking decision-making” (14)
Sprint Backlog: “the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal” (14)
Increment: “the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints” (15)
“Scrum relies on transparency” (15)
“Decisions to optimize value and control risk are made based on the perceived state of the artifacts” (15)
“The Scrum Master’s job is to work with the Scrum Team and the organization to increase the transparency of the artifacts. This work usually involves learning, convincing, and change. Transparency doesn’t occur overnight, but is a path” (15)
Definition of Done
“When a Product Backlog item or an Increment is described as ‘Done’, everyone must understand what ‘Done’ means” (14)
“Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together” (16)
Commentator’s Note: This is an interesting and difficult principle in the context of game development, where prototypes may be drastically incompatible with each other.
End Note
“Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum” (16)
Commentator’s Note: Seeing scrum events and artifacts in non-Scrum orgs make this point very obvious.